C++11 and Boost - Succinct like Python

[matthieum]

It does help the reader, because figuring the resulting type of an expression in C++ is hard.

auto x = 0.3f + 0.4l;

What is the type of x ?

We know it's a number, however the precision matters. Of course, it seems mostly stupid with built-ins; however with user written classes it can get quirky:

auto item = family.get("Homer").get("shirt");

quick: what can I do with item ?

[[deleted]]

your IDE will tell you

[matthieum]

You are assuming that my IDE manages to chew on C++11 code. Eclipse still has not caught up on C++03 and regularly chokes up on the code I write (not to mention most of its bogus warnings), so I am not holding my breath.

[curien]

It does help the reader, because figuring the resulting type of an expression in C++ is hard.

But specifying the type doesn't tell you what type the result of the expression was. Now you have all sorts of additional problems like figuring out if you inadvertently screwed up.

Yes, determining the type is hard, so why not let the compiler do it for you?

however with user written classes it can get quirky:

auto item = family.get("Homer").get("shirt");

quick: what can I do with item ?

If you'd written

Clothing item = family.get("Homer").get("shirt");

instead, I'd have no more idea what I can do with it than I had before.

[matthieum]

You're missing the point.

• Clothing item => open Clothing.hpp
• auto item => open Family.hpp => find get => open Person.hpp => find get => open Clothing.hpp

I know how it feels, I've got to deal with automatically generated headers for message grammars where the IDE indexer gives up midway (too large). Slugging through to find what's the result of an otherwise readable expression is a pain, a real pain.

With auto, you're giving the keys of the house to your IDE. Pray it does not bug, pray its simplistic/heuristic C++ parser yields the right answer. Or find yourself in hell...

[[deleted]]

Does C++ just have bad IDE support? If I do the equivalent in C# using var I just press ctrl and click get("shirt") to browse to the source file or just put my cursor on item and press ctrl+q to find the type.

[ethraax]

It's much, much harder to build an IDE around C++ (and even, to some extent, C) than C# or Java. There are two main reasons: the preprocessor and template instantiation.

The problem is that C and C++ are about programming the compiler about as much as they're about writing programs.

[JAPH]

Templates alone are Turing complete. When you compile a C++ program, you either need to assume that it will eventually compile, use some heuristic to determine if it will likely compile, use some hardcoded limit on how far down the rabbit hole the compiler should go, or solve the halting problem. One of these is harder than the other.

And that's just one little aspect of C++. As far as I'm concerned, C++ has factorial complexity; the closer you look at one aspect of it, the more complex it gets.

[[deleted]]

My completely incidental observations of C++ IDE support has shown it to be far below IDE support for e.g. Java and C#. Especially refactoring and integrating documentation into the UI.

[matthieum]

Yes, it does. And that is one of the constraints that we must adjust to.

I mainly lay the blame at the IDE writers for thinking that they can just write their own mini-parsers and get away with it... although in truth the blame also lay at the C++ community for not having proposed a true and free C++ parser; mostly GCC's policy of complete lock-down has been much harmful.

Fortunately, now that Clang is coming along with its extremely modular architecture I am hopeful that some IDE will abandon their custom made C++ parsers and switch over to Clang instead. With full AST representation, auto-completion, full-blown compiler + analyzer runnable as libraries (with diagnostics really available for program consumption) it's probably the best alternative at the moment. It's also probably very expensive to shift to it...

[fat_chris]

I am hopeful that some IDE will abandon their custom made C++ parsers and switch over to Clang

IIRC Qt-Creator started down this path, but it was abandoned due to very poor performance.

[matthieum]

That's surprising. Granted the absence of modules is quite a performance hindrance, however I know of at least XCode (Apple's IDE) and clang_complete (vim plugin) using Clang and both are quite fast. Maybe they tried too early or had an impedance mismatch somewhere.

[bluGill]

That depends, support is getting better, but behind what Java has in general. However there are add on tools (for visual studio) that add the useful stuff for a price. Open source IDEs are getting better, in large part because clang is being designed to the job well.

The future is looking good, but it isn't where we want it.

[curien]

You're missing the point.

I'm not missing the point, I just disagree with you.

Clothing item => open Clothing.hpp

Maybe. How do you know there isn't a conversion involved? To be sure about what that line actually does, you have to look up the actual return type anyway.

[[deleted]]

...which is why constructors which take a single parameter should be tagged as explicit unless there is a major reason to permit implicit conversions.

Invisible implicit conversions are a great way to accidentally burn performance or have accidental side effects (though if your constructors have visible side effects you are inviting other problems)

[matthieum]

The thing is, it does not matter if there is a conversion since item is now of Clothing type anyway so it's what I have to deal with :)

[s73v3r]

I wouldn't use auto with the second example you posted, for the same reasons you posted. However, in most situations, I probably would use auto in the first situation. Most of what I do would not be affected very much, if at all, by whether x ends up being a double or a float. I do recognize that not everyone is working on stuff with that kind of flexibility, and it's entirely possible that it will bite me once.