Exercise

Don't use the compiler. Try to predict the behavior.

Code:

---

#include <iostream>

using namespace std;

class B
{
public:
  static int i;
  static int j;
};

static int i = 3;
int B::j = i + 5;
int B::i = 5;

int main()
{
  cout << "j == " << B::j << endl
      << "i == " << B::i << endl;
  return 0;
}

---

Fine, I'll bite.

j == 8
i == 5


Although I suppose this is not the answer, otherwise this would be a very dull post. What's the real answer?

Jeff

I'd have the same answer as jfaust

Quote:

---

Originally posted by proxima centaur
I'd have the same answer as jfaust

---

It is not the right answer. I also have been misled by that code.

Depends whether the line "int B::j = i + 5;" indulges in some form of Koenig lookup or similar. If not, B::j == 8, if it does, then all bets are off, since B::i has no value (or is it 0?) at the time of the statement.

The result will be:

j=10
i=5


....because b::i is initialized before b::j

Well, I tested the code on 2 different compilers,
GNU g++ and pgCC (Portland group).

Both gave the same answer, and the same answer that
kjetilh gave.

To be honest, I can not figure out why. Stroustrup says
that the variables will be initialized in the same order
as their definition, and makes a point of saying that it not being in
the same order as their declaration.

And when the definitions are changed to :

Code:

---

int B::j = i + 5;
int B::i = j + 5;

---

the results are consistent with Stroustrup's book.

yet, this is a bug or undefined result in VC++.

the i refered by

Code:

---

int B::j = i + 5;

---

is clearly the i from the global scope:

Code:

---

static int i = 3;

---

to obtain 8 as a result for B::j one has to replace i declaration with

Code:

---

int B::j = ::i + 5;

---

Now why is that? beats me.

Quote:

---

Originally posted by kjetilh
The result will be:

j=10
i=5


....because b::i is initialized before b::j

---

Explain! :)
How about this:

Code:

---

#include <iostream>

using namespace std;

class B
{
public:
  static int i;
  static int j;
};

int i, B::j = i + 5, B::i = 5;

int main()
{
  cout << "j == " << B::j << endl
      << "i == " << B::i << endl;
  return 0;
}

---

Oooooppppssss! You got the same result!

Quote:

---

Originally posted by proxima centaur
yet, this is a bug or undefined result in VC++.

the i refered by

Code:

---

int B::j = i + 5;

---

is clearly the i from the global scope:

Code:

---

static int i = 3;

---

to obtain 8 as a result for B::j one has to replace i declaration with

Code:

---

int B::j = ::i + 5;

---

Now why is that? beats me.

---

I use VC++ and I got the same results as Philip Nicoletti.

“An initializer for a static member is in the scope of the member’s class.” (TC++PL, 2nd edition). That is:

Code:

---

int B::j = i + 5; // equ int B::j = B::i + 5;

---

That's what I was thinking of when I suggested "something like Koenig lookup". In defence of the rule, it's like the way a member function definition bring things into scope in the .cpp file:

Code:

---

class foo
{
public:
    class innerclass;
    //.....
    void bar(innerclass&);
};

void foo::bar(innerclass& ic)
{....

---

In the definition, you don't have to qualify "innerclass", since it's brought into scope by "foo::bar".

With the example given, B::i has "tighter" scope than ::i, so is used in prefence. The only issue that I couldn't look up is whether B::i is initialised at that point (declaration order) or not (definition order). It just emphasises the point "define/initialise member variables in the same order that you declare them"

This is a stupid question.

Why would any one write a piece of code like this that could easily trick the majority of programmers ( and could trick the compiler just as easy, too). As shown in previous follow ups, most people gets it wrong.

As a member of a software development team, your responsibility is NOT to write a piece of "smart" code that only you can understand correct and that is deemed to be mis-interpreted by other programmers, and even mis-compilered by the compiler, too! If you do so it doesn't show you as smart, it shows you as stupid.

Your responsibility, is to write crystal clear code which leaves absolutely no room for ambiguity what you intend to do and what happens first and what happens next. It needs to be so readable that even a junior programmer can read and understand it correctly. This is how a software team can produce bug free software.

Anthony,

That's not the point of the post. It's a piece of trivia, a point of interest, a starting point for discussion.

This was obviously not production code. Why attack it?

Jeff

Anthony,

You are mean… and I suspect you love it! :D
I do not think you are so stupid not too see the point of this discussion. Relax! This is not an arena!
I am waiting for your explanations. So far I do not have any. This weekend I will give a look at Mr. Stroustrup’s book and maybe I’ll find the answer.
I am not good at English, so please be brief.

:) Thanks Jeff!

Even though it is not "good" coding practice, it is still relevant to some of us who like to look at the arcane side of things and understand the twitches of such and such obscure code.

Personally, even though I wouldn't in my right mind write a piece of code like this one, I find it interesting to understand how the compiler works. This can actually prevent me for doing stupid things in my code in the future.

Now, unless you wrongfully felt your pride diminished because you didn't get the answer right or because you feel you are far superior to the lesser of us because you know what "good" code is, please stop telling others how stupid they are, as I myself find your comment useless as it brings nothing as to why the compiler acts the way it does.

By the way, I totally agree with the rest of your comment.