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

[huili80@gmail.com]

Should complex<T>::rea l() 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!!!

[SeanW]

Re: about std::complex&lt ;&gt;'s real() and imag()

On Jun 26, 10:55 am, huil...@gmail.c om wrote:

Should complex<T>::rea l() 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 TT real(const complex<T>&);
template<class TT imag(const complex<T>&);

Sean

[huili80@gmail.com]

Re: about std::complex&lt ;&gt;'s real() and imag()

On Jun 26, 11:49 am, SeanW <sean_woolc...@ yahoo.comwrote:

On Jun 26, 10:55 am, huil...@gmail.c om wrote:
>

Should complex<T>::rea l() 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 TT real(const complex<T>&);
  template<class TT 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?

[huili80@gmail.com]

Re: about std::complex&lt ;&gt;'s real() and imag()

On Jun 26, 11:49 am, SeanW <sean_woolc...@ yahoo.comwrote:

On Jun 26, 10:55 am, huil...@gmail.c om wrote:
>

Should complex<T>::rea l() 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 TT real(const complex<T>&);
  template<class TT 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() ?

[James Kanze]

Re: about std::complex&lt ;&gt;'s real() and imag()

On Jun 27, 1:09 pm, huil...@gmail.c om wrote:

On Jun 27, 5:35 am, James Kanze <james.ka...@gm ail.comwrote:

On Jun 26, 4:55 pm, huil...@gmail.c om 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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[huili80@gmail.com]

Re: about std::complex&lt ;&gt;'s real() and imag()

On Jun 27, 2:44 pm, James Kanze <james.ka...@gm ail.comwrote:

On Jun 27, 1:09 pm, huil...@gmail.c om wrote:
>

On Jun 27, 5:35 am, James Kanze <james.ka...@gm ail.comwrote:

On Jun 26, 4:55 pm, huil...@gmail.c om 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:james.ka. ..@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientier ter Datenverarbeitu ng
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.

[James Kanze]

Re: about std::complex&lt ;&gt;'s real() and imag()

On Jun 28, 8:06 am, Jerry Coffin <jcof...@taeus. comwrote:

In article <a59bbc9a-36f8-48eb-8a6d-f3804f1ee185
@c65g2000hsa.go oglegroups.com> , huil...@gmail.c om 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_INTEGR AL_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_IN T64
#endif
#if (_MSC_VER >= 1310) && defined(_MSC_EX TENSIONS)
# 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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Bo Persson]

Re: about std::complex&lt ;&gt;'s real() and imag()

Jerry Coffin wrote:

In article <a59bbc9a-36f8-48eb-8a6d-f3804f1ee185
@c65g2000hsa.go oglegroups.com> , huili80@gmail.c om 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<ch arT,traits,Allo cator>& str,
typename
basic_string<ch arT,traits,Allo cator>::size_ty pe pos = 0,
typename
basic_string<ch arT,traits,Allo cator>::size_ty pe n =
basic_string<ch arT,traits,Allo cator>::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_FRIEN DS :-).


Bo Persson