about std::complex<>'s real() and imag()

Discussion in 'C++' started by huili80@gmail.com, Jun 26, 2008.

  1. Guest

    Should complex<T>::real() and imag() return a value or a refernce?
    What does the standard say about this?

    I just realized that MSVC2008's implementation returns a value, but in
    GCC reference is returned.
    I tend to believe that MSVC made a big mistake here!!! But
    unfortunately I must use it at work, which sucks!!!
    , Jun 26, 2008
    #1
    1. Advertising

  2. SeanW Guest

    On Jun 26, 10:55 am, wrote:
    > Should complex<T>::real() and imag() return a value or a refernce?
    > What does the standard say about this?
    >
    > I just realized that MSVC2008's implementation returns a value, but in
    > GCC reference is returned.
    > I tend to believe that MSVC made a big mistake here!!! But
    > unfortunately I must use it at work, which sucks!!!


    The standard says:

    // 26.2.7 values:
    template<class T> T real(const complex<T>&);
    template<class T> T imag(const complex<T>&);

    Sean
    SeanW, Jun 26, 2008
    #2
    1. Advertising

  3. Guest

    On Jun 26, 11:49 am, SeanW <> wrote:
    > On Jun 26, 10:55 am, wrote:
    >
    > > Should complex<T>::real() and imag() return a value or a refernce?
    > > What does the standard say about this?

    >
    > > I just realized that MSVC2008's implementation returns a value, but in
    > > GCC reference is returned.
    > > I tend to believe that MSVC made a big mistake here!!!  But
    > > unfortunately I must use it at work, which sucks!!!

    >
    > The standard says:
    >
    >   // 26.2.7 values:
    >   template<class T> T real(const complex<T>&);
    >   template<class T> T imag(const complex<T>&);
    >
    > Sean


    Wow... this is suprising!!!
    What could be the reason to forbid user from accessing the real and
    imaginary part of a complex number?
    , Jun 26, 2008
    #3
  4. Guest

    On Jun 26, 11:49 am, SeanW <> wrote:
    > On Jun 26, 10:55 am, wrote:
    >
    > > Should complex<T>::real() and imag() return a value or a refernce?
    > > What does the standard say about this?

    >
    > > I just realized that MSVC2008's implementation returns a value, but in
    > > GCC reference is returned.
    > > I tend to believe that MSVC made a big mistake here!!!  But
    > > unfortunately I must use it at work, which sucks!!!

    >
    > The standard says:
    >
    >   // 26.2.7 values:
    >   template<class T> T real(const complex<T>&);
    >   template<class T> T imag(const complex<T>&);
    >
    > Sean


    Wait... you are talking about free functions, but I was talking about
    member functions real() and imag().
    Can you tell me what does the standard say of the return types of
    member functions std::complex<T>::real() and std::complex<T>::imag() ?
    , Jun 26, 2008
    #4
  5. James Kanze Guest

    On Jun 26, 4:55 pm, wrote:
    > Should complex<T>::real() and imag() return a value or a
    > refernce? What does the standard say about this?


    > I just realized that MSVC2008's implementation returns a
    > value, but in GCC reference is returned.
    > I tend to believe that MSVC made a big mistake here!!! But
    > unfortunately I must use it at work, which sucks!!!


    The standard requires them to return a value. The standard is
    designed to leave the internal representation of complex
    unspecified; at least in theory, an implementation could use
    polar coordinates internally.

    Although good practice in general, this freedom is probably
    useless in the case of complex: complex is mainly used in
    mathematical and scientific applications; such applications have
    to communicate with Fortran, and Fortran imposes a
    representation of complex. So C++ might as well do so as well,
    and guarantee the same representation as Fortran. (And C: in C,
    "Each complex type has the same representation and alignment
    requirements as an array type containing exactly two elements of
    the corresponding real type; the first element is equal to the
    real part, and the second element to the imaginary part, of the
    complex number.")

    Of course, this is still not an argument for real() returning a
    reference instead of a value. In the end, real() is a classical
    "getter", and the usual conventions I've seen are that "getter"s
    should always return by value, unless there are serious
    performance reasons not to do so (e.g. if the getter returns an
    std::list with a hundreds of thousands of elements). From a
    design point of view, returning a value is the correct thing to
    do.

    (And I don't understand your objection to VC++. The library has
    always been better than that of g++; until recently,
    significantly better. And recent versions of the compiler are
    just as good too. The environment is worthless for any
    professional work, but gmake, bash and vim or emacs are all
    available under Windows, and VC++ works fine with them.)

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Jun 27, 2008
    #5
  6. Guest

    On Jun 27, 5:35 am, James Kanze <> wrote:
    > On Jun 26, 4:55 pm, wrote:
    >
    > > Should complex<T>::real() and imag() return a value or a
    > > refernce?  What does the standard say about this?
    > > I just realized that MSVC2008's implementation returns a
    > > value, but in GCC reference is returned.
    > > I tend to believe that MSVC made a big mistake here!!!  But
    > > unfortunately I must use it at work, which sucks!!!

    >
    > The standard requires them to return a value.  The standard is
    > designed to leave the internal representation of complex
    > unspecified; at least in theory, an implementation could use
    > polar coordinates internally.
    >
    > Although good practice in general, this freedom is probably
    > useless in the case of complex: complex is mainly used in
    > mathematical and scientific applications; such applications have
    > to communicate with Fortran, and Fortran imposes a
    > representation of complex.  So C++ might as well do so as well,
    > and guarantee the same representation as Fortran.  (And C: in C,
    > "Each complex type has the same representation and alignment
    > requirements as an array type containing exactly two elements of
    > the corresponding real type; the first element is equal to the
    > real part, and the second element to the imaginary part, of the
    > complex number.")
    >
    > Of course, this is still not an argument for real() returning a
    > reference instead of a value.  In the end, real() is a classical
    > "getter", and the usual conventions I've seen are that "getter"s
    > should always return by value, unless there are serious
    > performance reasons not to do so (e.g. if the getter returns an
    > std::list with a hundreds of thousands of elements).  From a
    > design point of view, returning a value is the correct thing to
    > do.
    >
    > (And I don't understand your objection to VC++.  The library has
    > always been better than that of g++; until recently,
    > significantly better.  And recent versions of the compiler are
    > just as good too.  The environment is worthless for any
    > professional work, but gmake, bash and vim or emacs are all
    > available under Windows, and VC++ works fine with them.)
    >
    > --
    > James Kanze (GABI Software)             email:
    > 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


    Thanks for the explanation. I actually read the standard yesterday and
    found out that it requires real() and imag() to return a value. Though
    I was admittedly shocked at first, I eventually realized that was due
    to the freedom of how a particular implementation could represent a
    complex number internally. I admit that I was wrong about VC++ in this
    particular matter.

    As for my general dislike of VC++, I think it mainly comes from the
    fact that when I try to look into the source code of Boost (or some
    other c++ libraries), I can always see specific workarounds dedicated
    for MS's broken compiler (among a few other broken compilers).

    I wonder in what sense you meant by "The library has always been
    better than that of g++". I really want to know, because I don't have
    much experience with VC++'s library.

    Recently versions of VC++'s compiler maybe have been better their
    older ones. But still, broken. Here is a concrete example which I
    found during my first week of working with VC++ at work (which is
    about two weeks ago). For an sample code in blitz-0.9 (located at /
    path to blitz-0.9/example/array.cpp), both VC2003 and VC2005
    "miscompile" it in debug mode. The output is just wrong! Mysteriously,
    in release mode it does give the correct result. (If anyone would like
    to test it with VC2008, please let me know your result).

    If this post is off-topic, I apologize.
    , Jun 27, 2008
    #6
  7. Jerry Coffin Guest

    In article <db07f3ea-c891-4194-9fcf-9cd2ef0a5e14
    @s50g2000hsb.googlegroups.com>, says...

    [ ... ]

    > Wait... you are talking about free functions, but I was talking about
    > member functions real() and imag().
    > Can you tell me what does the standard say of the return types of
    > member functions std::complex<T>::real() and std::complex<T>::imag() ?


    They also return by value, not reference:

    T real() const;
    T imag() const;

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jun 27, 2008
    #7
  8. Jerry Coffin Guest

    In article <9f3ea756-8380-43f9-b740-093ef2c4e443@
    34g2000hsf.googlegroups.com>, says...

    [ ... ]

    > As for my general dislike of VC++, I think it mainly comes from the
    > fact that when I try to look into the source code of Boost (or some
    > other c++ libraries), I can always see specific workarounds dedicated
    > for MS's broken compiler (among a few other broken compilers).


    Most of these are for Microsoft's older compilers -- especially for VC++
    6.0. OTOH, it's open to a lot of question whether this should be seen
    negatively or positively. The reason the workarounds are there is
    because people still use VC++ 6.0 despite it's being over a decade old
    -- and the reason people still use it long after all its contemporaries
    have long since disappeared is largely that for a lot of purposes it's
    still usable, while it's contemporaries are not.

    IMO, "broken" with reference to a compiler is a nearly meaningless term.
    From a pure conformance viewpoint, I'm reasonably certain every C++
    compiler on earth is broken, though the degree to which they're broken
    varies. Most older compilers were, of course, a lot more broken than
    newer versions of the same. Even the EDG compiler (and ones based on it
    such as Intel and Comeau) isn't really perfect -- though it's clearly
    better than most others.

    [ ... ]

    > Recently versions of VC++'s compiler maybe have been better their
    > older ones. But still, broken.


    Until or unless you define some fairly specific (and non-obvious)
    meaning for "broken", the same could be said of every other C++ compiler
    available and remain true. Worse, almost regardless of what any compiler
    vendor does, it's likely to remain true indefinitely -- C++ is
    sufficiently complex that getting a compiler truly perfect is more a
    dream than a realistic goal. EDG is about as close as it gets, and the
    guys at EDG are pretty close to fanatical about writing the best
    possible compiler -- but their compiler's still "broken" if you take
    that to mean "not perfectly conforming".

    Worse, their target is moving: the 2003 standard for C++ is five years
    old now, but nobody's really even produced a truly conforming compiler
    for C++ 98 yet. Meanwhile, the standard committee is working at putting
    the final touches on the new standard to render both of those obsolete
    again -- and it adds a LOT of new stuff that'll keep the compiler
    vendors busy for quite a while ("busy" meaning their current motto is
    probably: "sleep is a disease caused by caffeine deficiency").

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jun 27, 2008
    #8
  9. James Kanze Guest

    On Jun 27, 1:09 pm, wrote:
    > On Jun 27, 5:35 am, James Kanze <> wrote:
    > > On Jun 26, 4:55 pm, wrote:


    > As for my general dislike of VC++, I think it mainly comes
    > from the fact that when I try to look into the source code of
    > Boost (or some other c++ libraries), I can always see
    > specific workarounds dedicated for MS's broken compiler (among
    > a few other broken compilers).


    Most of them, I'll bet, are for VC++ 6.0. 6.0 was pretty bad
    with templates (although it was OK elsewhere---but templates are
    what Boost is all about). The latest versions are as good as
    g++.

    > I wonder in what sense you meant by "The library has always
    > been better than that of g++". I really want to know, because
    > I don't have much experience with VC++'s library.


    Well, back in 6.0, they had a real, working implementation of
    standard streams, for example. And locales (locale support is
    probably still better in VC++). Before g++ 3.0, std::string
    wasn't multi-thread safe (but then, nor was the compiler
    generated code---at least in the case of exceptions).

    Back in the first couple of years of this decade, you had the
    choice: you could use VC++, with a good library, but broken
    templates, or g++, with good templates, but a broken library.
    Today, both are pretty good in both respects (although neither
    come anywhere near to Comeau for templates).

    > Recently versions of VC++'s compiler maybe have been better their
    > older ones. But still, broken.


    I've never used a compiler without some bugs.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Jun 27, 2008
    #9
  10. Guest

    On Jun 27, 2:44 pm, James Kanze <> wrote:
    > On Jun 27, 1:09 pm, wrote:
    >
    > > On Jun 27, 5:35 am, James Kanze <> wrote:
    > > > On Jun 26, 4:55 pm, wrote:

    > > As for my general dislike of VC++, I think it mainly comes
    > > from the fact that when I try to look into the source code of
    > > Boost (or some other  c++ libraries), I can always see
    > > specific workarounds dedicated for MS's broken compiler (among
    > > a few other broken compilers).

    >
    > Most of them, I'll bet, are for VC++ 6.0.  6.0 was pretty bad
    > with templates (although it was OK elsewhere---but templates are
    > what Boost is all about).  The latest versions are as good as
    > g++.
    >
    > > I wonder in what sense you meant by "The library has always
    > > been better than that of g++".  I really want to know, because
    > > I don't have much experience with VC++'s library.

    >
    > Well, back in 6.0, they had a real, working implementation of
    > standard streams, for example.  And locales (locale support is
    > probably still better in VC++).  Before g++ 3.0, std::string
    > wasn't multi-thread safe (but then, nor was the compiler
    > generated code---at least in the case of exceptions).
    >
    > Back in the first couple of years of this decade, you had the
    > choice: you could use VC++, with a good library, but broken
    > templates, or g++, with good templates, but a broken library.
    > Today, both are pretty good in both respects (although neither
    > come anywhere near to Comeau for templates).
    >
    > > Recently versions of VC++'s compiler maybe have been better their
    > > older ones. But still, broken.

    >
    > I've never used a compiler without some bugs.
    >
    > --
    > James Kanze (GABI Software)             email:
    > 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



    You bet wrong! The workaround for VC++ in Boost are mostly for VC7
    (2003), and they continue to exist all the way till VC9 (which was
    released this year, right?).

    Let's look at the files in boost/config/compiler/, specifically the
    visualc.hpp and gcc.hpp . They contain all the information on what the
    compiler is and is not capable of.

    Dedicated to VC7, there are 20+ macros defined in visualc.hpp that are
    named in the following fashion:

    #define BOOST_NO_XXXX

    Please excuse me for not listing them here.
    Back in 2003, the contemporary gcc compiler was gcc3. The gcc.hpp
    contains only 4 macros named like the above that are dedicated for
    gcc3.

    Now let's see what's happending now (in 2008).

    The visualc.hpp indicates that every version of VC till VC9 all
    recieved macros named like BOOST_NO_XXXX , though the number is far
    less than that of VC7.
    While in the gcc.hpp file at the section for gcc4, I didn't see a
    single BOOST_NO_XXXX macro, but quite a few BOOST_HAS_XXXX macros.

    By the way, both gcc and icc provides experimental c++0x features in
    their most recent releases. Does VC9 offer any of those?

    As to the library, I guess you're probably right. But I wouldn't know
    for sure, because I never needed to rely my life on those libraries
    you mentioned where VC was once supieror to gcc and/or still is. To
    me, template is far more important than strings or locales.
    , Jun 28, 2008
    #10
  11. Jerry Coffin Guest

    In article <a59bbc9a-36f8-48eb-8a6d-f3804f1ee185
    @c65g2000hsa.googlegroups.com>, says...

    [ ... ]

    > Let's look at the files in boost/config/compiler/, specifically the
    > visualc.hpp and gcc.hpp . They contain all the information on what the
    > compiler is and is not capable of.
    >
    > Dedicated to VC7, there are 20+ macros defined in visualc.hpp that are
    > named in the following fashion:
    >
    > #define BOOST_NO_XXXX
    >
    > Please excuse me for not listing them here.


    I'll excuse you, but I won't let you off the hook. I'm going to list at
    least a couple here, in the hope that you might learn from it.

    > Back in 2003, the contemporary gcc compiler was gcc3. The gcc.hpp
    > contains only 4 macros named like the above that are dedicated for
    > gcc3.
    >
    > Now let's see what's happending now (in 2008).
    >
    > The visualc.hpp indicates that every version of VC till VC9 all
    > recieved macros named like BOOST_NO_XXXX , though the number is far
    > less than that of VC7.


    Quite true.

    > While in the gcc.hpp file at the section for gcc4, I didn't see a
    > single BOOST_NO_XXXX macro, but quite a few BOOST_HAS_XXXX macros.


    Not too surprising. But now let's take a look at some of those macros
    and figure out what they mean.

    For our first example, let's consider:

    # define BOOST_NO_INTEGRAL_INT64_T

    VisualC.hpp. This means the compiler doesn't define a type by the name
    of 'long long' -- but then, C++ doesn't _allow_ a conforming compiler to
    define a type named long long. A bit later in the same file we find:

    #if (_MSC_VER >= 1200)
    # define BOOST_HAS_MS_INT64
    #endif
    #if (_MSC_VER >= 1310) && defined(_MSC_EXTENSIONS)
    # define BOOST_HAS_LONG_LONG
    #endif

    In other words, 1) VC++ really does have an integral type of 64 bits --
    but it's given the name "__int64" instead of "long long". Since
    "__int64" is in the implementor's name space, this is a conforming
    extension.

    gcc, by contrast, uses the name "long long" -- which isn't exactly a
    terrible extension, given that it's the accepted name for a 64-bit
    (minimum) type in C99 and the current draft for C++ 0x. OTOH, according
    to the current C++ standard, code that uses 'long long' simply isn't
    conforming. IOW, what we're seeing is an instance where VC++ conforms to
    the standard, but gcc does NOT.

    In the end, it comes down to this: most of the Boost contributors use
    gcc as their primary compiler, so they've picked gcc as their baseline.
    They don't update the baseline _every_ time the compiler is updated, but
    even so, the BOOST_HAS_XXXX and BOOST_NO_XXXX macros are NOT really
    telling you how different the compiler is from the standard -- they're
    really telling you how different the compiler is from the version of gcc
    they've chosen as their baseline.

    Once you realize that, it's hardly surprising that reasonably recent
    versions of gcc don't require any BOOST_NO_XXXX macros, and really
    recent versions just add a few BOOST_HAS_XXXX macros to cover features
    added to the compiler since the version they're using as the baseline.
    Older versions of gcc have a few BOOST_NO_XXX macros, but (again) it's
    not really much of a surprise that older versions of gcc are still
    pretty similar to newer versions of gcc, whereas other compilers tend to
    be somewhat different from gcc.

    If you look (for example) in common_edg.hpp, you'll find that it _does_
    define some BOOST_NO_XXXX macros -- even though EDG has led the market
    in terms of language conformance pretty much since the day it came onto
    the market.

    > By the way, both gcc and icc provides experimental c++0x features in
    > their most recent releases. Does VC9 offer any of those?


    Yes, though only a few. There's (quite) a bit of tension when it comes
    to adding new features though. People experimenting with new language
    features want the compiler to change as quickly as possible, adding
    every new feature as soon as anybody even thinks of it. People
    maintaining production code want the compiler to stay exactly the same
    _forever_, never changing anything that could possibly break any
    existing code.

    Think for a moment, and you'll realize that to Microsoft it's _far_ more
    important to ensure that (for example) all the code in Windows and
    Office continues to work than it is to claim they were the first to
    support feature XXX (that was informally accepted in one committee
    meeting, but formally rejected in the next one).

    gcc (for one example) is in a rather different position. First of all,
    though quite a bit of code depends on gcc, the gcc folks aren't going to
    get fired if their new revision breaks existing code or isn't binary
    compatible with the previous version (in fact, gcc has done both quite
    regularly...)

    Don't get me wrong: that doesn't mean gcc has NO interest in stability
    _or_ that Microsoft never adds new features -- but it does mean that for
    Microsoft, new features must be justified, not just added because
    somebody thought they'd be cool. That's going to be cost justification
    -- how much does it cost to implement, how much to get code to work with
    it again, and how much does having it save over the next X years.

    For example, despite being far behind in some areas, MS was one of the
    _very_ first vendors to ship working namespace support. Given their use
    of large teams and lots of existing code, that strikes me as about as
    surprising as the sun rising in the morning.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jun 28, 2008
    #11
  12. James Kanze Guest

    On Jun 28, 8:06 am, Jerry Coffin <> wrote:
    > In article <a59bbc9a-36f8-48eb-8a6d-f3804f1ee185
    > @c65g2000hsa.googlegroups.com>, says...


    > [ ... ]


    > > Let's look at the files in boost/config/compiler/,
    > > specifically the visualc.hpp and gcc.hpp . They contain all
    > > the information on what the compiler is and is not capable
    > > of.


    > > Dedicated to VC7, there are 20+ macros defined in
    > > visualc.hpp that are named in the following fashion:


    > > #define BOOST_NO_XXXX


    > > Please excuse me for not listing them here.


    > I'll excuse you, but I won't let you off the hook. I'm going
    > to list at least a couple here, in the hope that you might
    > learn from it.


    > > Back in 2003, the contemporary gcc compiler was gcc3. The
    > > gcc.hpp contains only 4 macros named like the above that are
    > > dedicated for gcc3.


    > > Now let's see what's happending now (in 2008).


    > > The visualc.hpp indicates that every version of VC till VC9
    > > all recieved macros named like BOOST_NO_XXXX , though the
    > > number is far less than that of VC7.


    > Quite true.


    > > While in the gcc.hpp file at the section for gcc4, I didn't
    > > see a single BOOST_NO_XXXX macro, but quite a few
    > > BOOST_HAS_XXXX macros.


    > Not too surprising. But now let's take a look at some of those macros
    > and figure out what they mean.


    > For our first example, let's consider:


    > # define BOOST_NO_INTEGRAL_INT64_T


    > VisualC.hpp. This means the compiler doesn't define a type by
    > the name of 'long long' -- but then, C++ doesn't _allow_ a
    > conforming compiler to define a type named long long.


    A g++ still doesn't, unless you request extensions. (At least
    as of version 4.2.1, using long long with -Wall -pendantic
    causes an error.)

    VC++ 2005 does support long long (although I presume that there
    is an option to turn it off, for conformity's sake). But as you
    say, it's not (yet) C++. When all is said and done, of course,
    long long is an abomination, adopted by C99 because it was
    existing (bad) practice, and adopted by C0x because it was in
    C99. The C90 standard had provisions for creating new types
    (and new anything in the language): use a keyword whose name
    starts with __ or _[A-Z]. Technically, there were really only
    two reasonable choices in C90/C++98 for a 32 bit compiler to
    offer a 64 bit type: make long 64 bits, or define a new type
    with a name like __int64.

    > A bit later in the same file we find:


    > #if (_MSC_VER >= 1200)
    > # define BOOST_HAS_MS_INT64
    > #endif
    > #if (_MSC_VER >= 1310) && defined(_MSC_EXTENSIONS)
    > # define BOOST_HAS_LONG_LONG
    > #endif


    > In other words, 1) VC++ really does have an integral type of
    > 64 bits -- but it's given the name "__int64" instead of "long
    > long". Since "__int64" is in the implementor's name space,
    > this is a conforming extension.


    > gcc, by contrast, uses the name "long long" -- which isn't
    > exactly a terrible extension, given that it's the accepted
    > name for a 64-bit (minimum) type in C99 and the current draft
    > for C++ 0x.


    Gcc used the name "long long" because most other Unix compilers
    had started using it. Gcc did not come up with it; their
    motivation is purely compatibility with stupidity of other
    compilers. And g++ don't support it when invoked with
    extensions turned off.

    > OTOH, according to the current C++ standard, code that uses
    > 'long long' simply isn't conforming. IOW, what we're seeing is
    > an instance where VC++ conforms to the standard, but gcc does
    > NOT.


    And where VC++ made a technically intelligent decision, and the
    Unix C/C++ compilers didn't.

    > In the end, it comes down to this: most of the Boost
    > contributors use gcc as their primary compiler, so they've
    > picked gcc as their baseline. They don't update the baseline
    > _every_ time the compiler is updated, but even so, the
    > BOOST_HAS_XXXX and BOOST_NO_XXXX macros are NOT really telling
    > you how different the compiler is from the standard -- they're
    > really telling you how different the compiler is from the
    > version of gcc they've chosen as their baseline.


    I don't know about that, but historically, the VC++ which was
    current when much of the older Boost stuff was developed was
    6.0, which was pretty weak with regards to macros. So the habit
    developed to use macros to work around problems in VC++, but to
    try to make the code really portable for other compilers.

    [...]
    > > By the way, both gcc and icc provides experimental c++0x
    > > features in their most recent releases. Does VC9 offer any
    > > of those?


    > Yes, though only a few. There's (quite) a bit of tension when
    > it comes to adding new features though. People experimenting
    > with new language features want the compiler to change as
    > quickly as possible, adding every new feature as soon as
    > anybody even thinks of it. People maintaining production code
    > want the compiler to stay exactly the same _forever_, never
    > changing anything that could possibly break any existing code.


    And people developing new code prefer that their compiler not be
    the first to adopt new features---the first implementations are
    always the poorest. Let others do the experimentation, and once
    it's well established how to make it work, then evolve.

    For the rest, I think you pretty much summarized the problems
    and the trade offs involved between stability and new features.
    I just might add that in recent years, g++ has moved more and
    more in the direction of stability---in other words, has become
    more and more like Microsoft, Sun CC et al. For those of us who
    use the compiler in a production environment, this is a good
    thing.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Jun 28, 2008
    #12
  13. Bo Persson Guest

    Jerry Coffin wrote:
    > In article <a59bbc9a-36f8-48eb-8a6d-f3804f1ee185
    > @c65g2000hsa.googlegroups.com>, says...
    >> Let's look at the files in boost/config/compiler/, specifically the
    >> visualc.hpp and gcc.hpp . They contain all the information on what
    >> the compiler is and is not capable of.
    >>

    >
    > In the end, it comes down to this: most of the Boost contributors
    > use gcc as their primary compiler, so they've picked gcc as their
    > baseline. They don't update the baseline _every_ time the compiler
    > is updated, but even so, the BOOST_HAS_XXXX and BOOST_NO_XXXX
    > macros are NOT really telling you how different the compiler is
    > from the standard -- they're really telling you how different the
    > compiler is from the version of gcc they've chosen as their
    > baseline.


    Yes, otherwise they would have needed a BOOST_NO_EXPORT_TEMPLATE in
    the gcc config, but not for some others (EDG based).


    We also still have my "favorite" piece of convoluted code, in the
    std::bitset constructor:

    template<class charT, class traits, class Allocator>
    explicit bitset(const basic_string<charT,traits,Allocator>& str,
    typename
    basic_string<charT,traits,Allocator>::size_type pos = 0,
    typename
    basic_string<charT,traits,Allocator>::size_type n =
    basic_string<charT,traits,Allocator>::npos);

    which gcc just cannot parse, not even in version 4.1.3. Not
    surpriningly it uses an "as-if" implementation. Other "less capable"
    compilers have no problem with this (even though they might fail on
    BOOST_NO_MEMBER_TEMPLATE_FRIENDS :).


    Bo Persson
    Bo Persson, Jun 28, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Helmut Blass
    Replies:
    0
    Views:
    346
    Helmut Blass
    Jan 21, 2004
  2. Peter Jansson
    Replies:
    5
    Views:
    6,253
    Ivan Vecerina
    Mar 17, 2005
  3. =?Utf-8?B?U2FtdWVs?=
    Replies:
    14
    Views:
    521
    Walter Wang [MSFT]
    Mar 2, 2007
  4. Vinu
    Replies:
    4
    Views:
    342
    Jim Langston
    Jul 7, 2005
  5. ma740988
    Replies:
    5
    Views:
    373
    ma740988
    May 25, 2006
Loading...

Share This Page