Variable Initialization: MSVC vs. world

[Thomas Matthews]

Hi,

When assigning variables at initialization, is the following
allowed:
class Field;

int main(void)
{
Field * p_field(NULL);
return EXIT_SUCCESS;
}

I've switch to using MS Visual C++ 6.0 and it is giving me
errors for the assignment. However, Borland 5.2 and GNU
g++ 3.4.4 do not give any errors.

My belief is that the above is correct syntax.

Unfortunately, I'm have to change all of these and
similar instances to:
Field * p_field = NULL;
to get the code to compiler under MSVC++ 6.0

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[Phlip]

Field * p_field(NULL);

I've switch to using MS Visual C++ 60 and it is giving
me errors for the assignment.

VC++ >6 permits that correct notation.

I suspect there are those who will promote constructor-notation for all
initializations. However, I can't think of a rationale besides "it's just
obviously better!"

 

[Jerry Coffin]

[ ... ]

I suspect there are those who will promote constructor-notation for all
initializations. However, I can't think of a rationale besides "it's just
obviously better!"

The obvious reasoning here is that constructor notation instructs the
compiler to construct the object with the value directly. Notation like:

whatever x=something;

really instructs the compiler to create a temporary object initialized
with 'something', then use whatever's copy constructor to create x, then
destroy the temporary. For built-in types, this is rarely a problem, but
for other types that take longer to create, copy and/or destroy, this is
substantially slower. Likewise, for extremely large objects, this wastes
memory creating two objects where only one is really needed.

 

[loufoque]

Phlip wrote :

I suspect there are those who will promote constructor-notation for all
initializations. However, I can't think of a rationale besides "it's just
obviously better!"

The constructor notation can cause problems related to function declaration.

 

[Victor Bazarov]

[ ... ]

I suspect there are those who will promote constructor-notation for
all initializations. However, I can't think of a rationale besides
"it's just obviously better!"

The obvious reasoning here is that constructor notation instructs the
compiler to construct the object with the value directly. Notation
like:

whatever x=something;

really instructs the compiler to create a temporary object initialized
with 'something', then use whatever's copy constructor to create x,
then destroy the temporary. For built-in types, this is rarely a
problem, but for other types that take longer to create, copy and/or
destroy, this is substantially slower. Likewise, for extremely large
objects, this wastes memory creating two objects where only one is
really needed.

The reality is a bit better but somewhat convoluted, I am afraid.
The compiler is explicitly allowed to forgo creation of a temporary
in such case, even if the copy c-tor has side effects (see 12.8/15).
However, the copy c-tor has to be accessible *as if* copying does take
place.

V

 

[loufoque]

Thomas Matthews wrote :

I've switch to using MS Visual C++ 6.0

Then switch again to a C++ compiler.

 

[Bart]

Hi,

When assigning variables at initialization, is the following
allowed:
class Field;

int main(void)
{
Field * p_field(NULL);
return EXIT_SUCCESS;
}

I've switch to using MS Visual C++ 6.0 and it is giving me
errors for the assignment.

Well, that's what you get for using an 8-year-old compiler. If you're
going to use MSVC at least use the most recent version (which is a lot
more standard-compliant BTW).

Regards,
Bart.

 

[Jeff Faust]

Thomas Matthews wrote :


Then switch again to a C++ compiler.

It compiles on VC++ 8, which is much much closer to being a C++
compiler.

Jeff