C++ is an extension to C adding object support (classes): GObject is an extension to C adding object support. The difference is only that GObject does this in C while C++ does it in C++. I’ve done similar in C too because a project demanded it. It’s not much different than GObject simply because you can’t do it any way better if you are limited to C which GTK is. So no, GTK can’t do much better because it is limited to C but in the end C++ is just a sugar coated version of C with classes like ObjectC is or any other C based object class system.
2 Likes
I don’t think there needs to be a C hacker syndrome debate here.
GObject has additional runtime overhead compared to C++ classes.
1 Like
I doubt so, simply because C++ is C with syntactical sugar. It still compiles to C code with “ricks” (see name mangling).l So no, C++ is not “magic”. It cooks with the same water.
1 Like
C++ includes code generator and type checker that is not possible to implement in plain C and preprocessor. You must write more duplicating code and have higher risk of mistakes.
3 Likes
Yes, C++ contains code generator and type checker. But you can do this also in C with pre-compiler tools. At the end of the day a C++ class is nothing but a struct with member variables and function pointers.
That said I’m all for C++ for practical use. It makes coding easier and less error prone. But under the hood it’s C with fancy pre-compilers.
1 Like
Using an higher level language means the compiler can do higher level optimizations.
So, yes, in theory C can do almost everything. But the amount of code you would need to write manully and probably duplicate (or do a bit ugly things like x-macros or generate source files) means it’s not worth the effort and time. And so you often end up with sacrificing some runtime performance for maintenance simplicity. But the same is also true of C++
2 Likes
I’ve seen a lot of benchmarks, c++ typically out performs all but the most extensively optimized c at almost everything but binary size. The c++ library’s are very well designed and see constant improvement.
Which is a problem of the pre-compiler toolchain used. C doesn’t get any more development. It works fine for what it is used. The rest is better done in C++. I though dislike STL… but that’s because I’m from a game developer background 
Hmmm… the earlier C++ and ObjectiveC compilers took the respective code, generated C and compiled it with a C compiler. I don’t think any modern C++ or ObjectiveC compiler works like that any more. Because that is an extremely inefficient way to write a compiler. Most modern compilers compiler a superset of C and C++ syntax (depending on compiler switches and file extensions) and go from code directly from parser to AST then object code generation. C++ is no longer “syntactic sugar” on top of a C compiler, because C++ compilers are no longer a clever preprocessor on top of a C compiler. Take this bit of code:
#include <iostream>
using namespace std;
class X {
public: void emit(string s) { cout << s << endl; }
}
int main() {
X x1;
x1.emit("test 1");
auto x2 = new X2();
x2->emit("test 2");
delete x2;
return 0;
}
If you compile that with gcc -save-temps yourfile.cpp -o youtapp you end up with 2 extra files, one with .i or .ii as the extension and a .s file. Look at the .ii one… the code above is still there, despite a tonne of preprocessed code being added to the start. Because the C++ preprocessor has expanded all the magic from the C++ headers and put it inline, but the C++ code is still there intact at the end. If you remove the C++ iostreams and change to use stdio.h, a different set of preprocessed code is generated, but your class is still there at the end and your class is still not expanded to “a struct with function pointers”. Because any modern C++ compiler compiles to object code from C++, and the C++ is not converted to C first.
2 Likes
Thank you @memsom ! At last someone said it ! Of course modern C++, for many years now, is not just syntactic sugar over C.
1 Like
This doesn’t change the fact that C++ is syntactic sugar over C. Just because you make a compiler doing all in one go for efficiency reason doesn’t change the underlying fact.
1 Like
Well, clearly no. C++ is it’s own language and I would also point out that C code does not always cleanly compile as C++ (as in, you tell the compiler to compile C as if it was C++) because C++ has different rules about some syntax elements. If all we ever do is look at the outside and claim the internals are the same because the input and the output is similar, we are destined to never really understand anything. Clearly 
1 Like
Yeah, this is one of those things people always roll out. If it were true, C++ compilers would generate terrible code, a bit like Vala and other transpilers. Also, if one were actually to look at the C++ language specification, it would be abundantly obvious that no sane developer was doing it via a transpiler. Everyone can hate on C++, but it does stand on its own and has done for a long time now.
Then C is syntactic sugar over assembly by the same reasoning
4 Likes
No. Assembler is syntactic sugar over machine code. C++ is syntactic sugar over C. It is also stupid to use C files not compiling with C++ compiler as argument against the sugar coating. It’s like with Math. Just because you it’s true that “if it rains then the road is wet” you can’t claim the inverse to be true.
But I agree that this discussion is not getting anywhere soon. I’ve got better things to do with my time than repeating myself.
1 Like
Repeating a claim without any evidence does not make it any more true. Claiming the inverse would be “C is syntactic sugar over C++” (edit: technically the inverse would be the same statement beeing false, but that usage makes no sense in the above post, so I assume the same claim with switched partners is ment)
In this case the statement and it’s inverse are false, it is not a matter of a logical falacy. Just a matter of no proof existing for the original argument.
If your only argument is “you can construct a transpiler that can transpile this language to a different language while keeping some of the code” then congratulations: everything is syntactic sugar over javascript. I think we can agree this is not the case.
1 Like
I think the argument misses the point anyway:
- Even if C++ was only syntaxic “sugar”, that is a very important part of any language. It allows to write code that is more safe, because the syntax additions allow to have more compile-time checks (example: private fields in a structure)
- While it is somewhat true of early C++ implementations (C++98, and to some extent C++11), C and C++ are now drifting apart with every new version. C++ has already removed some C keywords (“register”) or completely changed what they do (“auto”, “static”)
- A large part of C++ is templates, which allow to do things far beyond what you could do in C. Is it possible to transpile them? Yes, probably. Does that mean they are just “syntaxic sugar”? I don’t think so. They allow to handle some problems in a completely different way. In recent versions of the language, “constexpr” was also added tomake sure some things are fully computed at compile-time.
So, yes, of course eventually it’s going to be machine code running on the same machine, and so, C and C++ (and pretty much any other language) can be used to implement things in a similar way. Yes, a lot of things you can do in C++ can also be done in C (and there are exceptions, for example coroutines are not possible in plain C, but were added to C++20). Some things would also be possible in theory, but unusable in practice (exceptions with stack unwinding, or simply automatic destruction of stack-allocated objects when exiting a function)
2 Likes
The funny thing is that C is full of syntactic sugar. But people tend to use it without knowing/caring. I can think of a few things:
- K&R style function definitions vs ANSI C. The latter is syntactic sugar, as the former functioned perfectly well.
- Any of the allocation shortcuts, such as
a++/++a,a--/--a, anda+=x,a-=xare just sugar and also can be implemented as straight code. The++/--cut out more code obviously, but the+=/-=etc are bure sugar. - The
->operator is also syntactic sugar. So,x->yis the same as(*x).y - The subscript operator is also syntactic sugar.
a[x]is the same as*(a + x).
(A lot of the above was robbed from the Wikipedia article Syntactic sugar - Wikipedia)
When does an established language feature become accepted? I guess when people stop trying to make out all that it is is a “syntactic sugar” and just accept things are kind of moving towards usability,. not verbose and complicated to understand syntax.
1 Like
Funny to see what this thread evolved into, I wrote it thinking about how I’ll use a Qt/GTK2 or native program in XFCE and it looks perfect and fits in with my theme, but I start using a GTK3 program and everything looks completely different down to literally the title bar which is just unacceptable, I never thought this would go into the deeper and more technological meaning of fragmentation between applications but with all due respect continue your conversations :P