FLTK 1.4 Released With Wayland & HiDPI Display Support

[anda_skoa]

Nope. Its not standard C++.

It is, no matter how often you mistakenly claim the opposite.

People don't just convolute their build systems with MOC for the fun of it haha.

Yes, they use a code generate for convenience and productivity.

You can #define many words in C++ to "nothing". Doesn't mean it will compile.

Of course it will.
When the pre-processor has removed something it is no longer part of the input that is passed to the C++ tokenizer.

This is neither magic nor rocket science.
If you open a text editor and do a search&replace with the replace being empty, then the result is the same document without the word you searched for.

Likewise, if you don't pass your code through MOC first, the software will not compile.

The whole point of using C pre-processor macros as syntactic sugar is to ensure that the marked-up code is still valid C++.

Anyone who has built a Qt program and looked at the build output will have seen that each C++ source file is passed unaltered to the C++ compiler.

The MOC steps are additional, if needed at all (when a class declaration contains the Q_OBJECT or Q_GADGET macro)

Yeah, you get these kinds of errors obviously. Very easy to verify:

https://stackoverflow.com/questions/3607262/why-wont-this-compile-link-with-the-q-object-macro-in-place

Great demonstration that the compilation has worked nicely without the involvement of moc.

The error is about missing symbols at the linking stage, because the person had used a macro to declare function in a header but forgot to provide the implementation.
Easiest way for that is to let moc generate those implementations but as with any other code generator there is always the option to write the code manually.

The build process wouldn't have gotten to linking if the compiler had not been able to build the various translation units first.

Anyway, as I said earlier there is no shame in falling for this misunderstanding.
Many people who come from languages without pre-processor don't have prior experience with the this type of automatic text replacement.

I guess you are coming from a JavaScript/TypeScript situation which requires a separate tool to transform the actual source into something the target interpreter can understand.

In C and C++ there is a built-in step that is essentially a search&replace.
The most common use is the "#include" statement which gets replaced by the content of the file that follows.

Qt uses this mechanism to provide input for a code generation tool while at the same time keeping the code consumable by a C++ parser.

Some of these macros get replaced with nothing, i.e. effectively removed. For example "emit" or "slots"
Some get replaced with a C++ key word. For example "signals" gets replaced with "public"

Some are more complex and expand into declarations of functions or types. For example "Q_OBJECT".

The C pre-processor is quite versatile in this regard.
C code usually sees more use than C++ code but even the latter regularly makes use of "#include", "#ifdef", "#define".

Many C/C++ APIS ship related "#define" statements as part of their headers.
On a Linux system you can easily look for those by searching for "#define" in /usr/include

Edit: unsurprisingly FLTK uses the same mechanism.

For example "FL_OVERRIDE" gets either replaced with C++ keyboard "override" (if the C++ compiler is new enought) or replaced with nothing.

FL/forms.H has several defines that expand into function definitions, e.g.

#define forms_constructor(type,name) \
inline type* name(uchar t,int x,int y,int w,int h,const char* l) { \
return (type*)(fl_add_new(t, new type(x,y,w,h,l)));}

These things are so common that I doubt there are C/C++ developers who have not used them, let alone seen.
Many, if not most, will even have written them.

[Vistaus]

The FL in FLTK stands for fast and light, things GTK and Qt are not ...

Yeah, as an end-user I love Qt and wouldn't ever touch GTK with a ten-foot pole, but I wouldn't call Qt "fast and light" by any means. The closest Qt that is "FL" is TQt from the Trinity Project, but otherwise, not so much. But even then, FLTK is a little bit faster and especially a lot smaller in size. (Plus the look-and-feel is more human-like.) So I can see a market for FLTK, especially when size matters or when the app is meant to run fluid on low-end or old devices.

But as an end-user, I do prefer Qt and TQt myself. However, FLTK is great in its own way and I would gladly use it if I had an app that used it.

[Modu]

It is, no matter how often you mistakenly claim the opposite.


Yes, they use a code generate for convenience and productivity.


Of course it will.
When the pre-processor has removed something it is no longer part of the input that is passed to the C++ tokenizer.

This is neither magic nor rocket science.
If you open a text editor and do a search&replace with the replace being empty, then the result is the same document without the word you searched for.


The whole point of using C pre-processor macros as syntactic sugar is to ensure that the marked-up code is still valid C++.

Anyone who has built a Qt program and looked at the build output will have seen that each C++ source file is passed unaltered to the C++ compiler.

The MOC steps are additional, if needed at all (when a class declaration contains the Q_OBJECT or Q_GADGET macro)


Great demonstration that the compilation has worked nicely without the involvement of moc.

The error is about missing symbols at the linking stage, because the person had used a macro to declare function in a header but forgot to provide the implementation.
Easiest way for that is to let moc generate those implementations but as with any other code generator there is always the option to write the code manually.

The build process wouldn't have gotten to linking if the compiler had not been able to build the various translation units first.

Anyway, as I said earlier there is no shame in falling for this misunderstanding.
Many people who come from languages without pre-processor don't have prior experience with the this type of automatic text replacement.

I guess you are coming from a JavaScript/TypeScript situation which requires a separate tool to transform the actual source into something the target interpreter can understand.

In C and C++ there is a built-in step that is essentially a search&replace.
The most common use is the "#include" statement which gets replaced by the content of the file that follows.

Qt uses this mechanism to provide input for a code generation tool while at the same time keeping the code consumable by a C++ parser.

Some of these macros get replaced with nothing, i.e. effectively removed. For example "emit" or "slots"
Some get replaced with a C++ key word. For example "signals" gets replaced with "public"

Some are more complex and expand into declarations of functions or types. For example "Q_OBJECT".

The C pre-processor is quite versatile in this regard.
C code usually sees more use than C++ code but even the latter regularly makes use of "#include", "#ifdef", "#define".

Many C/C++ APIS ship related "#define" statements as part of their headers.
On a Linux system you can easily look for those by searching for "#define" in /usr/include

Edit: unsurprisingly FLTK uses the same mechanism.

For example "FL_OVERRIDE" gets either replaced with C++ keyboard "override" (if the C++ compiler is new enought) or replaced with nothing.

FL/forms.H has several defines that expand into function definitions, e.g.

#define forms_constructor(type,name) \
inline type* name(uchar t,int x,int y,int w,int h,const char* l) { \
return (type*)(fl_add_new(t, new type(x,y,w,h,l)));}

These things are so common that I doubt there are C/C++ developers who have not used them, let alone seen.
Many, if not most, will even have written them.

After I read your posts, I concluded that Vala is standard C code. Brilliant!

[kpedersen]

Great demonstration that the compilation has worked nicely without the involvement of moc.

Compilation hasn't worked nicely. The code required to link wasn't even generated in the first place. You have taken another step backwards and now don't even have the code.

So by your incorrect logic, the works of Shakespeare is standard C++

$ cat shakespere.txt | grep "MOC IS A BROKEN CONCEPT" > main.cpp
$ c++ main.cpp
(linker error, missing main entry point... but it compiled!)

Either way, good luck with whatever you class as standard C++. I do feel a little sorry for the poor guy that needs to clean up the mess after you.

After I read your posts, I concluded that Vala is standard C code. Brilliant!

Haha, indeed. The guy is clearly confused.

[Nth_man]

Several myths that some people still say... were debunked years ago: https://woboq.com/blog/moc-myths.html

[anda_skoa]

After I read your posts, I concluded that Vala is standard C code. Brilliant!

Something must have changed significantly since I've tried Vala couple of years ago.

Back then its syntax would not have been valid for a C compiler and you needed valac to generate C code.

valac back then was something you could consider an additional pre-processor or transpiler.

At which version did they remove the need for this?

[anda_skoa]

Compilation hasn't worked nicely.

I clearly has, otherwise the build would not have progressed to the linking stage.

Well, I guess since you have no experience with C/C++ that could also be confusing to you.

Building a program which consists of multiple files is usually done in steps.

Each source file (also referred to as a translation unit) is compiled into an object file.
These are then linked together to form the library or executable.

Some build system suppress verbose output by default but when they don't do that you can see the compiler being invoked for each translation unit.

Often looks like this

c++ -c -o myclass.o myclass.cpp

For a Qt program this is no different. The macros that might be used in myclass.h or myclass.cpp have been resolved by the compiler pre-processor.

If myclass.h contained the Q_OBJECT macro you will additionally see the invocation of the code generator

moc -o myclass_moc.cpp myclass.h

and, following that, the compilation of that with the normal compiler

c++ -c -o myclass_moc.o myclass_moc.cpp

Again no pre-processor involved other than the one the compiler has built-in.

The resulting files are then linked together

c++ -o myprogram myclass.o myclass_moc.o ....

In the Stack Overflow question this command generated an error.
The build would not have reached this command if any of the compilation commands had failed.

Since this is all new to you it might be easier to start with a single file example

#include <QtCore/QCoreApplication>
#include <QtCore/QTimer>

int main(int argc, char **argv)
{
    QCoreApplication app(argc, argv);

    QTimer::singleShot(1000, [&app]() { app.quit(); });

    return app.exec();
}
​

If you save that as, e.g. main.cpp, you can then compile and link it like this

g++ -o main main.cpp -I $QTDIR/include -L /dvl/Qt -L $QTDIR/lib -lQt6Core

assuming QTDIR is set to the correct prefix.

At no stage does this require moc to run, the macros in both QCoreApplication and QTimer headers are resolved by the compiler's built-in pre-processor just like it would resolve the ones defined by other libraries like FLTK.

Don't worry, once you have more C/C++ experience than basic tutorials this will not be a mystery to you either.

[rmfx]

This toolkit is great, it's just a shame that they do not implement a clean, simple and modern default theme (aka flat style, slightly rounded corner shapes with antialiasing),
and revamp their ugly website so that people are not turned off before even checking its api.

[Nth_man]

[...] If you save that as, e.g. main.cpp, you can then compile and link it like this

g++ -o main main.cpp -I $QTDIR/include -L /dvl/Qt -L $QTDIR/lib -lQt6Core

assuming QTDIR is set to the correct prefix.

If it may help, in my test I used:

​g++  -o main  main.cpp  -I /usr/include/x86_64-linux-gnu/qt5  -L /usr/lib/x86_64-linux-gnu/qt5  -l Qt5Core  -fPIC
​