Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Dynamic Windows 3.3 Status Update
#11
So a couple of updates... first in response to your issue with the tree code... I double checked and 3.3 now requires ARC be enabled. So the old instructions telling you to disable ARC are now incorrect. I'll update the instructions in the repository to remove the part about disabling ARC.

Second, regarding the C++ bindings, still a lot to go but the foundation is there... which was the hard part. Over the next few days I'll be implementing most of it not all of the Dynamic Windows functionality in the C++ classes. Then I'll rewrite the dwtest program in C++ as an example, that might take until after Christmas though, but hopefully before New Years. The first week of January will be spent getting 3.3 ready for release and squishing any last minute bugs.

The status of the C++ bindings is looking a bit better than I had hoped. While to accomplish everything I intended it looks like the C++11 standard will be required. However, I have managed to get it compiling on old compilers like GCC 4.2 (MacOS 10.5) and MSVC 2005 (Windows 2000). A few features get disabled when using those super old compilers but it is still completely functional to my surprise.

Every single platform that Dynamic Windows currently supports now supports the C++ bindings with one or more compilers.
Reply
#12
Ok on closer examination, the feature I really want to include... lambdas... I have really started to love lambdas from using them in the Go bindings and in newer Objective C code. However that feature requires C++11 support, and if I make that mandatory, that may rule out a number of those old compilers... I'm going to start implementing it, but if some of those old compilers, (GCC 4.2 and MSVC 2005 I am thinking about specifically) fail to work I will either have to make dual versions of the test program. One that uses subclasses for the signal handlers and one that uses lambdas. The other option is to just focus on the lambdas version and exclude the platforms that don't support them.

Update: I did some research and it looks like lambda support requires GCC 4.5 and MSVC 2010... so that would exclude Windows 2000 support and Mac PPC support at least. They would still support the subclass method, but the lambda method is out. https://www.cprogramming.com/c++11/c++11...sures.html

Thoughts anyone?
Reply
#13
(12-22-2022, 12:29 AM)dbsoft Wrote: Ok on closer examination, the feature I really want to include... lambdas...
Thoughts anyone?

I've made progress with Pascal for iOS - got the program running on simulator, which means it _should_ also work on real devices. "Real Soon Now." ™ Currently working on getting CMake to generate a correctly configured Xcode project, the goal being to automate (and thus make scriptable) as much as possible.

To get Pascal to work with dwindows on iOS, I had to replicate, in Pascal, some of the C code generated by dw.h's macro expansion of dwmain(), and then also export _dw_main_thread() as an API to be used from Pascal.

For the purpose of building language bindings, C is the lingua franca, so as long as dwindows continues to provide a C API, then, sure, go ahead and use the full power of C++.
Reply
#14
(12-28-2022, 05:01 PM)PierceNg Wrote: To get Pascal to work with dwindows on iOS, I had to replicate, in Pascal, some of the C code generated by dw.h's macro expansion of dwmain(), and then also export _dw_main_thread() as an API to be used from Pascal.

For the purpose of building language bindings, C is the lingua franca, so as long as dwindows continues to provide a C API, then, sure, go ahead and use the full power of C++.

Awesome work! Can't wait to see the result.

Yes the C API is not going anywhere, the C++ bindings are just a wrapper around the C API. Smile
Reply
#15
Okay, not sure if any of the people who requested the C++ bindings are still around. However I have completed a port of the test program to C++ using the new bindings I just created. I still have some bugs to fix and to make sure it doesn't leak... but if anyone interested in the C++ bindings can take a look and see what they think... C++ has not been my language of choice and I may not know the best way to do things.  I'm considering it alpha quality at the moment and subject to change.

There are a few changes I am considering before declaring it beta... like switching from "const char *" to std:: string if all the compilers will support it... and maybe changing HTREEITEM to be an Object-oriented class. (I did not do that since unlike normal widgets it is difficult to detect when a tree node is destroyed).
Reply
#16
I pushed out my 3.3 release, just wanted to update the final requirements. Despite basic lambda and other support in earlier compilers, through testing I have determined that GCC 5, Clang 3.3 and Visual Studio 2015 are required for full C++ support. Older compilers may build the bindings with reduced support, forcing a more simple version of the test application. I consider the C++ support alpha for now and subject to change as I get more feedback.

I was able to get it built with some compiler on all supported operating systems except for Windows 2000, which may still be possible, but I struggled to find a MinGW32 that still worked on Windows 2000, and I am not entirely sure what the use case would be for Windows 2000 at this point anyway. OS/2, Windows XP, PPC Mac are all supported by installing updated GCC compilers GCC 5 or later.

Also I promoted the platforms iOS and GTK4 to stable, Android remains at beta level due to a few outstanding bugs, performance and stability problems, but I hope to have Android promoted to stable for the next release.

Update: I was able to find a MinGW32 that supported Windows 2000: https://osdn.net/projects/mingw/ and was able to get the C++ binding built with it, however it was missing some Windows header files and I had to disable RICHEDIT and HTML to get it to build (and a couple minor modification that have now been committed).
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)