🚀 go-pugleaf

Hi,

Shankar Unni (shankar@engr.sgi.com) wrote:
: This not so much a standards issue as a migration issue.
: 
: What do people think? Of the idea, of the actual names if they are in favor
: of the idea, of which features should there be corresponding macros for? ...

I had a short (private) discussion with J.Kanze about this issue and we
decided to promote something like this (probably in
comp.lang.c++.moderated if it gets created: The voting period finished
on thursday but I don't have the results yet...). However, since there
are existing compilers which do not support these macro definitions and
which should be usable with the macros, our approach does not need to
built such a facility into the compiler. Instead a header file (which
includes some other header files too) is provided which defines a set
of macros.

I worked out a (not yet finished...) proposal for such files (including
a tool to "guess" about features supported by a certain compiler). I have
currently no feedback from James whether he likes my approach. However, I
have put the stuff into my WWW area. Use

  http://www.informatik.uni-konstanz.de/~kuehl/c++/portdefs.h.html

as an entry point, if you want to have a look on it. You can also download
the current stuff from

  ftp://ftp.informatik.uni-konstanz.de/pub/algo/kuehl/port.tar.gz

via anonymous ftp. Note that it is still under constructions. Some
parts of it are currently somewhat inconsistent although operational (I
will fix this soon).

Suggestion, additions, corrections, etc. are highly welcome! Currently
I have put the code under the GPL just to make sure it can be used by
everybody. I'm willing to make the licensing terms even more liberal
(to make the code useful in commercial products too) but I don't have
the knowledge how to write such a license. Suggestions and help on this
would also be welcome.
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic

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

Shankar Unni wrote:
> 
> This not so much a standards issue as a migration issue.
> 
> As vendors phase in new (since the ARM) features, like "bool", "wchar_t"
> (builtin), namespaces, exceptions, etc., people trying to write code that
> works with multiple compilers have a hard time trying to come up with
> appropriate configuration macros so that their source will build cleanly
> on all target platforms.
> ...
> I had in mind a pseudo-standard set of macros that implementations could
> define as they phased in features, like, say:
> 
>   _BOOL_SUPPORTED
>   _WCHAR_T_SUPPORTED
>   _NAMESPACES_SUPPORTED
>   _EXCEPTIONS_SUPPORTED
>   _RTTI_SUPPORTED
>   _MEMBER_TEMPLATES_SUPPORTED
>   _TEMPLATE_DEFAULT_ARGS_SUPPORTED
> 
> and so on. ...

Each community of developers who write portable code face this issue,
and approach it essentially the same way.  However, there is a key 
insight that can reduce the amount of work this involves, over time.

Rather than defining a macro _BOOL_SUPPORTED (which, by the way, is
in the vendor's reserved namespace), define a macro BOOL_BROKEN.
As features are added (and bugs fixed), macros are eliminated, until 
there are none left.  Then, a conforming compiler has no such macros 
defined, and is ready right out of the box. 

Vendor extensions should still be described positively: 
_VARIABLE_AUTO_ARRAYS, _AUTO_FUNCTIONS, etc.; but vendors
should provide those names themselves, to make it easier 
for users to use them safely.

Finally, it's a lot less work to use somebody else's maintained set 
of such macros.  I won't recommend any particular set, here.

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

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

Dietmar Kuehl (kuehl@uzwil.rz.uni-konstanz.de) wrote:

>   http://www.informatik.uni-konstanz.de/~kuehl/c++/portdefs.h.html
> as an entry point, if you want to have a look on it.

Excellent : this is the sort of thing I had in mind..

If there is established (or hopefully established) practice in this area,
then there is some hope.

(My motivation in asking this is that I want to add a couple of flags in
our compiler, so that I can share library source with an older official
compiler, and still have stuff for bool and array new/delete in the
library. I guess I'm just going to do a bare minimum set of flags for our
own use..)

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar


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

Nathan Myers (ncm@netcom.com) wrote:

> Rather than defining a macro _BOOL_SUPPORTED (which, by the way, is
> in the vendor's reserved namespace), define a macro BOOL_BROKEN.
> As features are added (and bugs fixed), macros are eliminated, until 
> there are none left.  Then, a conforming compiler has no such macros 
> defined, and is ready right out of the box. 

Oh, I was talking about *vendors* defining those symbols as they staged
each new feature online in their implementations.  As long as the names
were "pseudo-standard"ized, users could simply blindly stick in

  #ifdef _BOOL_SUPPORTED

into their code.

Sure, users come up with a scaffolding for this themselves (and I can see a
great value in an autoconf-like package - maybe a mini-autoconf - that can
generate a common "feature header" which could be automatically generated
by a config script on each platform).

But I was going about it from the angle of what vendors could provide to
make users' lives easier without going through all this autoconf
rigmarole (or having each user reinvent the wheel).

> Vendor extensions should still be described positively: 
> _VARIABLE_AUTO_ARRAYS, _AUTO_FUNCTIONS, etc.; but vendors
> should provide those names themselves, to make it easier 
> for users to use them safely.

That's right - that's exactly what I had in mind..
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar



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

In article <DIuD69.853@actrix.gen.nz>,
markj@atlantis.actrix.gen.nz (Mark Jordan) wrote:

|> That's precisely what the C++ standard is becoming. Is it too much to
|> ask for a standard that stays still!

I think that's an unfair characterisation. Very few new features have been
added in the last few meetings -- we have been clarifying the semantics and
descriptions.

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

With respect, "rubbish". Writing portable code is certainly possible. I
worked for a company that had a quarter of a million line C/C++ app and
could port it to new platforms in one or two days max, usually half a day.
They did it by having very tight coding standards which were automatically
enforced by the source library system. [mail me offline anyone who's
interested in hearing more about this]

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

The changes have almost completely stopped. Why don't you get more involved
in the standards process if you are so concerned? That's why I got my
previous company involved and it's why I, as an individual, am a paid up,
voting member of X3J16 who attends all the meetings!

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

Since the majority of compiler vendors are represented on the committee and
are actively voting on these changes, I think you are off the mark.

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

The Extensions WG was disbanded a couple of meetings ago so that we can
focus on clarifications. This was done partly as an externally visible
confirmation that the process is indeed stabilising. We are in the 'home
run' of the ballot process, concerned with satisfying national bodies'
objections _only_ and we are not adding any more extensions.

Critical posts like yours do not make the committee's job any easier.

Sean A. Corfield
Object Consultancy Services
C++ - Beyond the ARM - http://uptown.turnpike.net/~scorf/cplusext.html




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

Sean A Corfield (sean@corf.demon.co.uk) wrote:
|> In article <xg3pwecl774.fsf@marsh.cacs.usl.edu>,
|> akv@cacs.usl.edu (Anil Vijendran) 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. 

|> I would go further and say that it would simply be unworkable. Suppose you
|> want to write code that uses exceptions if they are available. What does it
|> do if they aren't? Some horrendous pseudo-exception hack, perhaps? RTTI
|> also affects the core of the way you design/build systems.

It depends on what level you are programming.  At the application level,
I agree.  An application must be designed to use exceptions, or not to
use them; it cannot do both.  At a library level, however, I would like
to write code which allows the user to use exceptions if they are
present, but also allows him not to use them, whether they are present
or not.

Most of the defines encompass smaller issues, however.  Things like
bool.  And the resulting ifdef's are limited to a header file which
makes other defines, for example:

    #if GB_HASBOOL
    typedef bool        GB_bool ;
    #define GB_true     true
    #define GB_false    false
    #else
    typedef int         GB_bool ;
    #define GB_true     1
    #define GB_false    0
    #endif

    #if GB_HASNEWCAST
    #define GB_CONSTCAST( t , o )       (const_cast< t >(o))
    #define GB_STATICCAST( t , o )      (static_cast< t >(o))
    #define GB_REINTERPRETCAST( t , o ) (reinterpret_cast< t >(o))
    #else
    #define GB_CONSTCAST( t , o )       ((t)(o))
    #define GB_STATICCAST( t , o )      ((t)(o))
    #define GB_REINTERPRETCAST( t , o ) ((t)(o))
    #endif

    #if GB_HASMUTABLE
    #define GB_MUTABLE  mutable
    #define GB_MUTABLECAST( t , o )     (o)
    #else
    #define GB_MUTABLE
    #define GB_MUTABLECAST( t , o )     GB_CONSTCAST( t , o )
    #endif

Even with regards to exceptions, I will occasionally use something like
the following in library code:

    GB_BEGIN_TRY
        //  .. Some operations
    GB_CATCH( ... )
        //  .. Any necessary cleanup
        GB_RETHROW ;
    GB_END_TRY

The definition of the macros is as follows:

     #if GB_HASEXCEPTIONS
     #define GB_BEGIN_TRY            try {
     #define GB_END_TRY              }
     #define GB_CATCH( cond )        } catch( cond ) {
     #define GB_RETHROW              throw
     #else
     #define GB_BEGIN_TRY            if ( 1 ) {
     #define GB_END_TRY              }
     #define GB_CATCH( cond )        } else if ( 0 ) {
     #define GB_RETHROW
     #endif

If the implementation doesn't support exceptions, of course, I don't
have to worry about cleaning up when an exception is thrown.

|> Smaller issues are slightly easier to workaround -- simply don't use new
|> features if your target is portability!

How do I avoid using namespaces if my compiler library puts iostream in
namespace std?  Once again, GB_USE( std::ios ) (or GB_USE_NS( std )) to
the rescue (and of course, GB_USE and GB_USE_NS are defined
conditionally).

And let's not forget GB_SYSINCLUDE(iostream), which expands to
<iostream.h>, or <iostream.hpp>, or <iostream>, or in fact, anything
else you might need to get the works (including, perhaps "myiostream.h"
for the perverse cases).

|> And then there are more subtle issues:

|>   enum E { a, b, c };
|>   void f(E);
|>   void f(int);

|> Or, even more so:

|>   struct T { static void f(); };
|>   T* g();
|>   g()->f();

|> Depending on how close to the draft your compiler is, the first may fail to
|> compile and the second may, or may not, cause 'g()' to actually be called.

|> The best approach to stuff like this is simply to avoid the changed areas
|> unconditionally -- feature-specific macros are not the way to go, IMO

I agree with avoiding the new stuff when you can.  I would never write
code which actually uses namespaces or RTTI, for example, except in an
application for a specific compiler where I knew that they were
available.  And I write my for loops so that it doesn't matter which
scope rules are used.  But you simply cannot always avoid the
differences.

This is nothing new.  Alert readers will have already noticed that
defining GB_SYSINCLUDE(iostream) to generate <iostream.h> or
<iostream.hpp> has nothing to do with new features in the standard.  And
we've always had to deal with int's being different sizes, plain char
being maybe signed and a number of other variables.  (My code still has
conditional definitions to handle ctype functions that don't work for
values greater than 127, and my programs don't expect tolower to work
unless isupper is true, ISO 9899 not withstanding.)

I must admit, however, that the evolving C++ standard has raised this
sort of compiler dependancy handling to a new level.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

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