🚀 go-pugleaf

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