Concurrent variable declaration

Recently, in trying new/different compilers, I've noticed some have different rules about when you can and cannot declare variables. Most newer IDE's seem to let you declare a variable anywhere you want, whereas some older IDE's complain and will only allow you to declare variables in chunks that directly follow the beginning of a scope. What's the deal with this? Are the old IDE's just being sticklers, or are the new IDE's violating some programming standard that says you should declare all variables at the top of a scope?

You are probably compiling files as C++, not C - MS Visual C++ 2005 (C/C++
compiler) complains about this code when compiled as C, not when compiled as
C++.

Code:

---

#include <stdio.h>

int main (void)
{
        printf ("A number: ");
        int num = 101;
        printf ("%d\n", num);

        return 0;
}

---

Confirmation from tutorial 1 on this site!

In C++ you can declare variables almost anyway besides as part of an expression as far as I
know, but all variables MUST be declared BEFORE use - same in C and C++

C, when originally specified, only allowed declarations before any executable statements (or, as you describe it, at the top of a scope), so compilers were obviously required to enforce it. This was true up to and including the 1989 C standard.

The ability to declare a variable after executable statements was actually a feature that was introduced in C++, and then adopted by some C compilers and then introduced in the 1999 C standard.

The net effect is that a compliant C compiler should not allow declaration of variables after executable statements unless it is compliant with the 1999 C standard. And there are a lot of C compilers that predate 1999. One complication is that there were quite a few C compilers before 1999 that are/were actually C++ compilers. Not all of those compilers could be forced to compile as C rather than C++, so they will accept C code with variables declared after executable statements.

So generally, is this a good, bad or neutral thing? Should I feel guitly that my compiler lets me "get away" with this? Or should I feel justified in using a newer C standard?
(p.s. the compilers that let me declare anywhere are CodeBlocks and Dev-C++, whereas Quincy 99 does not)

C99 is not widely supported yet, but it will be better supported eventually. I
suppose it's no harm to use the more up to date standard, but be aware of
potential problems when porting to another compiler.

>So generally, is this a good, bad or neutral thing?
It's a bad thing. If you're unwittingly producing non-portable code, it's always a bad thing. When you write something non-portable, it should be with full knowledge and intent.

>Or should I feel justified in using a newer C standard?
Until C99 becomes more widely implemented, it's best to restrict yourself to a common subset of features available in both C89 and C99. That's not terribly difficult because you can use good style C89 and you're pretty much there. :) The bad news is that you need to have at least a passing familiarity with the standard.

Quote:

---

Originally Posted by @nthony

So generally, is this a good, bad or neutral thing?

---

None of these. It's a language feature. If you use it well, it's a good thing. If you abuse it, it's a bad thing. If you use it in a way that makes little difference one way or the other .....

Personally, I find it a good thing, but I tend to use it in C++ rather than in C code. And in C++ it is a good feature, as it allows control over when an object is created. As long as I don't abuse the feature :)

Quote:

---

Originally Posted by @nthony

Should I feel guitly that my compiler lets me "get away" with this? Or should I feel justified in using a newer C standard?

---

That's up to you. If you only ever use compilers that support this feature, and don't give your code to someone who uses different compilers, there is no need to feel guilty about using this feature. If, however, there is any potential your code will be ported to a compiler that doesn't use this feature, then you should never use it.

Incidentally, it is quite easy to get the same control over lifetime of variables, even if your compiler does not support this feature. For example;

Code:

---

int main()
{
    /* assume we have a compiler that supports this */
    function();
    int x = some_result_we_could_not_compute_before_calling_function();
    some_other_function_call(x);
}

---

is functionally equivalent to;

Code:

---

int main()
{
    /* assume we have vanilla C 89 compiler */
    function();
    {
        int x = some_result_we_could_not_compute_before_calling_function();
        some_other_function_call(x);
    }
}

---

In fact, if you look at behaviour of some older compilers that converted early versions of C++ into C (where the C compiler didn't support this behaviour), you will find they did this sort of simple translation.

> Most newer IDE's seem to let you declare a variable anywhere you want, whereas some older IDE's complain
First you need to understand the difference between
- A language, as defined by an ISO standard.
- An implementation of that language, typically the compiler and linker.
- An IDE which is a collection of compatible tools (editor, debugger, help files) which have bugger all to do with the language at all. For example, you can write code using notepad, and compile it with the compiler which comes with Visual Studio. It makes no sense to say "I compiled it with notepad".

> Should I feel guitly that my compiler lets me "get away" with this?
It doesn't matter, so long as it's an informed choice.
You can only have an informed choice if you actually know the language as documented by the standards, rather than from your observations of a particular implementation.

> p.s. the compilers that let me declare anywhere are CodeBlocks and Dev-C++, whereas Quincy 99 does not)
Again, an IDE is not a compiler.

It's also the portability of that mush between your ears that you also have to worry about, even if you've no intention of compiling your current project on another platform. You could be in programming for a very long time, and it's something worth taking the time to get right.
I've used countless C compilers, so I really have no time for any of the "foo works on the bar compiler".