🚀 go-pugleaf

markj@atlantis.actrix.gen.nz (Mark Jordan) wrote:
>
>
>> I shudder to think of such ifdef's in the code. It would be a
>> maintenance nightmare -- think of having dynamic stuff like exceptions
>  ^^^^^^^^^^^^^^^^^^^^^
>> and casting in such ifdef's. 
>
>That's precisely what the C++ standard is becoming. Is it too much to
>ask for a standard that stays still!

Of course not. But you must be confused. There is NO C++ Standard,
it's still being worked on.

It hasn't been born yet, but when it is, it will stand relatively
still for at least 5 years.

>
>One of the most challenging things things that a software engineer 
>must attempt to do is to write bug free code. The glut of new features
>and semantics being introduced only makes this job harder every day.

  I disagree. C++ isn't simple, nor is it particularly
coherent, but there is no "glut" of new features. There are
a few minor changes (like mutable, bool, and explicit, and RTTI),
there is a MAJOR new coherent library (STL) which will lift
C++ programmer productivity by a huge factor in time,
and there is a MAJOR extension to the ARM "experimental"
template system. Most of the rest of the language is
relatively unchanged from the ARM, I can't see how much
ARM code would be broken by the current DWP,
and I know the committee has placed a HUGE effort into
retaining compatibility --- too much, IMHO, because this
is part of the reason for the complexity.

>> compilers. So, NOW you can't write portable code anyway. 
>
>Precisely!  Some of us would like to use the same code on embedded platforms
>as we do on a PC or mainframe. It's now next to impossible - even
>if you do have unlimited amounts of money to spend on C++ compilers.

  The only "expensive" compilers I know of are multi-user
licences.  Small systems C++ compilers go for a few hundred
dollars, a few hours work for a working programmer.
(Buying enough RAM and disk storage for them is another issue :-)

>Could somebody tell me please when all these changes are going to end.
>I would like to see at least a glimmer of light on the horizon.

  Sure. It will end when the ISO process affirms the DWP as an 
International Standard.

>Am I the only software engineer out here that feels this way? 

  Sure. We all do. But we're ALSO sick of writing reams of
error prone code in low level languages and we want something
much more powerful to increase programmer productivity
(and reduce sheer bordom!)

  C++ isn't that system. But it is enough to WRITE that 
system in. (Just :-)

>I bet the
>guys/gals who implement the compilers are dreading each change as it is made.

  Sure. They're ALSO the ones suggesting and approving the changes!
(Most of the vendors are represented on the committee)

>Getting back to my point about attempting to write bug-free software, I
>note that every month I see some article about compiler xxx having some
>obscure bug to do with the new language features of C++. I hate to think
>how many extra compiler introduced bugs are lying dormant in my software, 
>just waiting for their 15s of computing fame. As each new feature is 
>added do things get better or worse?

  I'm surprised. I've found that by being suitably conservative
the compilers that I use seem to have got MUCH more robust 
in the last 6 months -- at the same time as new features are added.

>Don't get me wrong, I do think that some of the extensions such as exception
>handling and templates are worthwhile, but I just wish the changes were
>managed in a better fashion. 

  So do I. What would YOU suggest as a way of managing it?

>It would be nice if all the compiler vendors
>supported the changes synchronously instead of in some adhoc fashion.

  I don't understand. Do you mean, all release "Version X.YY"
of their compilers at the same time with the same features?


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]