🚀 go-pugleaf

Mark,
 
>>I agree that stack-based objects are usefull. However, I don't think they are
>>quite the same thing as a class and could be restricted to structs.
 
>Heh, never tried resource acquisition? If MacApp had real exception handling
>you'd see a LOT of stack-based classes for that purpose.
 
I think you missed my point about stack based objects.  (Perhapse "restricting
class based objects to structs" went to far.  I was suggesting that there is a
difference between a new "type" and a new "class".  (I am defining a type as
something that is designed to have no virtual methods.)  In general, objects
that are designed to be stack based are really new types (i.e. CStr255), which
struct handles nicely.  A class, on the other hand, should have most, if not
all, of it's non private methods virtual.  However, in c++, EVERYTHING defaults
to nonvirtual.  This give a bias for methods to be nonvirtual until a reason
(performance) is discovered for them to be virtual.  The bias should be for
methods to be virtual.  Even better would be to have this issue resolved by the
linker like Object Pascal does, or the environment.
 
>Or use an intelligent DevEnv like Component Workshop.
I thought that Component Workshop also requires you to specify a method to be
virtual.  Also, Component Workshop isn't really C++.  What do you if you want
to port any of your Component Workshop code to Window or Unix, or Pink?  Not to
put down component workshop, but one of the attactions C++ has is that you know
that you can find at least one C++ compiler on pretty much any system you want
to port any of your code to.
 
>>I don't think any of these changes would this would impact the power of C++,
>>but would make it less error prone and easier to learn.
>How do stack-based objects make C++ harder to learn?
 
The fact that they cause nonvirtual to be the default for class makes the
language more error prone.  Also, I was referring to all of the possibble
language changes I mentioned when I made this statement.
 
Alan
 
PS  It's too late to complain about these problems with C++ anyway.  Changing
them would break too much code.  I just hope the designer of the next language
that gains wide spread acceptance realises that programmer productivity can be
improved more by having the compiler catch mistakes for you than by always
striving to reduce the number of characters you have to type.