From: John Torjo <john.lists@torjo.com> Subject: Re: [boost] Re: Points vs Vectors / GUI Library Proposal for
To: boost@lists.boost.org Message-ID: <418F48F8.9050002@torjo.com> Content-Type: text/plain; charset=us-ascii; format=flowed
Back on the subject of a GUI library: I understand the motivation - that's where wxWindows arose. And I realise that nowadays a GUI library could be done in a much more modern C++ style. But my question is: is C++ the right language? I don't want this to descend into a religious war - C++ is my favourite language, but it isn't the best language for
I would say so ;) For instance, you can abstract away a lot of stuff (true binding of data to GUI controls): http://www.torjo.com/win32gui/save_dlg.html
Also, I want to allow, in the future, to bind STL containers directly to GUI list controls.
So, I would say a higher level language won't be of help here - because you would need to convert your data and send it back and forth.
Yes - this was the one major benefit that I could think of when I wrote my original reply. But once you've exposed the data in question to the scripting language of your choice, you gain quite a bit: - By attaching validation routines and the like in your scripting layer, you can tune these without having to rebuild your program, or even restart it if you're lucky. - You can plug data and validation routines into UI elements using your UI design tool! - You can also expose the resulting bindings at the application level for things like scripting support.
I remember the days when I used to do the UI in VB - it was quite a mixed feeling...
Yes, I can see how that might put one off 'higher-level' languages :)
every task. Would a higher-level, more dynamic language be more suitable for GUI work? In a perfect world, I'd do all my back-end stuff in C++
sometimes, certainly
and all the front-end development in, say, Python. By doing all the GUI work in C++ instead of an interpreted language, you: a) spend a lot more time recompiling.
that is unfortunately true :(
b) can less easily tweak a running program to try out different ideas.
We're missing a good GUI designer... But we're slowly getting there ;)
The GUI designer can't help with attaching data, validation routines or anything else, unless those things are exposed to script.
c) have to spend a lot of effort to construct a domain-specific language (c.f Spirit; see (a)).
Not sure what you mean...
Spirit goes to great lengths to make C++ look like a language for declaring grammars. It's a huge chunk of beautifully crafted template magic, that's clearly taken much time and effort. Because of its size, recompiling the parser you build with spirit takes a very long time (hence the reference to (a)). A parser generator such as ANTLR does the same job much quicker[1]. Similarly, you've constructed an elegant way of linking data, validation routines and UI elements together, from C++. Your usage examples are concise and expressive. But does that justify the sheer weight of header files that they require? One could write probably less than half as much code to deliver similar results using Pyrex and Python. It wouldn't run quite as fast as your code. But it would give a smaller, more versatile runtime. In fact, there's an embryonic project to do just that at: http://nz.cosc.canterbury.ac.nz/~greg/python_gui/
d) probably end up with a bigger codebase.
why so?
Because C++ isn't the tersest of languages :) George