It's an integral part of the operating system! How else are Microsoft going to crush those iD Software guys if they're not bundling their own games in for free with the OS?
I know perfectly well what a preprocessor is. Moc is not the same as 'the' preprocessor, but it takes as source a language that is not C++, and generates C++. I call that processing. It happens before compilation, and is therefore preprocessing.
It takes a language in which 'slot' (IIRC) is a reserved word, and one that does not respect namespaces etc, and produces C++.
VisualC++'s application wizard doesn't process a source file to produce its code, so your analogy is rather seriously flawed.
I would expect that the Qt people would agree that Moc is a form of preprocessor, as I do credit them with having a clue:)
GTK-- is not GTK+
on
GTK-- vs. QT
·
· Score: 5, Interesting
A lot of people seem to have missed that the question was asking for opinions on GTK-- (now gtkmm), not GTK+. The difference being that gtkmm is the C++ interface to GTK+, so no C vs C++ dilemma exists here - both are C++.
Well, nearly. If you're from a standard C++ background (as I am), you will find gtkmm preferable, as they don't reinvent parts of the standard library (eg QList vs std::list), they use namespaces and templates (including giving familiar, STL-style interfaces to container widgets etc), and it's implemented entirely in C++ (whereas Qt is in a C++ like language that must be first preprocessed to produce C++).
But, as someone before me said; get both, try them, see which you prefer - there are obviously people who disagree with me, as KDE and Qt are popular.
#pragma is evil - anything after the #pragma is implementation defined. This means that #pragma blah on one compiler might do one thing and something else entirely on another.
You can't conditionally use it per compiler since it's at the pre-processor level. (You can't #ifdef out #endif, for example.)
_Pragma is nicer, however, as you can do:
#if <test for GCC>
#define BLAH _Pragma whatever
#elif <test for other compiler supporting such enlightenment>
#define BLAH whatever
#endif
BLAH
Unfortunately I don't know of any other compilers that realise this, so you're sort of stuffed. Most of them allow #pragmas to be ifdef'd out which is nearly as good.
Re:FOR loops: a question, ANSI C++, C++98, C++99..
on
GCC 3.0 Released
·
· Score: 1
Actually, MSVC has a command line switch that turns on the correct behaviour (that i goes out of scope at the end of the loop). It's just that if you turn it on it can't compile it's own headers, so it's somewhat useless...
The C Programming language was originally standardised in 1989, and this was known as C89 (and also as C90 - long story...)
In 1999, the C language was updated with some new features and library functions. This is now known as C99.
Slashdot Mirror
It's an integral part of the operating system! How else are Microsoft going to crush those iD Software guys if they're not bundling their own games in for free with the OS?
Sourcesafe. 'Nuff said.
...it's too bloody cold. It probably wants a trip somewhere warm. Perhaps a short stay in the south of france or something.
Wasn't it the BBC who had a snooker cue camera a while ago? ISTR it worked quite well until the player chalked it...
I know perfectly well what a preprocessor is. Moc is not the same as 'the' preprocessor, but it takes as source a language that is not C++, and generates C++. I call that processing. It happens before compilation, and is therefore preprocessing.
:)
It takes a language in which 'slot' (IIRC) is a reserved word, and one that does not respect namespaces etc, and produces C++.
VisualC++'s application wizard doesn't process a source file to produce its code, so your analogy is rather seriously flawed.
I would expect that the Qt people would agree that Moc is a form of preprocessor, as I do credit them with having a clue
A lot of people seem to have missed that the question was asking for opinions on GTK-- (now gtkmm), not GTK+. The difference being that gtkmm is the C++ interface to GTK+, so no C vs C++ dilemma exists here - both are C++.
Well, nearly. If you're from a standard C++ background (as I am), you will find gtkmm preferable, as they don't reinvent parts of the standard library (eg QList vs std::list), they use namespaces and templates (including giving familiar, STL-style interfaces to container widgets etc), and it's implemented entirely in C++ (whereas Qt is in a C++ like language that must be first preprocessed to produce C++).
But, as someone before me said; get both, try them, see which you prefer - there are obviously people who disagree with me, as KDE and Qt are popular.
#pragma is evil.
#pragma is evil - anything after the #pragma is implementation defined. This means that #pragma blah on one compiler might do one thing and something else entirely on another. You can't conditionally use it per compiler since it's at the pre-processor level. (You can't #ifdef out #endif, for example.) _Pragma is nicer, however, as you can do: #if <test for GCC> #define BLAH _Pragma whatever #elif <test for other compiler supporting such enlightenment> #define BLAH whatever #endif BLAH Unfortunately I don't know of any other compilers that realise this, so you're sort of stuffed. Most of them allow #pragmas to be ifdef'd out which is nearly as good.
Actually, MSVC has a command line switch that turns on the correct behaviour (that i goes out of scope at the end of the loop). It's just that if you turn it on it can't compile it's own headers, so it's somewhat useless...
The C Programming language was originally standardised in 1989, and this was known as C89 (and also as C90 - long story...) In 1999, the C language was updated with some new features and library functions. This is now known as C99.