Thread: C++ future features?

Do you know the difference between these things?
1. Programing Language
2. IDE
3. Compiler
4. Library
A. Standard Library
B. 3rd Party Library

Tim S.

Don't get me wrong, C++ is my cup of tea in just about everything, I just wonder if any of the listed above are planned to be implemented as standard in the next few years?

O_o

There is no actual standard for GUI utility interfaces, XML parsing interfaces, or JSON parsing interfaces. Virtually every library, language, and vendor provide such utilities in vastly different flavors. I could ask you several hundred questions about the design of a standard GUI toolkit, but everyone of those questions has a multitude of valid answer, and everyone I ask will give different answers. I'll ignore that complexity for something a bit simpler. So, what flavor of interface would you recommend the C++ standard implement?

Should the standard provide a DOM, SAX, or transforms XML parser? How do you handle massive documents with a DOM parser? You could throw an exception of a "out of memory" flavor or even repeatedly call `new' allowing the natural exception to propagate. How you validate the document? (An XML document without a schema, even if extremely general, doesn't have a known navigable DOM representation for retrieving information.) You could again throw an exception if the document doesn't have a valid schema. How do you represent the schema to the parser? Requiring that the schema be written with C++ is a terrible idea; do you use a DSEL for schema, an internal DTD schema, an external XSL schema? You could rely on an internal DTD schema using something like here-document from other languages. All of that is fine; you could instead go with a SAX parser, error codes, and an external XSL schema. How to interface these mechanisms for access by clients is an extremely complex problem plagued by politics.

I, for example, would say that both a DOM and SAX parser are required while many would refuse such duplicate measures as bloated.

Politics will likely continue to kill parsing, GUI, and utilities of similarly ambiguous format for years to come.

The standard will never require such components for all implementations. The standard will continue to allow implementations to conform to either the hosted or freestanding levels, and I assume such components would be provisioned as a third level. In practice, many distributions will not provide such components anyway as they are simply unnecessary for a lot of work.

*shrug*

Happily, you do not need such libraries to be standard.

Soma

Originally Posted by Dave11

generally , I think that Red and Microsoft are more attuned to their developer, hence succeed in bringing them better tools for the modern environment.

Microsoft doesn't have to go through 10 levels of bureaucracy to get something implemented, unlike the standard where they just meet 2-4 times per year. Maybe that will change if more interest is generated for C++, but until that day, this is reality.

Don't get me wrong, C++ is my cup of tea in just about everything, I just wonder if any of the listed above are planned to be implemented as standard in the next few years?

Network - yes, see Network TS. But I wonder if it's going to turn out well considering that it's based on Boost Asio, which in my opinion, is a piece of ****. But we already have a promising 3rd party library for RESTful APIs (i.e. networking with HTTP). It's called Casablanca. Very promising.
Anyway, GUI, no. There is a graphics subgroup, though. Maybe something will come out of that.
XML, JSON, etc - possibly with Network. I don't know. But I do know there are still good 3rd party libraries out there for that. Good ones I can think of is cereal, Boost.Serialization and Casablanca.

Originally Posted by Elysia

...Boost Asio, which in my opinion, is a piece of ****.

I agree that it's very cumbersome, and finding really helpful documentation and examples can be very tricky, but you have to realize that it was developed to be an all-encompassing, one-size-fits-all solution to serial and network communication across all platforms. As such, it's no surprise that it's so complex. I have recently been finding it increasingly useful.

I've worked for it for a while in search of a good network API. So I have some experience. Yeah, I even go it working. But I quickly ran into problems.
(Warning: this is strictly my opinion.)
First of all, it has a disgusting interface. Everything is in terms of buffers. If you have some type T, so have to serialize it first, then you have to send the length, and then the actual data and then the reverse on the reeving side.
And don't get me started on the actual sockets. For some reason, they just didn't want to close properly. I even looked into the destructor - and no, no implicit closing of the sockets.
Granted, I hear there are streams, but I'm not too familiar with them.
I even watched a talk at cppcon about asio, but stopped midway because I just got more annoyed with asio and the fact that the presenter was of the opinion "why use C++11 when C++03 still works?", I just dropped the talk midway.

Why all this complexity? I'd stuck with boost since I just couldn't get a server working.
But just recently I found something better. I'd been working with Casablanca for some while and it was just so good. Easy to use and it just worked (unlike boost).
Problem was that there wasn't really a server implementation. Just a client. The actual server couldn't actually accept external connections (i.e. non-localhost). But a nice wrapper by the name of nginx solved that problems beautifully.
So now I'm tossing boost asio out the window and adopting Casablanca full-time.

No idea what that's supposed to mean...

Still makes no sense.
If somehow the word "Casablanca" trips you up, google "C++ Casablanca."

I guess it is a reference from the film named after that city.

I don't do movie references.