Programming

Are the following equivalent?

Code:

  static int  df, dl, du, count;

Code:

  static int  df;
  static int  dl;
  static int  du;
  static int  count;

Unless you're relying on undefined behavior, then yes, absolutely.

Wish granted: Your mildly cryptic and explanation-devoid statement simply compels me to ask, what part of the above do you think may be associated with undefined behaviour?

I have to say, posting such a statement only seems designed to confuse the original poster without explaining much...

That he asks the question implies he may have found a difference and is seeking to explain why. Without seeing what he's done, it's hard to explain what he's done.

Or I may be reading too much into it. I do that sometimes.

If the application is assuming that based on the location in memory of dl (&dl) it "knows" the address of df or du and makes use of that knowledge to get the value of df or to store a value into du that application will produce undefined results. This is true even though there is a good chance that with a little testing the user can figure out how a given compiler will arrange the locations of the integers declared by:

Code:

static int  df, dl, du, count;

or by:

Code:

static int  df;
static int  dl;
static int  du;
static int  count;

There is probably a much better than 50% chance that the two above ways of declaring these variables will result in them being allocated in the same positions relative to each other, but there is a non-zero percent chance that some compilers would allocate them in reverse order (or alphabetic order by name or some other order) in memory.

Any application that makes an assumption like this is depending on undefined behavior. As Corona688 said: Is it possible that an assumption like this could change the behavior of a section of code? Absolutely.
Is it likely that an assumption like this would change the behavior of a section of code? Who knows?

Saying code like that "depend[s] on undefined behavior" is too kind. Anyone who writes code that assumes the location of a variable based on the location of another variable is bat-!*()% crazystupid.

FWIW, multiple definitions on one line are a bad idea for other reasons, too.

What's this mean:

Code:

char* ptrA, ptrB;

Code:

char* ptrA, ptrB;

declares an object of type pointer to char named ptrA and an object of type char named ptrB. It also means that I will never hire the programmer that wrote this. Either they don't understand the rules of C or C++, or they don't understand that you shouldn't name a variable ptrx unless that variable is declared to be a pointer type (unless they're entering some kind of code obfuscation contest).

There is nothing wrong with declaring multiple objects with a single declaration (whether or not it is on one line or spread across several lines).

When writing code, use a set of style guidelines and be consistent. And if the guidelines you use aren't "common practice", make sure that anyone who will ever need to maintain your code also has a pointer to a written set of the guidelines used.