Greg Herlihy wrote:
> On Mar 20, 10:03 am, p...@versatilecoding.com (Pete Becker) wrote:
>> Alberto Ganesh Barbati wrote:
>>
>>> Just a question: how many compilers define __cplusplus as 199711L yet
>>> they don't implement the export keyword? As you can see, this mechanism
>>> already failed in the past... It's not such a solid argument.
>> It's not an argument at all. It's a simple statement: a compiler that
>> does not conform to the C++ standard should not define the macro
>> __cplusplus.
>
> No, it's not a simple statement - it's a statement that is simply
> wrong: "...Non-conforming compilers should use a [__cplusplus] value
> with at most five decimal digits."
>

Fine. Testing for a value that's >= 199711L will always fail with such a
definition.

> Every C++ compiler (conforming or not) must define __cplusplus

No, the operative word in the footnote (footnotes are not normative) you
cite (without mentioning that it's a footnote) is "should", which is a
recommendation, not a requirement.

Yes, tautologically, a fully conforming C++ compiler must, as part of
conforming to the standard, define __cplusplus. But the subject here is
non-conforming compilers, so the requirements of the standard do not apply.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 20, 6:03 pm, p...@versatilecoding.com (Pete Becker) wrote:
> Alberto Ganesh Barbati wrote:

> > Just a question: how many compilers define __cplusplus as 199711L yet
> > they don't implement the export keyword? As you can see, this mechanism
> > already failed in the past... It's not such a solid argument.

> It's not an argument at all. It's a simple statement: a compiler that
> does not conform to the C++ standard should not define the macro
> __cplusplus.

According to whom?  The C++ standard has nothing to say about
what non-conforming compilers should do (although it could make
recommendations).  Maybe some truth in advertising law?

Even as a quality of implementation issue: __cplusplus has
historically been used to distinguish C from C++, in header
files, e.g.:

    #ifdef __cplusplus
    extern "C" {
    #endif
        ...
    #ifdef __cplusplus
    }
    #endif

with the result that a compiler that needs the `extern "C"' to
treat the header as C will generally (and should) define
__cplusplus.

I think that CFront defined it as 1; it would be nice if
compilers defined it as something less than 19971 unless they
were conform.  Regretfully, of the compilers I have handy (none
of which are conform), two out of three *do* define __cplusplus
as 199711.  Maybe they shouldn't (OK, definitly they shouldn't),
but they do.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze ha scritto:
>
> According to whom?  The C++ standard has nothing to say about
> what non-conforming compilers should do (although it could make
> recommendations).  Maybe some truth in advertising law?
>
> <snip>
>
> I think that CFront defined it as 1; it would be nice if
> compilers defined it as something less than 19971 unless they
> were conform.  Regretfully, of the compilers I have handy (none
> of which are conform), two out of three *do* define __cplusplus
> as 199711.  Maybe they shouldn't (OK, definitly they shouldn't),
> but they do.
>

Yes. That's exactly the point I was trying to raise. Regardless of the
actual C++ standard, the standard /de facto/ is that every reasonable
C++ compiler is defining __cplusplus as 199711L even if it's not
conforming. We have to consider that requiring __cplusplus == 199711L is
very crude. Implementors face a yes/no dilemma and it's inevitable that
they are tempted to say "yes" instead of "no" if the answer is "almost
yes" (for some definition of "almost").

So my point is that *even if the standard actually has no force on
non-conforming compiler*, if a more refined way to advertise features
were provided by the standard, implementors may decide to play nice and
abide by it.

To be concrete, one such scheme might be:

1) a macro to indicate full support of C++03 except for the export
keyword (rationale: we are not targeting pre-C++03 compilers but the
export keyword is so seldom implemented in actual compilers that it
makes sense to leave it out)

2) a macro to indicate support for the export keyword

3) a set of macros to indicate support for each of the main features of
C++0x: rvalue-refs, concepts, decltype/auto, template aliases, nullptr,
garbage collection, etc.

Just my opinion,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 22, 5:42 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> James Kanze ha scritto:

    [...]
> > I think that CFront defined it as 1; it would be nice if
> > compilers defined it as something less than 19971 unless they
> > were conform.  Regretfully, of the compilers I have handy (none
> > of which are conform), two out of three *do* define __cplusplus
> > as 199711.  Maybe they shouldn't (OK, definitly they shouldn't),
> > but they do.

> Yes. That's exactly the point I was trying to raise. Regardless of the
> actual C++ standard, the standard /de facto/ is that every reasonable
> C++ compiler is defining __cplusplus as 199711L

Not every.  g++ doesn't, and I'd consider it at least as
reasonable as VC++ or Sun CC.  (Personally, I don't consider it
reasonable that today, ten years after the standard was adopted,
a compiler does not implement export.  But that's another
question.)

> even if it's not
> conforming. We have to consider that requiring __cplusplus == 199711L is
> very crude. Implementors face a yes/no dilemma and it's inevitable that
> they are tempted to say "yes" instead of "no" if the answer is "almost
> yes" (for some definition of "almost").

It's not that crude.  If you want to follow the ARM, __cplusplus
== 1990 would seem to be a more reasonable choice.  And I'd have
no complaints with a compiler using the date of a draft without
export.

    [...]
> 3) a set of macros to indicate support for each of the main features of
> C++0x: rvalue-refs, concepts, decltype/auto, template aliases, nullptr,
> garbage collection, etc.

It's an interesting idea, but where do you draw the line.  Most
of these features are relatively complex, and we can imagine
early versions only implementing them partially.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 22, 11:54 am, "James Kanze" <james.ka...@gmail.com> wrote:
> On Mar 22, 5:42 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
.
> > 3) a set of macros to indicate support for each of the main features of
> > C++0x: rvalue-refs, concepts, decltype/auto, template aliases, nullptr,
> > garbage collection, etc.
>
> It's an interesting idea, but where do you draw the line.  Most
> of these features are relatively complex, and we can imagine
> early versions only implementing them partially.
.

Maybe the C++ keywords that are not C keywords could be
assigned successive numbers starting with 0.  If a
compiler could parse proper usage of the keyword, it
would turn on the corresponding bit in the preprocessor
constant __cplusplus_keywords.

A quite arbitary line to draw, but more sensible than
simple yes/no compliance with a large and complex
standard.  If there were truly some way to pressure
compiler vendors to be 100% compliant, they would
push back harder on things like "export", and the
end result might be that advanced features get
dropped or unnecessarily delayed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
>
> Just a question: how many compilers define __cplusplus as 199711L yet
> they don't implement the export keyword? As you can see, this mechanism
> already failed in the past... It's not such a solid argument.
>

It's not an argument at all. It's a simple statement: a compiler that
does not conform to the C++ standard should not define the macro
__cplusplus.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pete Becker wrote:
> Alberto Ganesh Barbati wrote:
>>
>> Just a question: how many compilers define __cplusplus as 199711L yet
>> they don't implement the export keyword? As you can see, this mechanism
>> already failed in the past... It's not such a solid argument.
>>
>
> It's not an argument at all. It's a simple statement: a compiler that
> does not conform to the C++ standard should not define the macro
> __cplusplus.

That's a matter of opinion; the C++ standard has no force
over compilers that do not comply with it.  It's certainly
unfortunate if compilers define __cplusplus misleadingly,
but current practice is that almost all of them do -- in
other words, the de facto standard is that compilers which
implement some vague level of approximation to C++ define
__cplusplus, which thereby serves little purpose other than
distinguishing them from C compilers, which (in my
experience) do not define __cplusplus.

For comparison, it's common for C++ compilers to define
__STDC__, though arguably they should not.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 20, 10:03 am, p...@versatilecoding.com (Pete Becker) wrote:
> Alberto Ganesh Barbati wrote:
>
> > Just a question: how many compilers define __cplusplus as 199711L yet
> > they don't implement the export keyword? As you can see, this mechanism
> > already failed in the past... It's not such a solid argument.
>
> It's not an argument at all. It's a simple statement: a compiler that
> does not conform to the C++ standard should not define the macro
> __cplusplus.

No, it's not a simple statement - it's a statement that is simply
wrong: "...Non-conforming compilers should use a [__cplusplus] value
with at most five decimal digits."

Every C++ compiler (conforming or not) must define __cplusplus - or
the compiler would not be a C++ compiler (of any kind). Therefore, to
distinguish conforming C++ compilers from the others, the C++ Standard
recommends that non-conforming C++ compilers define __cplusplus as
described above so that the non-conforming value will not conflict
with the conforming value - either now or in the future.

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze ha scritto:
>
> In practice, I've never found this to be too much of a problem.
> I always need a lot of implementation specific options for the
> compiler, anyway, which vary radically from one compiler to the
> next, and even from one version to the next.  So it's no big
> deal adding a project specific one, e.g. GB_supportsConcepts, if
> you really need it.  I also find that in application code, you
> rarely need it: if one of your compilers doesn't support some
> feature, you don't use it---whatever you use instead should work
> even on the compilers which do support the feature.
>

I was expecting this objection. In fact, I agree with you. But what
about library (or library-like) code whose explicit intent is to support
as many compilers as possible? Think about libraries like Boost. For
example, a library could provide a component with full move-semantic if
rvalue-refs are supported, while also providing fall-backs with more
limited semantic for older compilers.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Will C++09 specify preprocessor flags to indicate the presence
of new features (__cplusplus_concepts perhaps)?  Or, will there
just be a single one for the new standard (__cplusplus09) ?

This is the best way I can think of  to allow the writing
of templates with Concepts specified for the declaration
of formal template parameters for C++09, and without
Concepts for C++98.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

W Karas wrote:
> Will C++09 specify preprocessor flags to indicate the presence
> of new features (__cplusplus_concepts perhaps)?  Or, will there
> just be a single one for the new standard (__cplusplus09) ?
>
> This is the best way I can think of  to allow the writing
> of templates with Concepts specified for the declaration
> of formal template parameters for C++09, and without
> Concepts for C++98.
>

The macro __cplusplus expands to the version number (supposedly the
release date of the standard), which will be updated in C++0x.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 8, 7:34 pm, p...@versatilecoding.com (Pete Becker) wrote:
> W Karas wrote:
> > Will C++09 specify preprocessor flags to indicate the presence
> > of new features (__cplusplus_concepts perhaps)?  Or, will there
> > just be a single one for the new standard (__cplusplus09) ?

> > This is the best way I can think of  to allow the writing
> > of templates with Concepts specified for the declaration
> > of formal template parameters for C++09, and without
> > Concepts for C++98.

> The macro __cplusplus expands to the version number (supposedly the
> release date of the standard), which will be updated in C++0x.

Just a note: it expands to the version number with an integral
type (not a string), so you can do things like:

    #if __cplusplus > 200000L

(I believe that the intent is that the number be year*100 +
month; maybe you could confirm that.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> On Mar 8, 7:34 pm, p...@versatilecoding.com (Pete Becker) wrote:
>> W Karas wrote:
>>> Will C++09 specify preprocessor flags to indicate the presence
>>> of new features (__cplusplus_concepts perhaps)?  Or, will there
>>> just be a single one for the new standard (__cplusplus09) ?
>
>>> This is the best way I can think of  to allow the writing
>>> of templates with Concepts specified for the declaration
>>> of formal template parameters for C++09, and without
>>> Concepts for C++98.
>
>> The macro __cplusplus expands to the version number (supposedly the
>> release date of the standard), which will be updated in C++0x.
>
> Just a note: it expands to the version number with an integral
> type (not a string), so you can do things like:
>
>     #if __cplusplus > 200000L
>
> (I believe that the intent is that the number be year*100 +
> month; maybe you could confirm that.)
>

I think that's the scheme. In C++98, the value of __cplusplus is
199711L. (It's the same in C++03, which was an oversight)

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 8, 1:34 pm, p...@versatilecoding.com (Pete Becker) wrote:
> W Karas wrote:
> > This is the best way I can think of  to allow the writing
> > of templates with Concepts specified for the declaration
> > of formal template parameters for C++09, and without
> > Concepts for C++98.
>
> The macro __cplusplus expands to the version number (supposedly the
> release date of the standard), which will be updated in C++0x.

Practically speaking, this doesn't help us at all :)

C++0x features are likely to be implemented piece-meal, with
potentially years in between implementation of the simple C++0x
features (say, right angle brackets or delegating constructors) and
the more comprehensive features (concepts, garbage collection). So, I
expect we'll all need to define our own C++0x feature macros, and keep
those in sync with compiler releases, just like we did for C++98.

  Cheers,
  Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> On Mar 8, 1:34 pm, p...@versatilecoding.com (Pete Becker) wrote:
>> W Karas wrote:
>>> This is the best way I can think of  to allow the writing
>>> of templates with Concepts specified for the declaration
>>> of formal template parameters for C++09, and without
>>> Concepts for C++98.
>> The macro __cplusplus expands to the version number (supposedly the
>> release date of the standard), which will be updated in C++0x.
>
> Practically speaking, this doesn't help us at all :)
>

Sure it does! If __cplusplus is less than the value specified for C++0x,
don't use C++0x features. <g>

> C++0x features are likely to be implemented piece-meal, with
> potentially years in between implementation of the simple C++0x
> features (say, right angle brackets or delegating constructors) and
> the more comprehensive features (concepts, garbage collection). So, I
> expect we'll all need to define our own C++0x feature macros, and keep
> those in sync with compiler releases, just like we did for C++98.
>

The standard can't cater to non-conforming implementations, so, yes
there will be a transition period where the standard doesn't help.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pete Becker ha scritto:
> Douglas Gregor wrote:
>> On Mar 8, 1:34 pm, p...@versatilecoding.com (Pete Becker) wrote:
>>> W Karas wrote:
>>>> This is the best way I can think of  to allow the writing
>>>> of templates with Concepts specified for the declaration
>>>> of formal template parameters for C++09, and without
>>>> Concepts for C++98.
>>> The macro __cplusplus expands to the version number (supposedly the
>>> release date of the standard), which will be updated in C++0x.
>>
>> Practically speaking, this doesn't help us at all :)
>>
>
> Sure it does! If __cplusplus is less than the value specified for C++0x,
> don't use C++0x features. <g>
>

Just a question: how many compilers define __cplusplus as 199711L yet
they don't implement the export keyword? As you can see, this mechanism
already failed in the past... It's not such a solid argument.

>> C++0x features are likely to be implemented piece-meal, with
>> potentially years in between implementation of the simple C++0x
>> features (say, right angle brackets or delegating constructors) and
>> the more comprehensive features (concepts, garbage collection). So, I
>> expect we'll all need to define our own C++0x feature macros, and keep
>> those in sync with compiler releases, just like we did for C++98.
>>
>
> The standard can't cater to non-conforming implementations, so, yes
> there will be a transition period where the standard doesn't help.
>

In OpenGL, new features are usually first introduced as extensions to
the core and, once their use has solidified and is widely accepted, they
are moved into the core. Of course, C++ is different. But instead of
thinking "this compiler is C++0x conforming except for concepts" we
might reverse the point of view and say, for example, "this compiler is
C++03 conforming but provides rvalue references as described in C++0x as
an extension". In this way the standard would never need to cope with
"non-conforming" implementations. Could this switch help the committee
considering this issue? In the end it all boils down to identify the
most significant new features (concepts, rvalue refs, garbage collect
and what else?) and choose meaningful identifiers that an implementation
shall define if such features are implemented. Not a big deal.

Any thoughts?

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 10, 4:35 am, p...@versatilecoding.com (Pete Becker) wrote:
> Douglas Gregor wrote:

    [...]
> The standard can't cater to non-conforming implementations, so, yes
> there will be a transition period where the standard doesn't help.

Yes and no.  Unlike the case with C++98, there is a standard,
which all compilers can be expected to conform to.  So it's
quite possible to write portable code, just be avoiding the new
features entirely.  (I don't think that there will be much in
the new standard that will break existing conformant code.)

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sat, 10 Mar 2007 03:35:15 GMT, Pete Becker wrote:

        [...]
>>> The macro __cplusplus expands to the version number (supposedly the
>>> release date of the standard), which will be updated in C++0x.
>>
>> Practically speaking, this doesn't help us at all :)
>>
>
>Sure it does! If __cplusplus is less than the value specified for C++0x,
>don't use C++0x features. <g>

:-)

        [...]
>The standard can't cater to non-conforming implementations, so, yes
>there will be a transition period where the standard doesn't help.

One thing I have always wondered is: is it at all *legal* to use the
name C++ for a non-conforming implementation? (Well, without going
into a "what is intentional deviation" and "what is a bug" diatribe)

--
Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pete Becker ha scritto:
> Douglas Gregor wrote:
>
>> C++0x features are likely to be implemented piece-meal, with
>> potentially years in between implementation of the simple C++0x
>> features (say, right angle brackets or delegating constructors) and
>> the more comprehensive features (concepts, garbage collection). So, I
>> expect we'll all need to define our own C++0x feature macros, and keep
>> those in sync with compiler releases, just like we did for C++98.
>>
>
> The standard can't cater to non-conforming implementations, so, yes
> there will be a transition period where the standard doesn't help.
>

Sure, that's how an official body is expected to act. I completely agree
on that. But if the C++ community (NOT the C++ committee or at least not
necessarily) could agree on some informal yet detailed way to cope with
the transition period, maybe compiler vendors could decide to adopt it
and make life's easier to everyone. What do you think?

Just my opinion,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 12, 4:46 pm, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> Pete Becker ha scritto:

> > Douglas Gregor wrote:
> >> On Mar 8, 1:34 pm, p...@versatilecoding.com (Pete Becker) wrote:
> >>> W Karas wrote:
> >>>> This is the best way I can think of  to allow the writing
> >>>> of templates with Concepts specified for the declaration
> >>>> of formal template parameters for C++09, and without
> >>>> Concepts for C++98.
> >>> The macro __cplusplus expands to the version number (supposedly the
> >>> release date of the standard), which will be updated in C++0x.

> >> Practically speaking, this doesn't help us at all :)

> > Sure it does! If __cplusplus is less than the value specified for C++0x,
> > don't use C++0x features. <g>

> Just a question: how many compilers define __cplusplus as 199711L yet
> they don't implement the export keyword? As you can see, this mechanism
> already failed in the past... It's not such a solid argument.

The problem is, of course, that the C++ standard only defines
what a conforming compiler must do.  It doesn't say anything
about what a non-conforming compiler might do.

In practice, I've never found this to be too much of a problem.
I always need a lot of implementation specific options for the
compiler, anyway, which vary radically from one compiler to the
next, and even from one version to the next.  So it's no big
deal adding a project specific one, e.g. GB_supportsConcepts, if
you really need it.  I also find that in application code, you
rarely need it: if one of your compilers doesn't support some
feature, you don't use it---whatever you use instead should work
even on the compilers which do support the feature.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 12, 6:05 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> On Sat, 10 Mar 2007 03:35:15 GMT, Pete Becker wrote:

    [...]
> One thing I have always wondered is: is it at all *legal* to use the
> name C++ for a non-conforming implementation? (Well, without going
> into a "what is intentional deviation" and "what is a bug" diatribe)

Legal in what sense.  I've yet to use a conforming
implementation, at least professionally (since none of the
compilers I use professionally support export).  The name C++
was around long before ISO promolugated its standard.  As such,
even if ISO had wanted to, they couldn't have made it a
trademark, or some such (e.g. like Java or Ada), to protect it.

There is a lot of false advertizing floating around, of course,
which claims "standard C++"---even g++ has an option -std=c++98
(which doesn't activate export, so it is a lie).  As to what
that legally means, it doubtlessly varies from country to
country.  (I seem to remember reading somewhere that in Germany,
if there was a legal DIN standard for X, it was illegal to sell
an X which didn't conform.  And ISO 14882 is also a DIN
standard.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]