> 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!

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.

> 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.

> compilers (or specific releases) and then use -D's to define them?
> That way, you can still write portable code, can't you? It is just the
> compile time configuration that changes from one compiler to
> another... the code itself doesn't. Most of us have always been doing
> this kind of stuff in one form or the other anyway.

Yes, but we shouldn't have to.

> Nothing is certain but death and taxes

And a stochastic C++ standard.

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.

Am I the only software engineer out here that feels this way? I bet the
guys/gals who implement the compilers are dreading each change as it is made.
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?

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. It would be nice if all the compiler vendors
supported the changes synchronously instead of in some adhoc fashion.

I think it's about time people started discussing these issues in this
news group, instead of dreaming up some new obscure feature which could
be added to an already over-bloated language.


Mark.
Frustrated Software Engineer.

--
 Mark Jordan           |   Never put off anything you can do today
 Engineer              |   until tomorrow, because if you liked it,
 markj@actrix.gen.nz   |   you can do it again tomorrow!


---
[ 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. ]

Mark Jordan wrote:
> ... Is it too much to ask for a standard that stays still!

There is no standard yet.  It's being worked on.  The Draft of the standard
is much more stable, now, than the compilers that are catching up with it.
When there is a standard, it will of course stay still.

Or it will for a while ... anybody who looks into what the revived
C committee is up to will find a lot more to worry about than what
is going on with C++.

> 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.

Well, the Extensions Working Group has been disbanded.  Nothing resembling
a "new feature" has been added this year, and none are expected.
The changes to expect now are compilers becoming progressively
more similar to one another as the Draft nears approval.

> Am I the only software engineer out here that feels this way? I bet the
> guys/gals who implement the compilers are dreading each change as it is made.

Almost all the compiler implementors send representatives
to the ANSI/ISO Standards committee.  Votes for changes to the
Working Paper, lately, have mostly come out unanimous because
the changes are only to fix bugs.  Nobody wants the standard to be
finished more than the people putting volunteer labor into it.

Nathan Myers
myersn@roguewave.com

[ 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. ]

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. ]

According to John Max Skaller:
> Of course not. But you must be confused. There is NO C++ Standard,
> it's still being worked on.

OK, the draft standard(s) that every compiler vendor is taking as
gospel :-).

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

I'll look forward to that, IF it eventuates. (I mean the stand still part)

> >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,

My basic point was that complexity is the enemy of bug-free software.
Anything that increases complexity WILL result in more bugs, including
the STL library. (provided we still continue to code C++ manually).
Adding any standard libraries is effectively extending the language as
far as the average programmer is concerned.

> >> 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 :-)

Excuse me, but which tools do you use? IBM VisualAge 3.0 costs
roughly NZ $1700 with reference manuals, Microtec embedded systems
C++ compiler for 68K family costs roughly NZ $3000. Borland C++
costs around $600NZ ... the list goes on. Nothing even near $200.
DSP compilers are usually priced at the $1500 mark. They all support
different C++ feature sets.

> >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.

Any dates? 6mths away, 1yr away...

> >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!)

Oh, now I get it. All the changes were to prevent the C++ programming
community from becoming too bored. Why didn't they just say that. :-)

I don't know about you, but my old C code is every bit as reliable as
modern C++ code. All it takes is discipline and avoidance of dangerous
programming practices.

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

Good point.

> >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)

OK maybe they don't dread each change since they have a vested interest
in keeping things on the move.

> >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.

Which compiler are you refering to?
I agree that by sticking to the mainstream features you are less likely
to run into problems, but you have to ask yourself why compiler vendors
are having such a hard time writing a C++ compiler that works.

> >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?

How about this:
The C++ standards committee could say that compiler vendors must
support features u, v and w of draft standard x by date y in order
to be certified as an ANSI C++ compiler. This event should be no
more frequent than once a year, and preferably longer. Any vendors
that jump the gun and implement features that are not yet approved
for implementation would be declined certification until they were
removed.


> >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?

I mean't that it would be nice if all vendors supported the same
feature sets at the same time. I wouldn't go so far as defining a
version number, but perhaps a specific logo would be useful.


Cheers


--
 Mark Jordan           |   Never put off anything you can do today
 Engineer              |   until tomorrow, because if you liked it,
 markj@actrix.gen.nz   |   you can do it again tomorrow!

[ moderator's note: This discussion shows signs of degenerating
  into the kind of thing that led to this group becoming moderated.
  (I'm not picking on Mark, but this seemed a good time to step in.)
  Let's all try to keep in mind the newsgroup charter.  -sdc

  Charter:
  comp.std.c++ is for technical announcements and discussion of the
  ANSI/ISO C++ standardization process and the C++ standard, and for
  discussion of the design and standardization of the C++ language and
  libraries. Other discussion that is directly related to the C++
  standard (not related merely to C++ programming techniques) is
  also welcome. Posts should be cogent and free from personal attacks.
]


---
[ 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. ]

>>>>> On 25 Nov 95 05:33:11 GMT, shankar@engr.sgi.com (Shankar Unni)
said:

    Shankar> This not so much a standards issue as a migration issue.
    Shankar> As vendors phase in new (since the ARM) features, like "bool", "wchar_t"
    Shankar> (builtin), namespaces, exceptions, etc., people trying to write code that
    Shankar> works with multiple compilers have a hard time trying to come up with
    Shankar> appropriate configuration macros so that their source will build cleanly
    Shankar> on all target platforms.

    Shankar> For instance, I might want to take advantage of bool, if it is implemented.
    Shankar> The problem is, there is no automatic way of figuring this out, so I have
    Shankar> to write something like

    Shankar>     #if _BOOL_SUPPORTED
    Shankar>     /* bool already there.. */
    Shankar>     #else
    Shankar>     typedef int bool;
    Shankar>     const int true = 1;
    Shankar>     const int false = 1;
    Shankar>     #endif

    Shankar> The problem is, everyone has to come up with a scaffolding to do this
    Shankar> automatically on each platform, a laborious and error-prone process.

    Shankar> I had in mind a pseudo-standard set of macros that implementations could
    Shankar> define as they phased in features, like, say:

    Shankar>   _BOOL_SUPPORTED
    Shankar>   _WCHAR_T_SUPPORTED
    Shankar>   _NAMESPACES_SUPPORTED
    Shankar>   _EXCEPTIONS_SUPPORTED
    Shankar>   _RTTI_SUPPORTED
    Shankar>   _MEMBER_TEMPLATES_SUPPORTED
    Shankar>   _TEMPLATE_DEFAULT_ARGS_SUPPORTED

    Shankar> and so on.

I tend to think of this as an implementation issue. Where would you
stop if you go on like this? There'd have to be things like

 _TEMPLATE_EXPLICIT_QUALIFICATION_SUPPORTED
 _TYPENAME_SUPPORTED
 _TEMPLATE_EXPLICIT_INSTANTIATION_SUPPORTED
 _TEMPLATE_PARTIAL_SPECIALIZATION_SUPPORTED

... one for each new feature or extensions of new features in the
standard. What would be the grain size of these macros -- do they
exist for a toplevel feature or do they go deeper than that (for
example, _OVERLOADING_AND_PARTIAL_SPECIALIZATION_RULES_SUPPORTED)?

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.

I'm not in favor of letting the standard mandate such things. Let all
these things be taken care of the implementation. As it stands now,
there isn't much you can do in terms of portability across all C++
compilers. So, NOW you can't write portable code anyway.

Why not just figure out the list of all features supported by specific
compilers (or specific releases) and then use -D's to define them?
That way, you can still write portable code, can't you? It is just the
compile time configuration that changes from one compiler to
another... the code itself doesn't. Most of us have always been doing
this kind of stuff in one form or the other anyway.

--
Peace.... +<:-)

Anil

___________________________________________________________
Nothing is certain but death and taxes

---
[ 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. ]