Rui Ferreira wrote in message <9n2esq$30mu$1@digitaldaemon.com>...
>I do not see any benefit to introduce vtables and polymorphism into a otherwise, by definition; simple and to the point data structure.


I think there may be misunderstanding here. Structs and classes are very different types. Structs do not have vtables and are not polymorphic. Classes have vtables and are polymorphic.

Rui Ferreira wrote:
> >> 3)  They cannot be inherited from
> 
> Well, I have found some uses to inheritance, here it mostly serves the purpose of code reuse.
> 
> A pragmatic role I guess, but not terribly important.

  I was just going on Bjarne's description.  To reuse them you make them
a member.  I do believe that we ought to prohibit virtual methods and
polymorphism, but I guess I don't have a good reason for that.

> >> They can have constructors and a destructor.  There is no guarantee that
> the destructor will be run immediately when a >>variable goes out of scope, but it will be run.  (I don't want to go to the extreme of saying they can't allocate >>resources.)
> 
> Yes, perhaps we can make some compromises regarding c++ here. A destructor is generally used on a concrete type to provide the "resource acquisition is initialization" paradigm.
> 
> I am used to this, so I'm biased, but we may find a better alternative.
> 
> I am not experienced enough to know if the 'finally' clause is a good one, but the auto-magical properties of a local concrete "handle" that releases its resources at the end of a block are very alluring.

	I like that style of resource management to, but it's a little rough
because of garbage collection from what I hear.  Beside, I think the
finally statement is supposed to be "the D way" of do this.  I guess I
will probably grow to like it since I would have to create an entire
class just to get the same results.

> Regarding the rest, data hiding with protection keywords is a must, and yes, operator overloading only on these types of data structures is a very good "force the users to use it" design compromise.

	There is a strong element against overloading on this group though.  I
don't want to presume that there will be overloading.  But limiting them
to concrete classes might be the way to prevent the abuses to some of it
more moderate opponents (reasonably) fear.

> >>and it would allow user defined vector math type that will be useful in
> tight loops.
> 
> And you know we need them... :]

	I'd like to think I'm going to do something pretty in 3D in a
reasonable frame rate.  And I like my math to look like math.  :-)

Dan

>>I was just going on Bjarne's description.  To reuse them you make them a
member.

Well, to use them I would make them a member, yes, but to REuse them I need to extend them in some way. In c++ that means inheritance to extend classes without the need for forwarding functions. Of course that, the very nature of concrete types makes them simple enough to avoid any substantial advantages from this, but since c++ allows it, natural uses have been found. I agree D should probably be simpler.

>>I do believe that we ought to prohibit virtual methods and polymorphism,
but I guess I don't have a good reason for that.

We're not prohibiting anything... we're just extending C Structs to support a public interface.

>>I guess I will probably grow to like it since I would have to create an
entire class just to get the same results.

Templates as smart pointers can be effective here. In fact smart pointers are so effective in c++ that they may now seem awkward to not be better integrated into the language itself. Provided it is available with a flexible extension mechanism of course. To push a single form of reference counted pointer or anything like that would be worst than the native template solution.

>>There is a strong element against overloading on this group though.  I
don't want to presume that there >>will be overloading.  But limiting them to concrete classes might be the way to prevent the abuses to >>some of it more moderate opponents (reasonably) fear.

True, but abuse would be not to support them. :]

-Rui

Correct. Const is not part of the typing system, although you will get an error if you try storing directly into a const:

    const int foo = 5;
    foo = 3;        // error

Note that C hardly gets it right. Look at strchr().

 -Walter

Axel Kittenberger wrote in message <9n1pt5$2iqm$2@digitaldaemon.com>...
> size_t strlen(char* s);
> char* strcpy(char* dest, char* src);

Okay then there is nothing that checks for const violations?
like mismatched arguments will result for you into a runtime segfault:

char *foo;
strcpy("hallo", foo);

from where a normal C comiler is perfectly able to warn/error for.

- Axel

> Axel Kittenberger wrote in message <9n0n3a$1v21$1@digitaldaemon.com>...
>>>So you're defintly targeting to be a userspace application only?
> 
> I don't understand why you conclude that from structs not having vtables and classes having.

Oh sorry, I misunderstood it as you're forcing always to use virtual functions on classes, no 'final' allowed.

- Axel

> Note that C hardly gets it right. Look at strchr().

Indeed! I never noticed that.

Now I finally know how I make 'secret' const casts, that pass through altough the compilers has const-cast-warnings truned on and is set on stop on warning :o)

But the problem is not easy to solve :/ Adding const at the return value is false too, people using strchr() on a really changeable array also want to have a changeable return pointer. Hmmm don't know would 'const' overloadable within C++? Or also for c++ could a template fix this? (Fortunally) I never deeped that far into C++.


> Correct. Const is not part of the typing system, although you will get an error if you try storing directly into a const:
> 
>     const int foo = 5;
>     foo = 3;        // error

Hmm I start to understand a bit, so I guess a call to an function declaring this one as 'out' would also not be allowed right?

But I still don't want to totally abandon the const's paradigm, from the practice I expirienced that adding the correct const attributes to a project usually spots bugs even before they ever appeared for the user, or using the correctly from start of hinders a whole set of programming failures even before they arise, even if it didn't help the optimizer at all.

I agree that 'const' in C++ is very confusing, especially in conjuction with typedefs, with type const struct members against const applied to the whole struct. And then when discussing with others it's funny that a set of people programming C fulltime for a couple years, still can't say certainly how more complicates constructions with const work out.

- Axel

Axel Kittenberger wrote in message <9n8if5$7rh$1@digitaldaemon.com>...
>And then when discussing with others it's funny that a set of
>people programming C fulltime for a couple years, still can't say certainly
>how more complicates constructions with const work out.


Even worse, const doesn't help the optimizer anyway, because some other non-const pointer may point to the same data and change it. Const just doesn't work as a type attribute.

Walter wrote:
> 
> Correct. Const is not part of the typing system, although you will get an error if you try storing directly into a const:
> 
>     const int foo = 5;
>     foo = 3;        // error
> 
> Note that C hardly gets it right. Look at strchr().

What's wrong with strchr()? MSVC's version of it seems to be declared sanely.

-RB

Russell Bornschlegel wrote:

> Walter wrote:
>> 
>> Correct. Const is not part of the typing system, although you will get an error if you try storing directly into a const:
>> 
>>     const int foo = 5;
>>     foo = 3;        // error
>> 
>> Note that C hardly gets it right. Look at strchr().
> 
> What's wrong with strchr()? MSVC's version of it seems to be
> declared sanely.

*must hold back scarcasm* *must hold back scarcasm*

>> What's wrong with strchr()? MSVC's version of it seems to be
>> declared sanely.
> 
> *must hold back scarcasm* *must hold back scarcasm*

Ooops sorry I hit enter too early, I was still in typing the message... so don't take it personally :/

MSVC's version just as good/bad as every others. Take a look what strchr() takes for an argument and take a look what the return type is.

So what happened to the 'const'? If I've a 'const char *' so am not allowed to change it, and search for a character with strchr(), it returns: suprise a 'char *' pointer, one that I can use to modify the contents from which was before forbidden.

. Axel