Update the Qt headers to match modern Qt

[ghost]

As it seems they target Qt4. Qt4 has long EOL-ed. It's now the era of Qt5 and Qt6.

[VictorMiasnikov]

You can try run (?) m3swig[.exe] for QT6 . . QT3 *.inc

[ghost]

You can try run (?) m3swig[.exe] for QT6 . . QT3 *.inc

No I will not do it. I'm already a swig user (for Python and Java) and I know the pains. It's the maintainers should do it not me.

[VictorMiasnikov]

M3swig is hi modified variant.

} It's the maintainers should do it not me.

( Imho, maintainer of QT should, of course -) )

P.S. Maintainer of "big QT"

08.09.2022, 20:59, @." @.>:M3swig is hi modified variant.( Imho, maintainer of QT should, of course  -) >)08.09.2022, 20:20, "zpu2tw" @.***>:

You can try run (?) m3swig[.exe] for QT6 . . QT3 *.inc

No I will not do it. I'm already a swig user (for Python and Java) and I know the pains. It's the maintainers should do it not me.

[ghost]

@demoitem It's easy to modify your qinclude to support Windows. I have done it and it the build script worked.

@VictorMiasnikov His Qt binding is for Qt4 and doesn't work with Qt5. I tested with MSYS2's Qt5, it doesn't work. Try using swig to regenerate the wrapper also failed. This binding needs to be updated to be able to use with Qt5.

[VictorMiasnikov]

Please, public all worked source code. ( I'm again on smartphone) I have and qt4 binary ( non M3 specific part)

13.09.2022, 19:00, "pwd96m4a" @.***>: @demoitem It's easy to modify your qinclude to support Windows. I have done it and it the build script worked. @VictorMiasnikov His Qt binding is for Qt4 and doesn't work with Qt5. I tested with MSYS2's Qt5, it doesn't work. Try using swig to regenerate the wrapper also failed. This binding needs to be updated to be able to use with Qt5.

[VictorMiasnikov]

Are You has used "usual SWIG" or m3swig?

13.09.2022, 19:00, "pwd96m4a" @.***>: @demoitem It's easy to modify your qinclude to support Windows. I have done it and it the build script worked. @VictorMiasnikov His Qt binding is for Qt4 and doesn't work with Qt5. I tested with MSYS2's Qt5, it doesn't work. Try using swig to regenerate the wrapper also failed. This binding needs to be updated to be able to use with Qt5.

[demoitem]

I tried updating to qt5 a couple of years ago but it was a lot more complicated than I thought it would be since they changed some of the headers substantially. That, and the fact that the signals and slots interface was completely different. So I gave up.

I have been looking at CPPBind and modifying it to generate m3. It uses clang and ast matchers to generate bindings which could be a better solution.

Regards

On Wed, 14 Sept 2022 at 02:51, VictorMiasnikov @.***> wrote:

Are You has used "usual SWIG" or m3swig?13.09.2022, 19:00, "pwd96m4a" @.***>: @demoitem It's easy to modify your qinclude to support Windows. I have done it and it the build script worked. @VictorMiasnikov His Qt binding is for Qt4 and doesn't work with Qt5. I tested with MSYS2's Qt5, it doesn't work. Try using swig to regenerate the wrapper also failed. This binding needs to be updated to be able to use with Qt5.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1245681946, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABALZX76VN24GSXKYN5V3MTV6CWITANCNFSM6AAAAAAQHSMZNM . You are receiving this because you were mentioned.Message ID: @.***>

[jpgpng]

I have no idea why there are too many bindings for Qt in many languages even though it's assumed to be hard to make bindings for @3oheicrw? The Python guys have many Qt bindings available just for them a single language!

https://wiki.qt.io/Language_Bindings

[jpgpng]

About C libraries should be preferred, I don't really agree. C libraries are too low level that it's very difficult to use on M3 (and M2, too!). For example, they are using char in many places in their libraries. On M3 (and M2, too!), char can only be mapped to ADDRESS (which is a generic pointer type like void* on C I think?). Using C libraries with M3 (and M2, too!) is not safe at all IMO.

[jpgpng]

The fact is, Modula 3 seems doesn't support variadic functions like C. This make using of C libraries more limited on Modula 3!

https://en.cppreference.com/w/c/variadic

An example: https://cplusplus.com/reference/cstdio/sprintf/

[jpgpng]

FreePascal supports it as array of const: https://www.freepascal.org/docs-html/ref/refsu97.html

[jpgpng]

FreeBASIC supports it with the syntax very similar to C: https://www.freebasic.net/wiki/ProPgVariadicArguments

[VictorMiasnikov]

As I said, there is no version of swig available that could wrap Qt 😄 I used to try using swig to wrap CopperSpice (https://github.com/copperspice/copperspice) for a Python binding and also failed. I'm not yet try with this, though: https://github.com/woboq/verdigris But since it's still include standard Qt headers I think it will also failed 😄

Are You using m3swig for "Modula-3 tasks"?

[jpgpng]

And GNU Modula 2 supports it, too. Have a look at the example for printf: https://www.nongnu.org/gm2/12/interface_to_c.html

[jpgpng]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

[jpgpng]

@pwd96m4a I would suggest trying to make a M3 binding for the FOX Toolkit as I think it will be easier than Qt. Qt and CopperSpice both made use of modern C++ features heavily. The FOX Toolkit on the other hand is only requires C++11:

http://www.fox-toolkit.org/

[jpgpng]

There are problems with the FOX Toolkit, too. It made heavy use of macros (not as worse as CopperSpice though). Modula 3 doesn't support macros, so mapping to Modula 3 is extremely hard.

[VictorMiasnikov]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

Ada binding for QT6 . . QT4 exist. We can try do anologs.

[jpgpng]

About macros support on Modula 2. GNU Modula 2 will run the C preprocessor (cpp) to process it sources before compilation the same way as the C/C++ frontend. ADW Modula 2 also supports macros (in a more limited way, enough to wrap C libraries to use with Modula 2).

[jpgpng]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

Ada binding for QT6 . . QT4 exist. We can try do anologs.

I don't understand. It's too clear why you still not get it? @demoitem please explain to him what is the problem.

BTW, If there is no problems with swig why he (@demoitem) switched to CppBind I wonder @VictorMiasnikov?

[VictorMiasnikov]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

Ada binding for QT6 . . QT4 exist. We can try do anologs.

I don't understand. It's too clear why you still not get it? @demoitem please explain to him what is the problem.

BTW, If there is no problems with swig why he (@demoitem) switched to CppBind I wonder @VictorMiasnikov?

Using CppBind is "main way".

Personal I ready use QT4. And wait M3 binding for QT6 . . QT5

[VictorMiasnikov]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

Ada binding for QT6 . . QT4 exist. We can try do anologs.

I don't understand. It's too clear why you still not get it? @demoitem please explain to him what is the problem.

BTW, If there is no problems with swig why he (@demoitem) switched to CppBind I wonder @VictorMiasnikov?

demoitem is author of m3swig.

QT4 binding has built by early version of m3swig.

demoitem has problem with QT5 binding.

[jpgpng]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

Ada binding for QT6 . . QT4 exist. We can try do anologs.

I don't understand. It's too clear why you still not get it? @demoitem please explain to him what is the problem. BTW, If there is no problems with swig why he (@demoitem) switched to CppBind I wonder @VictorMiasnikov?

demoitem is author of m3swig.

QT4 binding has built by early version of m3swig.

demoitem has problem with QT5 binding.

This thread is anything but about Qt5/Qt6 binding? Qt4 is already EOL and no longer supported.

[ghost]

I think C libraries are easier to make bindings. I suggest this library over IUP as it's more simpler: https://github.com/dbsoft/dwindows

https://github.com/modula3/cm3/discussions/1057

https://github.com/modula3/cm3/issues/1067

[ghost]

Personal I ready use QT4.

Are you joking or serious? He stated very clearly on https://github.com/modula3/cm3/blob/master/m3-ui/qt/README. The current implementation of signals and slots is very clumsy alongside many other limitations. I don't think it's production ready.

[VictorMiasnikov]

I think C libraries are easier to make bindings. I suggest this library over IUP as it's more simpler: https://github.com/dbsoft/dwindows

1057

1067

Oh: I want write about this software too.

May be m3swig can create binding for it.

[VictorMiasnikov]

Are You using m3swig for "Modula-3 tasks"?

He said it very clear. Swig in general is unable to wrap Qt. Any versions of swig. Including your m3swig fork.

Ada binding for QT6 . . QT4 exist. We can try do anologs.

I don't understand. It's too clear why you still not get it? @demoitem please explain to him what is the problem. BTW, If there is no problems with swig why he (@demoitem) switched to CppBind I wonder @VictorMiasnikov?

demoitem is author of m3swig. QT4 binding has built by early version of m3swig. demoitem has problem with QT5 binding.

This thread is anything but about Qt5/Qt6 binding?

Yes, it is. ( QT4 is "small offtopic" -) )

Qt4 is already EOL and no longer supported.

I known.

[VictorMiasnikov]

Personal I ready use QT4.

Are you joking or serious? He stated very clearly on https://github.com/modula3/cm3/blob/master/m3-ui/qt/README. The current implementation of signals and slots is very clumsy alongside many other limitations. I don't think it's production ready.

I read this readme.

Today we found answer on question: "Where we are?"

It looks like that we can work with QT4. It can sense re-check this theory.

[ghost]

I will go back to Modula 2. This is a too limited language for me. Goodbye.

[ghost]

Anyone could confirm @3oheicrw and @jpgpng's statements about Modula 3 not supporting variadic functions and macros (preprocessing) please? I wanted to know about it. Thanks.

[ghost]

Anyone could confirm @3oheicrw and @jpgpng's statements about Modula 3 not supporting variadic functions and macros (preprocessing) please? I wanted to know about it. Thanks.

@VictorMiasnikov @mikanystrom @RodneyBates

[mikanystrom]

Modula-3 does not have a defined preprocessor. You can add one yourself through Quake if you really want to. We did for some very specialized types of programming, there may be examples in the tree.

Also no direct support for variadic functions, because they are hard to implement in a way that's both fast and safe. There are a few tricks to simulate varargs for functions, where it's useful. Look at Fmt.i3, especially F and FN. F uses default parameter values, FN uses the language support for arrays.

 Mika

On Wed, Sep 14, 2022 at 5:16 AM zpu2tw @.***> wrote:

Anyone could confirm @3oheicrw https://github.com/3oheicrw and @jpgpng https://github.com/jpgpng's statements about Modula 3 not supporting variadic functions and macros (preprocessing) please? I wanted to know about it. Thanks.

@VictorMiasnikov https://github.com/VictorMiasnikov @mikanystrom https://github.com/mikanystrom @RodneyBates https://github.com/RodneyBates

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1246677127, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYNJMICJYQZATHUC6CCPDV6G62LANCNFSM6AAAAAAQHSMZNM . You are receiving this because you were mentioned.Message ID: @.***>

[RodneyBates]

On 9/14/22 04:57, jpgpng wrote:

About C libraries should be preferred, I don't really agree. C libraries are too low level that it's very difficult to use on M3 (and M2, too!). For example, they are using char in many places in their libraries. On M3 (and M2, too!), char can only be mapped to ADDRESS (which is a generic pointer type like void* on C I think?). Using C libraries with M3 (and M2, too!) is not safe at all IMO.

Well, there is no way to make inter-language bindings for any language pair type-safe by any reasonable definition, without resorting to a single compiler that is partially multi-language itself.  It would have to know the high level-semantics of the types in both languages, the machine-level representations in both languages, and the ABI of both.  Moreover, for the latter two, the word "language" would have to actually mean language plus compiler, since different compilers for the same langauge can use different representations and ABIs.

The likely representations used by a typical C compiler are usually fairly obvious, which makes C bindings relatively simple.  But the representations and ABI for C++ dispatching virtual member functions (object type methods in Modula-3) are very much more complicated. And you sometimes really want to use these in a binding to C++ code.

This shows up in the bindings to LLVM's tree-building machinery, as used in Modula-3's LLVM backend.  LLVM's developers have provided bindings in C to some of this.  But by going through C, they completely lose the dynamically-typed pointers in LLVM, which are very extensively used.  This makes the binding process really messy and a lot more unsafe, if you will grant me the iffy concept of degrees of unsafety.

I have often thought about picking, say, gcc's, implementation of C++ and its representations and ABI, putting knowledge thereof into Cm3, so the dynamic typing can be preserved both ways across a binding. This is a big job.  Has anything like it been done elsewhere?

LLVM's developers are always keen to make earliest-possible, maximum use of C++'s ever widening ambiguities and semantic gaps between what something syntactically looks like and what it actually means.  So this could be an exceptionally difficult moving target.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1246523820, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNC7DBLP53BSVWP467TV6GOPJANCNFSM6AAAAAAQHSMZNM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[RodneyBates]

On 9/14/22 04:59, jpgpng wrote:

The fact is, Modula 3 seems doesn't support variadic functions like C. This make using of C libraries more limited on Modula 3!

https://en.cppreference.com/w/c/variadic

An example: https://cplusplus.com/reference/cstdio/sprintf/

C's variadic functions are a bit of a fraud.  While the syntax is indeed variadic, making it work semantically requires machine-level coding that is highly unsafe and highly compiler-dependent.  And the caller has to carefully avoid uncheckable mismatches among the actual parameters.

In Modula-3, you can accomplish the same thing, entirely safe on the call side and implementation-independent in the module.  For example, look at Fmt.F and Fmt.FN, found in:

  m3-libs/libm3/src/fmtlex/Fmt.i3

Using the open array version, you can make it just as general as in C. Since the parameters could be REFANY, you can wrap a mix of types for them too.  I have used this technique to cut way down on the size of tedious and boring code, while still getting the language to check for type errors, albeit some only at runtime.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1246526732, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNHPHERTZJYOKVADAXLV6GOYZANCNFSM6AAAAAAQHSMZNM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[RodneyBates]

On 9/14/22 05:11, jpgpng wrote:

About macros support on Modula 2. GNU Modula 2 will run the C preprocessor (cpp) to process it sources before compilation the same way as the C/C++ frontend. ADW Modula 2 also supports macros (in a more limited way, enough to wrap C libraries to use with Modula 2).

You can run cpp on anything.  A line of Quake code can do it in Cm3.

Macros are sometimes useful.  I would really like to expand something to Compiler.ThisLine, which would change meaning if moved into a called procedure.

That said, the bizarre interactions of cpp macro identifier scopes, include files, and programming language identifiers is a nightmare. You have to be awfully careful about the possibility of a macro identifier being the same as a language identifier, with no help from the cpp/compiler combination.

But there are other preprocessors that only substitute identifiers that are somehow tagged as such.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1246540912, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNHD75NPEDUNEMFEQHLV6GQGLANCNFSM6AAAAAAQHSMZNM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mikanystrom]

Why do we not seem to see each other's responses?

On Wed, Sep 14, 2022, 7:21 PM Rodney M. Bates @.***> wrote:

On 9/14/22 04:59, jpgpng wrote:

The fact is, Modula 3 seems doesn't support variadic functions like C. This make using of C libraries more limited on Modula 3!

https://en.cppreference.com/w/c/variadic

An example: https://cplusplus.com/reference/cstdio/sprintf/

C's variadic functions are a bit of a fraud. While the syntax is indeed variadic, making it work semantically requires machine-level coding that is highly unsafe and highly compiler-dependent. And the caller has to carefully avoid uncheckable mismatches among the actual parameters.

In Modula-3, you can accomplish the same thing, entirely safe on the call side and implementation-independent in the module. For example, look at Fmt.F and Fmt.FN, found in:

m3-libs/libm3/src/fmtlex/Fmt.i3

Using the open array version, you can make it just as general as in C. Since the parameters could be REFANY, you can wrap a mix of types for them too. I have used this technique to cut way down on the size of tedious and boring code, while still getting the language to check for type errors, albeit some only at runtime.

— Reply to this email directly, view it on GitHub < https://github.com/modula3/cm3/issues/1066#issuecomment-1246526732>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABSVZNHPHERTZJYOKVADAXLV6GOYZANCNFSM6AAAAAAQHSMZNM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1247078291, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYNJPQHLGXXSALQ7K4LPLV6ICR3ANCNFSM6AAAAAAQHSMZNM . You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

I decided to switch to Mulle ObjC (https://mulle-objc.github.io/). The reasons for Objective C is painless interroping with C. This implementation of Objective C is also Apple-free and cross platform. Objective C is also reference counted and there is no constructors too, just an init method like Modula 3. It's a bit hard to setup since I'm on Windows (having to compile everything from source). But now I had everything setup so I'm ready to go with it. Frankly speaking I wanted to go with Swift first. But I'm on Windows 7 and Swift only supports Windows 10+. There is a Swift implementation by RemObjects Silver but this implementation differed from the Swift of Apple, they even don't use the same standard library. So I decided to go with Objective C.

Goodbye everyone. And thank you for your helps.

[jpgpng]

I have often thought about picking, say, gcc's, implementation of C++ and its representations and ABI, putting knowledge thereof into Cm3, so the dynamic typing can be preserved both ways across a binding. This is a big job. Has anything like it been done elsewhere? LLVM's developers are always keen to make earliest-possible, maximum use of C++'s ever widening ambiguities and semantic gaps between what something syntactically looks like and what it actually means. So this could be an exceptionally difficult moving target.

The FreeBASIC project did exactly this and they have very limited success. See @3oheicrw's message above. This thread has too many answers so it's really hard to keep track.

[jpgpng]

Even though the same compiler (MinGW) is being used only the version differs, the C++ standard library is incompatible. So you can't use a C++ library compiled by an old version of MinGW with the current version of MinGW because the two libstdc++-6.dll will slash with each other. This new knowledge I just acquired today!

https://github.com/copperspice/copperspice/issues/217

p/s: this is unrelated to @RodneyBates's idea about implementing support for C++ ABI though. Just sth I think is useful and wanted to share.

[jpgpng]

Objective C is also reference counted and there is no constructors too, just an init method like Modula 3.

People on the ObjC world called these -init, -intWithInt,... as constructors too. There is no reasons for the Init method of Modula 3 to be not called as a constructor smile

They are called Class Initializers :smile:

[jpgpng]

As I said, there is no version of swig available that could wrap Qt smile I used to try using swig to wrap CopperSpice (https://github.com/copperspice/copperspice) for a Python binding and also failed. I'm not yet try with this, though: https://github.com/woboq/verdigris But since it's still include standard Qt headers I think it will also failed smile

Qt should be preferred. CopperSpice is full of macros so it's really difficult to wrap. It's also full of unresolved bugs. The team promised to solve it as soon as possible but they did nothing since 2020:

https://github.com/copperspice/cs_signal/issues/12

CopperSpice uses CS_Signal internally to power their signals and slots.

[jpgpng]

Qt is easier to wrap than CopperSpice. The MOC is not really an obstacle. See verdigris he mentioned above. If we can't wrap the signals and slots implementation of Qt, we can create our own signals and slots implementation on Modula 3 side too.

[jpgpng]

I hope someone could modify this tool to generate M3 binding from GIR:

https://wiki.freepascal.org/gir2pascal

https://github.com/n1tehawk/gir2pascal

It's used to generate the GTK+ headers of FreePascal.

[jpgpng]

Do not talking about C++ as it's too far a goal. Why there is not yet a tool to help generate M3 bindings from C headers? Swigm3 doesn't count. What swig generates is a complex human non-readable wrapper, these tools generate perfectly readable code:

https://www.freepascal.org/tools/h2pas.html

https://www.freebasic.net/wiki/DevBindingCreation

Please note that fbfrog (https://github.com/freebasic/fbfrog) is very powerful. Most of the C libraries headers of FreeBASIC now generated by it: https://github.com/freebasic/fbbindings

FreeBASIC used to rely on their swig3 fork to generate bindings but fbfrog has taken up the job. There is h_2_bi too.

[mikanystrom]

Reference counting is fairly limited compared to "real" garbage collection...

On Thu, Sep 15, 2022 at 5:09 PM zpu2tw @.***> wrote:

I decided to switch to Mulle ObjC (https://mulle-objc.github.io/). The reasons for Objective C is painless interroping with C. This implementation of Objective C is also Apple-free and cross platform. Objective C is also reference counted and there is no constructors too, just an init method like Modula 3. It's a bit hard to setup since I'm on Windows (having to compile everything from source). But now I had everything setup so I'm ready to go with it. Frankly speaking I wanted to go with Swift first. But I'm on Windows 7 and Swift only supports Windows 10+ so I gave up. There is a Swift implementation by RemObjects Silver but this implementation differed from the Swift of Apple, they even don't use the same standard library. So I decided to go with Objective C.

Goodbye everyone. Thank you for your helps.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1066#issuecomment-1248772360, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYNJLUMFDE32OGS5VOLYDV6O3DHANCNFSM6AAAAAAQHSMZNM . You are receiving this because you were mentioned.Message ID: @.***>

[VictorMiasnikov]

} m3swig can not generate human readable code.

Are You run pretty print m3pp?

P.S.

Try convert by m3swig LLVM 9.0.1 Or LLVM 10.0.1 headers.

And compare results with my or demoitem. My LLVM10 / LLVMv10 public as pool request.

After this convert QT 4.8.7 headers. And use this binding.

16.09.2022, 19:47, "jpgpng" @.***>: Do not talking about C++ as it's too far a goal. Why there is not yet a tool to help generate C bindings from C headers? Swigm3 doesn't count. What swig generates is a complex human non-readable wrapper, these tools generate perfectly readable code: https://www.freepascal.org/tools/h2pas.html https://www.freebasic.net/wiki/DevBindingCreation Please note that fbfrog (https://github.com/freebasic/fbfrog) is very powerful. Most of the C libraries headers of FreeBASIC now generated by it: https://github.com/freebasic/fbbindings FreeBASIC used to rely on their swig3 fork to generate bindings but fbfrog has taken up the job. There is h_2_bi too.

[VictorMiasnikov]

} Turbo Pascal and Delphi are ( . . .)

Delphi  ( and FPC / Lasarus) don't have Garbage Collector.

If You want try Oberon family language then see on Active Oberon, please.

16.09.2022, 18:45, "3oheicrw" @.***>: BTW, I'm about to leave Component Pascal (GPCP and CPIde) to go back to Free Pascal. The Wirthian languages IMO are too limited to use in real life so it's nothing strange they are not used widely. By Pascal I mean Object Free Pascal (aka the Object Pascal dialect of Free Pascal compared to the Object Pascal dialect of Delphi). Turbo Pascal and Delphi are corporate products, they are more practial than academic projects like the Wirthian languages. Borland/Embarcadero incorporated into them features needed for real life use so they are very comfortable to work with. I don't feel such comfortable with any Wirthian languages, including Component Pascal (the GPCP dialect of course, not the BlackBox Component Builder dialect). Long story short, goodbye.

[jpgpng]

Reference counting is fairly limited compared to "real" garbage collection...

BTW I always wanted to ask you how our GC compared to Boehm-GC? Most Oberon impl I know all use Boehm-GC.

[jpgpng]

} m3swig can not generate human readable code.Are You run pretty print m3pp?P.S.Try convert by m3swig LLVM 9.0.1Or LLVM 10.0.1 headers. And compare results with my or demoitem.My LLVM10 / LLVMv10 public as pool request. After this convert QT 4.8.7 headers.And use this binding.

I don't want to argue with you as I found you have the habit to ignore other's arguments. I will only tell you that with these tools you have an almost 1-1 very clean and compact mapping of the original C headers, no additional source files/headers are added and absolutely no Swig* types mess. Swig is about wrapping C++. These tools are specific to wrap plain C. Let it be clear.

[jpgpng]

Delphi ( and FPC / Lasarus) don't have Garbage Collector.If You want try Oberon family language then see on Active Oberon, please.

IMO it's about the syntax and the language that is limited, it's nothing to do with it's being GC-ed or not. I personally liked the Delphi syntax for OOP more. It's closer to C#/C++/Java, with construtors, destructors, classes,... what I'm already familiar with as I learned Java on University days. Another point about language limitation, Delphi has function overloading. So far I don't know any Modula/Oberon dialects have this. Because of that on Modula/Oberon world we have the mess called WriteCard, WriteInt, WriteReal,... and PutInt, PutReal,... when on Delphi there is only need just one overloaded function for all of these things.