15 comments

[ 2.7 ms ] story [ 35.1 ms ] thread
No mention of Solaris Studio, which is something I've always been curious about. Unlike most (all?) of those others it can use a completely different compiler than gcc or clang.
Speaking of Solaris, I'd love if dbx was available on linux.

I haven't used it in years, and don't even remember what was so great about it, I just remember it seemed a lot better than gdb at the time.

dbx was terrible. I often resorted to gdb on Slowlaris.
> Speaking of Solaris, I'd love if dbx was available on linux.

From the dbx wikipedia page:

DBX is included as part of the Oracle Solaris Studio product from Oracle Corporation, and is supported on both Solaris and Linux. It supports programs compiled with the Oracle Solaris Studio compilers and GCC.

The only reason I haven't played with this to satisfy my curiosity is that they are pretty specific about what distributions they support, and they don't support mine.

I'd be so hesitant to use the sun compiler unless I had the source code in hand or sun was under contractual obligation to fix bugs. Does it come with its own source?

Perhaps I've simply been scarred by the nineties, but back in the day /opt/SUNWspro was an extremely rich source of mysterious WTFs and much profanity.

I use it all the time. In my experience, it produces much more optimized code that the alternatives (which seems to be true for the UNIX vendor's compilers in general as well)... and as I work on a large-scale system that must perform well, that alone is sufficient reason to use it.

It has definitely had its annoying moments from time to time tho.

I use Nemiver simply because I don't need to have an ide installed to use it.

Ease of setup makes Nemiver really good for when you need to debug something, but don't use an ide with an integrated debugger..

It's frustrating reading about this and seeing that it makes all the same mistakes as all these other gdb frontends that make them impossible to use with the standard library.

What the hell is this https://people.gnome.org/~dodji/vids/variable-tooltip.ogg ? It's supposed to be showing off how amazing the inspect variable tooltip is but I still have to dig through a veritable warren of template members just to find the underlying value. At least tell me I can write and install my own pretty printers if needed.

This appears to be reviewing IDEs with debugger frontends, not debuggers themselves, though a few integrated commercial debugger packages make a showing among the gdb frontends. Just a heads-up.
Funny how IDEs (Eclipse, Netbeans) written in Java and used primarily for Java development turned out to be the most functional C++ debuggers and beat dedicated C++ debugger frontends.
It's not that funny. Java has reflection mechanisms and C++ has nearly none unless you (ab)use the macro system. This gives Java a huge leg-up when it comes to GUIs.

C++ developers who are interested in better GUI development should work with the standards commmittee's reflection subgroup (SG7), which is headed by Chandler Carruth. I haven't been involved there, but I think it's important work for various domains including this one and database abstraction layers.

https://isocpp.org/std/the-committee

Can you explain a little why reflection is important in GUI development?
To be clear, in any Turing-complete language you can do anything (more or less). However, many things often require a lot of boilerplate, especially involving metadata: Does it display text? How do you get its name? Does it have its own thread? Does it have any XML-configurable attributes?

Often, especially in C++, that boilerplate is created through code-generating tools (like WYSIWYG editors), which is fine for many use cases... all of the metadata, getters, setters, and wiring logic are churned out for you. There are drawbacks to that approach, including many of the same limitations to WYSIWYG HTML/CSS tools (which I guess is a special kind of GUI development).

One way to improve the situation is to allow for more compile-time and/or runtime dependency injection in C++ code. It's not a silver bullet, but it's a tried-and-true model for other kinds of frameworks in various languages. In other words, why don't we see a Sinatra or a Spring in C++ land? Some people may think this is a feature, not a bug, but I submit the lack of those types of frameworks is due to a limitation of the language, not a lack of interest.

To get to the point of C++ GUI frameworks, however, some basic building blocks are needed. Especially of note are reflection mechanisms. For example, attributes on types, functions, and objects that can be inspected in code (constexpr or not).

This is a fairly involved subject worthy of a series of blog posts (with examples) instead of a single comment in a comment thread. But I hope I got the general idea across.

Many of the usecases where reflection is used could be also addressed with metaprogramming. This is probably why so many C++ GUI frameworks still use C macros and/or code generators. So I guess C++ not only needs reflection, but also much better metaprogramming capabilities. Template metaprogramming is considered awesome by some academics (being accidentally Turing-complete), but in fact it is quite limited compared to good macro systems.