«

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

On Jun 26, 10:55 am, huil...@gmail.com 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

On Jun 26, 11:49*am, SeanW <sean_woolc...@yahoo.com> wrote:
> On Jun 26, 10:55 am, huil...@gmail.com 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?

On Jun 26, 11:49*am, SeanW <sean_woolc...@yahoo.com> wrote:
> On Jun 26, 10:55 am, huil...@gmail.com 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() ?

On Jun 26, 4:55 pm, huil...@gmail.com 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

On Jun 27, 5:35*am, James Kanze <james.ka...@gmail.com> wrote:
> On Jun 26, 4:55 pm, huil...@gmail.com 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:james.ka...@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

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.

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.

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.

On Jun 27, 1:09 pm, huil...@gmail.com wrote:
> On Jun 27, 5:35 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jun 26, 4:55 pm, huil...@gmail.com 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

On Jun 27, 2:44*pm, James Kanze <james.ka...@gmail.com> wrote:
> On Jun 27, 1:09 pm, huil...@gmail.com wrote:
>
> > On Jun 27, 5:35 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jun 26, 4:55 pm, huil...@gmail.com 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 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 200.

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.