Wednesday, February 3, 2010

comp.lang.c++ - 21 new messages in 6 topics - digest

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* C++0x regex supported by gcc? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a5e3fb25be9236a9?hl=en
* memory leaks - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/d9b20823062f2cb3?hl=en
* ordered unordered_map - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3743266d80703cfb?hl=en
* On the Square-Rectangle Problem - 10 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/17378f3e6e3294ba?hl=en
* MySQL connector/driver behaviour with Visual C++ CLR/CLI project - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/738ca35dc8623177?hl=en
* Static member vs global variable - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en

==============================================================================
TOPIC: C++0x regex supported by gcc?
http://groups.google.com/group/comp.lang.c++/t/a5e3fb25be9236a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 4:58 pm
From: Jorgen Grahn


On Sun, 2010-01-31, mattia wrote:
> Hi all, do you know if gcc supports the regex library defined in the
> C++0x draft? If so, which version?

This ought to be a starting point:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html

> Can you provide a simple snippet?

Example code? Why? Using the regex library will look the same, no
matter what compiler you use, as long as it supports it.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

==============================================================================
TOPIC: memory leaks
http://groups.google.com/group/comp.lang.c++/t/d9b20823062f2cb3?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 2 2010 5:05 pm
From: red floyd


On Feb 2, 4:24 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Mon, 2010-01-25, Larry wrote:

> >   ZeroMemory(buff, sizeof(Buffer));
>
> Just out of curiosity: did you define this one somewhere, or are
> Microsoft daft enough to push a differently named std::memset()?

Microsoft is that daft.


== 2 of 3 ==
Date: Tues, Feb 2 2010 6:36 pm
From: "Alf P. Steinbach"


* red floyd:
> On Feb 2, 4:24 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Mon, 2010-01-25, Larry wrote:
>
>>> ZeroMemory(buff, sizeof(Buffer));
>> Just out of curiosity: did you define this one somewhere, or are
>> Microsoft daft enough to push a differently named std::memset()?
>
> Microsoft is that daft.

I agree :-), but in this particular case it's not so. ZeroMemory is a Windows
API function. It's available whether you program in C or Pascal or Fortran, say
(actually I don't know about Fortran, it's near 30 years since I last rode that
beast, but I'm pretty sure it can be used also from Fortran).

The OP's code was

Buffer *buff = new Buffer;
ZeroMemory(buff, sizeof(Buffer));

and by the rules of C++ he could just have written

Buffer* buff = new Buffer(); // That's it.

by §5.3.4/15 second main dash, which in C++98 reads "If the new-initializer is
of the form (), default-initialization shall be performed" (and I guess that's
changed to "value initialization" in C++03, but I'm not checking that).


Cheers,

- Alf


== 3 of 3 ==
Date: Tues, Feb 2 2010 10:16 pm
From: Rolf Magnus


Jorgen Grahn wrote:

> On Mon, 2010-01-25, Larry wrote:
> ...
>> #define _CRT_SECURE_NO_WARNINGS
>> #include <windows.h>
>> #include <vector>
>> #include <cstdlib>
>> #include <ctime>
>> #include <cstdio>
>> #include <boost/circular_buffer.hpp>
>> using namespace std;
>> using namespace boost;
>
> ...
>> ZeroMemory(buff, sizeof(Buffer));
>
> Just out of curiosity: did you define this one somewhere, or are
> Microsoft daft enough to push a differently named std::memset()?

They have their own function for pretty much everything, just like they have
CHAR and VOID as replacement for char and void. Maximum incompatibility
seems to be the main goal.


==============================================================================
TOPIC: ordered unordered_map
http://groups.google.com/group/comp.lang.c++/t/3743266d80703cfb?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 6:18 pm
From: tonydee


On Feb 2, 10:30 pm, Ralf Goertz <r_goe...@usenet.arcornews.de> wrote:
> Pete Becker wrote:
> > Ralf Goertz wrote:
> >> I recently found out that using unordered_map<unsigned, Foo> instead of
> >> map<unsigned, Foo> speeds up my program substantially (it contains
> >> several hundreds of thousands elements). However, I really would like to
> >> be able to iterate over those elements in an ordered way at the end of
> >> the program. Is there a way to do that? ...
>
> > If you're willing to reorganize the container, how about going a small
> > step further and replacing it at that point with an ordered container?
>
> It seems I will have to do that then, thanks.

It's a good, simple solution in most cases. If the objects are large
and keys small and your RAM limited, and/or that final step is
performance critical too, consider
- keeping the data in an ordered map, but adding an unordered (hash)
map indexing from key to ordered-map iterator
- keep the data in a vector, and having unordered and ordered maps
from key to index
- looking at boost's multi-indexed container library, which can manage
the synchronisation of data and indices for you

Cheers,
Tony

==============================================================================
TOPIC: On the Square-Rectangle Problem
http://groups.google.com/group/comp.lang.c++/t/17378f3e6e3294ba?hl=en
==============================================================================

== 1 of 10 ==
Date: Tues, Feb 2 2010 8:18 pm
From: tonydee


On Feb 2, 1:30 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Tony D <anthony...@gmail.com> writes:
> >what functions are appropriate in the interfaces, any inheritance
> >relationship, justified in terms of implications to correct design and
> >usage.
>
>   Such questions are best discussed given a specific set of
>   requirements for a programming task.
>
>   For example, when someone tells me to write a shape
>   editor where one can edit rectangles and squares, these
>   requirements would eventually lead to a class design,
>   possibly with certain subtype-relationships.
>
>   Without specific requirements, we can not derive enough
>   information from just the words »square« and »rectangle«
>   to get such a design.

Agreed, but is it not the exploration of options and implications in
this space that makes the square/rectangle circle/ellipse problem
space educational?


== 2 of 10 ==
Date: Tues, Feb 2 2010 8:45 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)


tonydee <tony_in_da_uk@yahoo.co.uk> writes:
>Agreed, but is it not the exploration of options and implications in
>this space that makes the square/rectangle circle/ellipse problem
>space educational?

Educational or just entertaining?

Whenever one has a specific assignment, one has a context.

Given just the words one can only use the mathematical
definition, because this is the realm those words come from.
By this, a circle is the set of all points where the
distance from a given point is a given constant while an
ellipse is the set of all points in a plane such that the
sum of the distances to two fixed points is a given constant.

By this definition, every circle is an ellipse, because
here, set theory applies.

So in programming, to come to other conclusions, one needs
to use other meanings of »circle« and »ellipse«, and those
cannot be derived from just those words.

== 3 of 10 ==
Date: Tues, Feb 2 2010 9:02 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)


Philip Potter <pgp@doc.ic.ac.uk> writes:
>A square store is guaranteed to hold a square. A rectangle store has no
>such guarantee.
>A rectangle store which currently holds a nonsquare rectangle is
>certainly not useful as a square store.

If a rectangle store can store a width and a height, then it
can store a square by storing the width and the height of
the square (which happen to be equal to each other for a square).

Assuming for simplicity rectangles and squares with borders
that are parallel to the axes of the coordinate system, both
have only the width and height as their properties.

(However, you might define some of these terms in other ways,
and then you would be right. So here, everything depends on the
definitions used for these terms.)

== 4 of 10 ==
Date: Tues, Feb 2 2010 10:25 pm
From: tonydee


On Feb 3, 1:45 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> tonydee <tony_in_da...@yahoo.co.uk> writes:
> >Agreed, but is it not the exploration of options and implications in
> >this space that makes the square/rectangle circle/ellipse problem
> >space educational?
>
>   Educational or just entertaining?
>
>   Whenever one has a specific assignment, one has a context.
>
>   Given just the words one can only use the mathematical
>   definition, because this is the realm those words come from.

Not so, the words also have meaning in common usage.

>   By this, a circle is the set of all points where the
>   distance from a given point is a given constant while an
>   ellipse is the set of all points in a plane such that the
>   sum of the distances to two fixed points is a given constant.
>
>   By this definition, every circle is an ellipse, because
>   here, set theory applies.

In common usage, calling something an ellipse may imply it's not
(obviously) simply a circle, in the same way that calling some person
an animal is presumed to be making a point. But I play Devil's
Advocate here... it's only a distraction from the OO modeling issues
that these examples are used to illustrate.

>   So in programming, to come to other conclusions, one needs
>   to use other meanings of »circle« and »ellipse«, and those
>   cannot be derived from just those words.

Not so... the programming issues embrace the definitions you've
provided above - accepting those conclusions. Specifically, they
explore what happens when you map that conclusion most simply/naively
into an object model: a Circle object as a special case (subclass) of
a more general Ellipse. The answer is that you have Circles that
can't do what is reasonable to ask of an Ellipse, namely, alter the
ratio of width to height, without ceasing to be Circles. You hide
form Mrs Liskov spotlight. You can try to mitigate the mess by having
the Circles throw exceptions, return a success indicator, assert or
any other manner of error handling/notification, but someone who knows
they're dealing with an Ellipse may take it for granted that these
fundamental operations are always successful and not even read the
documentation let alone check for and handle failure. It's a bad
design in that what's intuitively certain may not work. That level of
presentation of the problem is not so vague and arbitrary that it is
"best discussed given a specific set of requirements for a programming
task" as you've suggested. That is the starting point for
discussion. If you don't get that far, then you're not addressing
yourself to the same problem. It is from an understanding of that
conflict that alternative modeling can be explored, and that's where
things might get vague - although in practice it's not so difficult to
have a reasonably tight and meaningful discussion around this.

Regards, Tony


== 5 of 10 ==
Date: Tues, Feb 2 2010 10:50 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)


tonydee <tony_in_da_uk@yahoo.co.uk> writes:
>explore what happens when you map that conclusion most simply/naively
>into an object model: a Circle object as a special case (subclass) of
>a more general Ellipse. The answer is that you have Circles that
>can't do what is reasonable to ask of an Ellipse, namely, alter the
>ratio of width to height, without ceasing to be Circles. You hide

Such an object does not truly model a circle, because a
circle cannot be modified. Instead it seem to model a
circle storage, which is something different from a circle.

The essential property of an ellipse storage is an ellipse
/requirement/: It requires a value to be an ellipse (in order
to become accepted for storage). Since every circle is an
ellipse, every ellipse requirement R also accepts circles. Thus:

x e C ==> x e E (if x is a circle, then x is an ellipse)
R a C <== R a E (if R accepts ellipses, then R accepts circles)

The transition from objects to requirements is what actually
inverts the direction of the arrow above. It happens to apply
to stores, because stores for type T require values to be of type T.

>form Mrs Liskov spotlight. You can try to mitigate the mess by having
>the Circles throw exceptions, return a success indicator, assert or

You are calling something a �Circle� here, what is really a
�circle storage�. This is like calling a numeric variable a
�number�: It is alright as long as you know that it really is
storage, not a value.

== 6 of 10 ==
Date: Tues, Feb 2 2010 11:23 pm
From: tonydee


On Feb 3, 3:50 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> tonydee <tony_in_da...@yahoo.co.uk> writes:
> >explore what happens when you map that conclusion most simply/naively
> >into an object model: a Circle object as a special case (subclass) of
> >a more general Ellipse.  The answer is that you have Circles that
> >can't do what is reasonable to ask of an Ellipse, namely, alter the
> >ratio of width to height, without ceasing to be Circles.  You hide
>
>   Such an object does not truly model a circle, because a
>   circle cannot be modified.

Indeed :-).

> Instead it seem to model a
>   circle storage, which is something different from a circle.
>   The essential property of an ellipse storage is an ellipse
>   /requirement/: It requires a value to be an ellipse (in order
>   to become accepted for storage). Since every circle is an
>   ellipse, every ellipse requirement R also accepts circles. Thus:
>
> x e C  ==>  x e E      (if x is a circle, then x is an ellipse)
> R a C  <==  R a E      (if R accepts ellipses, then R accepts circles)
>
>   The transition from objects to requirements is what actually
>   inverts the direction of the arrow above. It happens to apply
>   to stores, because stores for type T require values to be of type T.

The issue is not with storage: an ellipse can store a circle. But
your statement "if R accepts ellipses, then R accepts circles" is
wrong, given a function R that accepts an ellipse by reference and
attempts to change its height:width ratio. That's the flaw in the
naive OO model... itself an important insight, but again -
understanding this is primarily a basis for discussing how to model
Circles and Ellipses in a more inherently robust fashion....

> >form Mrs Liskov spotlight.  You can try to mitigate the mess by having
> >the Circles throw exceptions, return a success indicator, assert or
>
>   You are calling something a Circle here, what is really a
>   circle storage . This is like calling a numeric variable a
>   number : It is alright as long as you know that it really is
>   storage, not a value.

Wrong. I clearly defined "Circle" and "Ellipse" above in terms of
naive OO modeling, in which Circle is subclassed from Ellipse and
therefore inherits its Ellipse storage.

Regards,
Tony


== 7 of 10 ==
Date: Tues, Feb 2 2010 11:25 pm
From: Nilone


On Feb 1, 6:23 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >It has been solved by me some years ago - I don't know if
> >anyone else has published this solution, but I guess so:
>
>   I have been looking around and found:
>
> http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_...)
>
>   Using the terms from this article, I can define a function:
>
>       *: T -> T*
>
>   that maps a type T of values to a type T* of storage cells
>   for such values, and the essential assertion then becomes:
>
>       * is contravariant.
>
>   That is, using <= from this article:
>
>       square     <= rectangle, but
>       rectangle* <= square*.
>
>   So, obviously, many computer scientists are aware of
>   contravariance - just some authors of web articles about
>   the square-rectangle problem are not.

Why do you disable archiving of your posts, Stefan? I think these are
important points.


== 8 of 10 ==
Date: Tues, Feb 2 2010 11:27 pm
From: Nilone


On Feb 3, 8:50 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> tonydee <tony_in_da...@yahoo.co.uk> writes:
> >explore what happens when you map that conclusion most simply/naively
> >into an object model: a Circle object as a special case (subclass) of
> >a more general Ellipse.  The answer is that you have Circles that
> >can't do what is reasonable to ask of an Ellipse, namely, alter the
> >ratio of width to height, without ceasing to be Circles.  You hide
>
>   Such an object does not truly model a circle, because a
>   circle cannot be modified. Instead it seem to model a
>   circle storage, which is something different from a circle.
>
>   The essential property of an ellipse storage is an ellipse
>   /requirement/: It requires a value to be an ellipse (in order
>   to become accepted for storage). Since every circle is an
>   ellipse, every ellipse requirement R also accepts circles. Thus:
>
> x e C  ==>  x e E      (if x is a circle, then x is an ellipse)
> R a C  <==  R a E      (if R accepts ellipses, then R accepts circles)
>
>   The transition from objects to requirements is what actually
>   inverts the direction of the arrow above. It happens to apply
>   to stores, because stores for type T require values to be of type T.
>
> >form Mrs Liskov spotlight.  You can try to mitigate the mess by having
> >the Circles throw exceptions, return a success indicator, assert or
>
>   You are calling something a Circle here, what is really a
>   circle storage . This is like calling a numeric variable a
>   number : It is alright as long as you know that it really is
>   storage, not a value.

My apologies for contradicting your archiving wishes by quoting you.
I really do want to keep posts like these around.


== 9 of 10 ==
Date: Tues, Feb 2 2010 11:54 pm
From: tonydee


On Feb 3, 4:23 pm, tonydee <tony_in_da...@yahoo.co.uk> wrote:
> On Feb 3, 3:50 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >   The essential property of an ellipse storage is an ellipse
> >   /requirement/: It requires a value to be an ellipse (in order
> >   to become accepted for storage). Since every circle is an
> >   ellipse, every ellipse requirement R also accepts circles. Thus:
>
> > x e C  ==>  x e E      (if x is a circle, then x is an ellipse)
> > R a C  <==  R a E      (if R accepts ellipses, then R accepts circles)

Apologies for saying this statement of requirement was wrong...
reading bits of your post piecemeal as I responded, I lost sight of
the fact you'd specifically defined R as a requirement _on the
storage_, and not a more general requirement re functionality/
interface....

That misunderstanding aside, your model seems to do nothing more than
also suggest a "class Circle : public Ellipse" naive modeling. It
only gets interesting in light of the expected set_height_width(...)
or similar member in Ellipse, which by having an error case
necessarily breaks the expectation that the interface be fully
intuitive and safe.

(Personally, I think a "try_to_set_height_width(...)" or similar is a
practical compromise, ensuring client usage is cued to investigate the
potential failure condition....)

(There's also the even more naive model of "class Ellipse : public
Circle", too obviously broken to be interesting).

Regards,
Tony


== 10 of 10 ==
Date: Wed, Feb 3 2010 12:10 am
From: tonydee


On Feb 2, 1:47 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Stefan Ram:
>
>
>
> > r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >> It has been solved by me some years ago - I don't know if
> >> anyone else has published this solution, but I guess so:
>
> >   I have been looking around and found:
>
> >http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_...)
>
> >   Using the terms from this article, I can define a function:
>
> >       *: T -> T*
>
> >   that maps a type T of values to a type T* of storage cells
> >   for such values, and the essential assertion then becomes:
>
> >       * is contravariant.
>
> >   That is, using »<=« from this article:
>
> >       square     <= rectangle, but
> >       rectangle* <= square*.
>
> >   So, obviously, many computer scientists are aware of
> >   contravariance - just some authors of web articles about
> >   »the square-rectangle problem« are not.
>
> Not sure if I follow the above, it looks like obfuscation.
>
> I discussed the ellipse/circle problem in my "pointers" tutorial, which is now
> off-web. Perhaps I should put it on Google docs. Essentially, as you point out,
> it is about an immutable-values-view versus a modifiable-variables view.
>
> And yes, understanding it is essential for understanding the Liskov substitution
> principle (contra-variance and co-variance), and it ties in with "const" in C++.
> It also ties in with "in", "in/out" and "out" in languages that support such,
> e.g. the partial support in C#.
>
> Cheers,
>
> - Alf

Hi Alf,

I would agree that the problem only arises for mutable values, but I
wouldn't agree that the problem is _about_ constness/mutability.
Still, enforced constness may be a legitimate solution, encouraging
robust usage... whether it's actually more natural and intuitive for
developers may depend upon their educational background and
experience....

I do hope you'll have time to put your articles back online....

> For C++ the only such support is half hidden and
> very limited, namely co-variance for pointer or reference function results.

Good point - an explicit way to mark "out" parameter would be great.
Tuples and structs help somewhat but can be clumsy.

Regards,
Tony

==============================================================================
TOPIC: MySQL connector/driver behaviour with Visual C++ CLR/CLI project
http://groups.google.com/group/comp.lang.c++/t/738ca35dc8623177?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 2 2010 8:48 pm
From: 0


Hello. i'm having an issue getting the MySQL connector/driver to
behave proberly with a Visual C++ CLR/CLI project.... my issue is
best described by this screen capture: http://img97.imageshack.us/i/mysqlissue.jpg/

The host name that MySQL is trying to resolve is a series of strange
characters.... certainly not the "string" that is passed into the
connector function. The exception handler is saying: Unknown MySQL
server host 'U‹ìWVS ì ' (11004)... clearly it is not trying to
connect to tcp://bluetech

Has anyone see this? Could it have to do with language/character sets
or something? I've already tried: this->con = this->driver->connect
(L"tcp://bluetech:3306",L"SC",L"SC"); but, the connect function is
looking for a std::string.

Can someone please help me?

Thanks!


== 2 of 2 ==
Date: Tues, Feb 2 2010 9:22 pm
From: Dann Corbit


In article <7e24d166-16db-4953-b819-0e26231bf068
@u41g2000yqe.googlegroups.com>, jeffrey.whiteside@gmail.com says...
>
> Hello. i'm having an issue getting the MySQL connector/driver to
> behave proberly with a Visual C++ CLR/CLI project.... my issue is
> best described by this screen capture: http://img97.imageshack.us/i/mysqlissue.jpg/
>
> The host name that MySQL is trying to resolve is a series of strange
> characters.... certainly not the "string" that is passed into the
> connector function. The exception handler is saying: Unknown MySQL
> server host 'U?ìWVS ì ' (11004)... clearly it is not trying to
> connect to tcp://bluetech
>
> Has anyone see this? Could it have to do with language/character sets
> or something? I've already tried: this->con = this->driver->connect
> (L"tcp://bluetech:3306",L"SC",L"SC"); but, the connect function is
> looking for a std::string.

Guess: I wonder if you have the project type defined correctly.

Under the "Solution Properties"/General tab, check to see if character
set is what you want (you might try mbcs if it is unicode and that is
not what is wanted, for instance).

I guess that you will have better fortune asking VC++ specific questions
of this nature in one of the Microsoft programming groups.

HTH

==============================================================================
TOPIC: Static member vs global variable
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Feb 2 2010 9:02 pm
From: Suneel VLN


Hi all,

Below example is the from the famous C++ book "Thinking in C++, Vol
1".

#include <iostream>
using namespace std;
int x = 100;

class WithStatic
{
static int x;
static int y;
public:
void print() const
{
cout << "WithStatic::x = " << x << endl;
cout << "WithStatic::y = " << y << endl;
}
};

int WithStatic::y = x + 1;
int WithStatic::x = 51;

int main()
{
WithStatic ws;
ws.print();
}

Output is...

WithStatic::x = 51
WithStatic::y = 52


My questions are...

1. Why local x took precedence over global x?
2. Even though local x initialized after local y initialization, how x
value updated when initializing y?

Can anybody explain me this behavior?

Thanks in advance.
--Suneel VLN.


== 2 of 4 ==
Date: Tues, Feb 2 2010 10:00 pm
From: Rolf Magnus


Suneel VLN wrote:

> Hi all,
>
> Below example is the from the famous C++ book "Thinking in C++, Vol
> 1".
>
> #include <iostream>
> using namespace std;
> int x = 100;
>
> class WithStatic
> {
> static int x;
> static int y;
> public:
> void print() const
> {
> cout << "WithStatic::x = " << x << endl;
> cout << "WithStatic::y = " << y << endl;
> }
> };
>
> int WithStatic::y = x + 1;
> int WithStatic::x = 51;
>
> int main()
> {
> WithStatic ws;
> ws.print();
> }
>
> Output is...
>
> WithStatic::x = 51
> WithStatic::y = 52
>
>
> My questions are...
>
> 1. Why local x took precedence over global x?

Because that's how the standard defines it. The variable in the closest
scope is used.
BTW: I wouldn't call it "local". That term is normally used for variables
defined within a function.

> 2. Even though local x initialized after local y initialization, how x
> value updated when initializing y?

For objects with static storage duration, there are two types of
initialization, static and dynamic. static initialization is done before
dynamic initialization, and if a constant expression is used for an object
of POD type, the initialzation is static. 51 is a constant expression, so x
is initialized statically, while x + 1 is not a constant expression, so y is
initialized dynamically.

== 3 of 4 ==
Date: Tues, Feb 2 2010 10:27 pm
From: Suneel VLN


On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
> Suneel VLN wrote:
> > Hi all,
>
> > Below example is the from the famous C++ book "Thinking in C++, Vol
> > 1".
>
> > #include <iostream>
> > using namespace std;
> > int x = 100;
>
> > class WithStatic
> > {
> > static int x;
> > static int y;
> > public:
> > void print() const
> > {
> > cout << "WithStatic::x = " << x << endl;
> > cout << "WithStatic::y = " << y << endl;
> > }
> > };
>
> > int WithStatic::y = x + 1;
> > int WithStatic::x = 51;
>
> > int main()
> > {
> > WithStatic ws;
> > ws.print();
> > }
>
> > Output is...
>
> > WithStatic::x = 51
> > WithStatic::y = 52
>
> > My questions are...
>
> > 1. Why local x took precedence over global x?
>
> Because that's how the standard defines it. The variable in the closest
> scope is used.
> BTW:  I wouldn't call it "local". That term is normally used for variables
> defined within a function.
>
> > 2. Even though local x initialized after local y initialization, how x
> > value updated when initializing y?
>
> For objects with static storage duration, there are two types of
> initialization, static and dynamic. static initialization is done before
> dynamic initialization, and if a constant expression is used for an object
> of POD type, the initialzation is static. 51 is a constant expression, so x
> is initialized statically, while x + 1 is not a constant expression, so y is
> initialized dynamically.

I am little bit confused with this statement...

> Because that's how the standard defines it. The variable in the closest
> scope is used.

static x is a private member inside a class. How come it was in
closest scope at that line?

> For objects with static storage duration, there are two types of
> initialization, static and dynamic. static initialization is done before
> dynamic initialization

in such case during static initialization will y be initialized to 0?

Thanks,
--Suneel VLN.


== 4 of 4 ==
Date: Tues, Feb 2 2010 10:43 pm
From: tonydee


On Feb 3, 3:27 pm, Suneel VLN <suneelsuns...@gmail.com> wrote:
> On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
> > For objects with static storage duration, there are two types of
> > initialization, static and dynamic. static initialization is done before
> > dynamic initialization
>
> in such case during static initialization will y be initialized to 0?

I don't think the Standard guarantees that... my recollection is
compilers are free to use uninitialised/reclaimed memory for static
variables that are to be dynamically initialised. That would seem
more efficient - why initialise something twice?

Cheers,
Tony


==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

No comments: