Why C++ Sails When the Vasa Sank [pdf]

http://files.meetup.com/1455470/Why%20C%2B%2B%20Sails%20When%20the%20Vasa%20Sank.pdf

by dirtyaura • 12 years ago

112 212 12 years ago

files.meetup.com

Moral_• 12 years ago

Why do people insist on linking to slideshare? http://files.meetup.com/1455470/Why%20C%2B%2B%20Sails%20When...

dang• 12 years ago

Thanks. We changed to that from http://www.slideshare.net/yandex/why-c-sails-when-the-vasa-s....

thrownaway24242• 12 years ago

  auto y = std::move(x);

Is this good code? How do you review it? What's the type of y? Usually I would ask for at least one type statement per line. For example this seems ok to me, because the type is on the left.

  auto* x = new Foo();

But this doesn't seem ok:

  auto y = std::move(x);

octo_t2• 12 years ago

what about in the case of something like:

    auto it = std::find(vec.begin(), vec.end(), value);

thrownaway24242• 12 years ago

That doesn't bother me because std::find returns an iterator, and nobody wants to look at long STL iterator type names. But if the next thing were this:

  auto foo = *it;

... I would be sad.

Scorponok• 12 years ago

You should only really use "auto" when the type is clear (like in your example #2). If it's not clear, you should probably specify the type so that it's more obvious what's going on. #1 and 3 are probably fine if x is defined right above y, but maybe not if they're at the bottom of a long function or similar.

Iftheshoefits• 12 years ago

Like anything else in a language in which the syntax and other features permit writing correct code that is difficult to maintain or decipher, your objection has to be handled by a human being (or well-designed analysis tool) at the "meta" level (e.g. by code style guidelines/policies).

I agree "auto y = std::move(x)" is (likely) poor coding practice. I only use "auto" basically as a shorthand (e.g. instead of writing "hand_crampingly_long_container_iterator_type v = std::fn(c.begin(), ....)).

I have mixed feelings about "polluting" the namespace with "useless" typedefs and similar aliases versus using "auto". The former leads to very explicit code, but lots of extra "overhead." On the other hand, "auto" is much more powerful than a convenient in-place alias as I've described, and I've rarely found myself in the position of looking at code and having to truly ponder over the type of an "auto" variable. On the other other hand, seeing a lot of either may indicate something else about the code and whether it ought to have a design review. It's (somewhat) subjective.

RogerL5• 12 years ago

Do you allow this to pass code review (ignoring the bad name 'foo')?

  foo (A*x);

'A * x' creates a temporary with no documented type, but the conceit here is that we don't care. They could be ints, floats, matrices - any data type that implements '*'. By and large that is fine.

Here you are just moving x to y. What is the type of y? the same type as x, which supposedly didn't cause you heartache throughout the rest of the function.

Stroustrup gave an interesting talk this year about how, everytime he introduced a new feature, people complained that it was not clear and asked for very verbose syntax. Instead of foo<T>, we get template<typename T> foo<T>(T, well, you get the idea. Now everyone is familar with templates and loath the verboseness.

Back to auto, it allows for 'generic' programming. Do you object to templated functions?

  template<class T>
  T add (T a, T b)
  {
     return a + b;
  }

That seems really clear to me, as is the auto version:

   auto add (auto a, auto b)
   {
      return a + b;
   }

If that is clear, why is

   auto x = a + b;

unclear? I can certainly come up with counterexamples where it isn't clear, but by and large I love auto, and use it all the time. (counterexample: we care about the type of x because we need to cast to a 16-bit int because it is going to be use to communicate with hardware).

plorkyeran• 12 years ago

we care about the type of x because we need to cast to a 16-bit int because it is going to be use to communicate with hardware

IMO you should still use auto there and use a static_cast<int16_t> on the RHS to make it clear to the reader that you're deliberately converting it.

yongjik• 12 years ago

Problem arises when we find "y" deep in a function, searches for its definition, and encounters "auto y = std::move(x);". Now we have to know the type of x, and if x is defined similarly, up the chain. Not fun.

foo(A * x) doesn't pose similar problem. On the other hand, if I write

    auto bar = foo(A*x);

Then we can have the same problem (esp. if foo is a templated function).

maxlybbert7• 12 years ago

While C++ programmers are still getting used to type inference, it's not really a new concept. It's been in other languages for decades.

Personally, I avoided type inference in C# for a long time. But I never ran into a bug caused by type inference. While C#'s (and C++'s) type system isn't as advanced as Haskell's, if you screw up the types you generally get a compiler error. If "auto y = std::move(x)" compiles, then why do you care what type y is? You know it's the same type as x, and you can do anything with y that you could have done with x.

There's really nothing to fear.

millstone3• 12 years ago

Consider this simple code to swap the first two items of a vector:

    vector<T> foo = ...
    auto tmp = foo[0];
    foo[0] = foo[1];
    foo[1] = tmp;

When T is int, it swaps as expected. But when T is bool, instead of swapping, it copies the second item over the first, with nary a warning. And I'll wager you could stare at that code all day without spotting the bug.

So yes, be afraid.

fleitz• 12 years ago

The types are immaterial to the operation, the important thing is the move, not the type line noise.

100982• 12 years ago

I think it depends on context, I like using auto when the type is clear from the surrounding 5-7 lines of code or if it's for some nested-container-iterator stuff. The rule of thumb is, if the context doesn't provide enough information about types to deduce what the inferred type for `auto' will be after a quick glance, then don't use auto.

wmkn2• 12 years ago

Scott Meyers (the author of this presentation) makes a pretty good case in the following presentation: http://vimeo.com/97318797

Unfortunately the slides are not online. But his presentation starts with a case of why 'auto' should often be preferred to explicit type declarations.

EpicEng4• 12 years ago

"For example this seems ok to me, because the type is on the left"

    auto* x = new Foo();

Are you only referring to the fact that the type is noted at least once on that line? I ask because that would not pass my code review at all 99% of the time (manually allocating memory that way.)

As for something like

    auto x = std::move(y);

I couldn't say it is bad without seeing the context around it. Is it a small function? Is it obvious what y is? Looks fine to me in most cases.

TheSoftwareGuy2• 12 years ago

do you NEVER allow dynamically allocated memory? or am I misunderstanding you?

ingve• 12 years ago

The video:

http://tech.yandex.ru/events/cpp-party/june-msk/talks/1954/

angersock2• 12 years ago

I've never seen footage of Meyers before...He kind of reminds me of the Tall Man from the Phantasm movies.

I guess C++ will do that to you. :)

72deluxe9• 12 years ago

I always thing his prog-rock 70s haircut makes him look like one of Robin Hood's merry men or a medieval archer.

Not that this is a bad thing.

fn• 12 years ago

Thanks for the link to the video. Always been a fan of Meyers but have never been a talk of his.

cacainmycafe• 12 years ago

I like C++ because I only pay for what I use in the language. Very little overhead or additional baggage to slow or weigh things down, unless, I elect to include the extra luggage.

The recent updates - C++11, C++14 and the drafts for C++17 are also very welcome.

When you need performant, deterministic, portable and testable code, you go for C++.

heinrich5991• 12 years ago

The new Rust language by Mozilla makes similar promises,

* only pay for what you use

* memory safety

* testability

* portability

(They even got a standard testing module.)

EDIT: How do you make lists with Hacker News markup?

SamReidHughes2• 12 years ago

How do you make lists with Hacker News markup?

You just made one.

freyrs3• 12 years ago

Conceptually they are similar, though it's always important to note that C++ has several man-centuries worth of compiler work. Rust may become stable and efficient enough to replace some existing C++, but at the moment it's most certainly not as mature as the existing C++ ecosystem.

AnimalMuppet4• 12 years ago

To me, the key line was "Most of the complexity of C++ is hidden from most of the users most of the time."

The complexity is there. Trying to understand the whole language at a language-lawyer level is mind-boggling. Trying to write libraries that make proper use of the goodies is very hard.

But using C++ isn't so bad, as long as you don't try to use every aspect of it. Just use the parts you need to be able to do what you're really trying to do. You don't have to pay for what you don't use. That's good enough for a huge number of programmers in a wide variety of contexts.

There's a lot of haters that can point out a huge number of flaws. But here's the thing: Most of them, I never run into. I don't care if the move syntax is confusing; I don't use it. Maybe I never will. If I have to, then I'll care about how good or bad the syntax is. In the meantime, the parts I actually use let me get my work done better than any alternatives.

ygra• 12 years ago

The problem is that in any existing codebase that is large enough you'll have such a plethora of different things that are used that it doesn't really matter that I don't use things I don't understand or know yet. I still encounter them when reading code and have to understand them then. At least for me who stumbled into a semi-ancient C++ codebase two years ago (and having known almost nothing about the language before) that was a major impediment in picking up how the language should or might be used properly.

mgkimsal• 12 years ago

Good point, and was most recently used in the PHP community with the introduction of 'goto' about 5 years ago. "If you don't like it, don't use it" is pretty naive, because more often than not, I'm not using my own code, but someone else's (via inherited code, libraries, etc). Code is written once and maintained for years. I've noticed a trend over the years whereby certain types of developers (ab)use new features in a language when first introduced, then move on to other projects, leaving their "my first time with feature X" code behind for someone else to deal with for years to come. Sometimes it's fine, sometimes it's a nightmare.

The GOTO thing in PHP has almost been a non-issue all around, but highlighted the "don't use it if you don't like it" argument's flaws.

72deluxe9• 12 years ago

Stumbling into ancient codebases is always an impediment to understanding the language properly. Like reading C++ from before dynamic_cast was available, and spotting macros to do the same thing littered around MFC code.

I also find that the ancient developer's design style and implementation left a lot to be desired, and if someone came across that as an introduction to a language, I think they would have hated the language too. That's why we should always write beautiful code and occasionally throw in obscure language features to force them to learn them :-)

ef42• 12 years ago

One does not always have the luxury of sticking to the good parts. Code is communication, and you often have no control over who is trying to communicate with you.

zenbowman5• 12 years ago

The difference between engineering and tinkering is discipline.

Not to say tinkering is bad, its perfectly fine when trying to create the latest viral app or when learning how to do something. When engineering something, discipline is required.

And nothing stops any institution seriously committed to engineering to adopting practices that restrict language use to a subset (mandatory code review, static analysis tools that highlight deviant code and disallow it to be pushed, etc).

rayiner• 12 years ago

The complexity is there. Trying to understand the whole language at a language-lawyer level is mind-boggling.

It makes me uncomfortable not to have that level of understanding for a language that's so low-level and doesn't have the "Do What I Mean" bent of say Python. I'm "meh" on C++ going forward. I invested a lot of time into my copy of "The C++ Programming Language" (3d Ed.), for C++ 98, but I can't motivate myself to get the new edition and learn in the ins-and-outs of C++ 11. It doesn't seem worth it to me. I'm really hoping Rust catches on. It's a complex language in the same vein as C++, but the bang-for-buck in terms of expressiveness relative to complexity is better, I think.

dman• 12 years ago

Looking forward to v1.0 of Rust to have some expectation that the constructs that I learn will endure over time.

pmelendez• 12 years ago

"for C++ 98, but I can't motivate myself to get the new edition and learn in the ins-and-outs of C++ 11"

I can understand that but keep in mind that C++11 is a completely different language to what it is C++98.

blub• 12 years ago

How will learning a new language help you? I guess it depends on what you're trying to achieve in the end, but when that something is building software, learning how to use a new kind of hammer isn't the breakthrough one needs most of the time.

In fact I find the premise of all the Go/Rust/D advocates a bit strange. It makes sense to learn a tool that does something you can't do with your existing ones, but learning 5 tools that are mostly the same is a waste of time unless one is not into collecting tools as a hobby.

EpicEng4• 12 years ago

I love how C++ is now considered by many to be "so low level". It's a high level language as far as my work goes. Sure, it's not Python-high-level, but Python isn't an option.

tptacek4• 12 years ago

I'm a former C++ programmer (and a current C programmer) and my go-to language is currently Golang; here's why I'd virtually always choose Golang before C++:

* Streamlined language with carefully-chosen syntax and keywords (there aren't 10 different meanings for "static", for instance); entire concepts have been eliminated to no apparent ill effect in building real systems. Fewer cycles allocated to the language, more cycles allocated to problem domain.

* The 95% case for associative and sequential containers is built into the language, with (for me) enormous benefits to programming efficiency.

* A streamlined and carefully orthogonalized standard library optimized for systems programming. Golang has the best-designed standard library I've ever used.

* A ruthlessly pragmatic packaging and modularity system; unlike C++, packaging is not left up to the build system.

* Build-world compilation times measured in 100s of milliseconds rather than 10s of minutes.

If I was writing, say, a generic trie library that I was hoping to get hundreds of different programmers to use, C++ would be a tempting target because of generics. But it turns out, most of the time I build projects like that, I'm really just wanking. Another benefit of Golang is that it's so stripped down and pragmatic that it subtly discourages wanking.

A lot of people would add Golang's concurrency model (share by communicating instead of communicating by sharing) and lightweight threads to this list. I like Golang concurrency too but my sense of it is that among languages designed from the jump for concurrency, this isn't that much of a unique benefit.

72deluxe9• 12 years ago

C++ does feel like a new language. If you just buy Stroustrup's new book and read through the "tour of C++" towards the beginning, you'll find lots of new bits without having to read the entire book (although I am still going to try and do that).

For me, I am constrained by the compilers that are used by my employers (VC10) so I can't use half of the new features (although I could use them in Xcode and macro them out I suppose).

cheez3• 12 years ago

def doappend_dwim(arg = []): arg.append('a') return arg

assert(doappend_dwim([]) == ['a']) assert(doappend_dwim() == ['a']) assert(doappend_dwim() == ['a','a'])

Nitramp• 12 years ago

Another quote:

    C++ most suited for demanding systems applications. [...] You choose C++ when the situation is already complicated.

... and then you have two problems </snark>. Yes, C++ has a lot of features, and those features are often individually useful to solve individual issues, but I remain unconvinced that this plethora of features and complexity pull their own weight.

You can write useful, efficient software in languages that expose much less complexity to their users.

Re: complexity. Not having to understand C++ most of the time, or subsetting the language to have a manageable code base only works until you run into somebody else's code, or some 3rd party library. It's not a fix, it's a symptom of something broken.

GFK_of_xmaspast• 12 years ago

"C-with-STL-containers" is an incredibly powerful subset of C++.

mpyne2• 12 years ago

The point is that sometimes you need the added complexity to solve complex problems. Torque wrenches are more complicated than a socket wrench, which is itself more complicated than a simple $5 wrench.

But when you need to be able to precisely measure running torque or torque a fitting to known value, you can't avoid picking up the complexity of a torque wrench.

redtexture• 12 years ago

Book needed: "C++ the Good Parts"

steveklabnik5• 12 years ago

Isn't that "Modern C++ Design" by Alexandrescu?

cpeterso• 12 years ago

Need a "C++: The Good Parts" compiler (or static analysis front end) that enforces the good parts but your code is a compilable by a C++11 compiler. I've heard some Rosy developers joke that Rust is C++ The Good Parts. :)

pjmlp• 12 years ago

Get "Tour of C++", a new book from Bjarne only with modern C++11.

kgabis• 12 years ago

It was released years ago: http://www.amazon.com/dp/0131103628

cmollis• 12 years ago

"Just use the parts you need". (sounds prosaic, but actually well put).

I've used C++ over the years off-and-on (depending on what the clients required). You don't really need to use every 'exotic' feature in order to be productive. If you need something low-level with great compilers and a lot of great lib support, it's actually a nice language. All these new languages are nice, but Go and Rust just chisel off the 'ugly' in favor of some different 'ugly', IMO.

wtetzner2• 12 years ago

The problem is that other people's code might use the 'exotic' features. Unless you're the only one working on the code, or you have control over what subset of the language is used (including libraries), you have to deal with the whole language.

alexvr2• 12 years ago

I think this makes it a great language for solo projects. You can write almost however you like and largely ignore features you don't need. The problems arise when dealing with a bunch of programmers with different experience levels and preferences. That's where simpler, more conservative languages like Java shine. C++ gurus used to their massive arsenal of options must cringe when forced to work with simpler languages.

lutorm2• 12 years ago

Why does the title slide show a ship flying a US flag? He obviously has correct pictures, because they are in the later slides...

vinkelhake4• 12 years ago

I suppose the ship on the title slide is "the one that sails" (it's not the Vasa).

wmkn2• 12 years ago

Because it is a pretty picture and the ship with the US flag represents the sailing part in the title of the presentation.

lutorm2• 12 years ago

What, like C++ comes from the US?

jokoon• 12 years ago

there are still things I wish would be possible for c++. I'm not a language expert, but I still wish for those things.

* non templated tuples instead of struct: for example, 2 struct types are the same if the data types they hold is the same. Not sure if it's possible for statically typed language.

* tighter STL container integration with the core language syntax

* some way to do modules

* some new thing to make compiling much faster, so to avoid relying on precompiled headers. go and rust are so much faster for this, C++ is not. I still wonder if there could be some gcc or clang extension for this, it would be really appreciated. C++ is awesone to work with, but language implementations suffers from those little details.

loup-vaillant22• 12 years ago

ML and Haskell are statically typed, and have tuples as you describe them. For instance, the tuple

  (42, "foo", fun x -> x+3)

has type

  int * string * (int -> int)

in ML. It would probably be a serious extension to C++'s type system, though, and for limited benefit: you're asking for yet another way to do Cartesian product. Structs already do that. What's sorely lacking is sum types:

  type 'a option = Some of 'a
                 | None

  type 'a list = Cons of 'a * 'a list
               | Empty

---

Integrating the STL at a syntax level gives a special status to the standard library, preventing users from writing effective replacements or analogies. Also, C++ has precious little orthogonality left, let's not destroy it.

---

What kind of modules are you talking about? C++ has compilation units, classes, and namespaces. What capability do you want that they don't already provide?

---

Good luck on the fast compilation front. That one will likely require removing things from the language, or making some major compatibility-breaking changes in the syntax (to make it easier and faster to parse), and possibly a rework of the template system. No. Way.

AnimalMuppet4• 12 years ago

If I understand correctly, Go is the "removing things from the language" approach to fixing the fast compilation issue.

pixelglow• 12 years ago

clang has implemented modules as a replacement for monolithic precompiled headers, but they are marked experimental for C++. They are tracking the C++ modules proposal.

See http://clang.llvm.org/docs/Modules.html and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n207....

detrino6• 12 years ago

* non templated tuples instead of struct: for example, 2 struct types are the same if the data types they hold is the same. Not sure if it's possible for statically typed language.

C++ has std::tuple, but most people (myself included) find nominal typing easier to understand. I Would only use std::tuple in situations where I needed to store a values of the types of a variadic argument pack.

* tighter STL container integration with the core language syntax

C++ actually does pretty well here, it has operator overloading as well as std::initializer_list.

* some way to do modules

Hopefully a good modules proposal makes it for C++17

* some new thing to make compiling much faster, so to avoid relying on precompiled headers. go and rust are so much faster for this, C++ is not. I still wonder if there could be some gcc or clang extension for this, it would be really appreciated. C++ is awesone to work with, but language implementations suffers from those little details.

Modules would help with compile speed. IMO, Go doesn't offer very many abstractions to the programmer that the compiler must eliminate so its easier to compile quickly. My 1 day experience with Rust was that it actually compiled quite slowly, do you have any personal experience with the language that you found it compiled quickly ?

eatitraw• 12 years ago

Scott did an amazing talk in Moscow two weeks ago. The slides look the same. Here is the link to the video:

http://tech.yandex.ru/events/cpp-party/june-msk/talks/1954/

4bpp• 12 years ago

The way people like to complain about the bloat and arbitrariness of C++, but then still quietly wind up using it, reminds me a lot of the common complaints about the arbitrary pronunciation and other quirks of the English language. There is, of course, the trivial commonality that "everyone understands it and a lot of useful things have already been written in it", but at least part of the reason why languages like Esperanto or even Lojban don't catch on is that while many like to extol the virtues of a (natural or machine) language being simple and unambiguous on paper, in practice, more often than not people arrive at a point where they perceive the very un-Pythonic benefit of being able to express the same thing in more than one way (and, conversely, being able to convey more than what the words/code say at face value).

The natural language example of course being metaphor and allusion, I am thinking of practices such as indenting glVertex calls inside a glBegin/glEnd block, or overloading () on an object to convey the idea that "you should think of this as something like a function" when it is really not on a technical level.

rbehrends• 12 years ago

The way people like to complain about the bloat and arbitrariness of C++, but then still quietly wind up using it

Most such people are probably in the same position that I am in, and this is that they're using C++ primarily because they're involved in projects with a C++ legacy codebase. Language choice really isn't something that's up to individual developers.

But for personal projects, I've pretty much abandoned C++, other than when I need something to bootstrap on platforms that I can't make a whole lot of assumptions on, or when I have to operate close to the metal and C for some reason or another doesn't fit the bill.

The thing is that I don't really have a lot of beef with the language features of C++ (the way they're used in some libraries is a different issue). The features it has are generally there for a reason, and have good rationales. And C++ does pretty well in its chosen domain (system programming). It's not perfect (what programming language is?), but hardly terminally flawed, either.

But C++ simply doesn't meet my needs. It has a very strong bias for optimizing CPU cycles, even at the cost of developer cycles, but I'm far more likely to be short on the latter than the former. Those extra few percent of speed that I might gain (or might not -- some C++ features are not all that efficient, after all) are rarely worth adding even a few hours of development time.

andrewflnr• 12 years ago

Regarding English at least, and for the most part C++, being able to express things in more than one way is not what we're complaining about; we're not looking for Pythonicity. What's annoying about English is more the erratic spelling, grammar, conjugations, and stuff like that.

mtdewcmu• 12 years ago

"everyone understands it and a lot of useful things have already been written in it"

That's such an overwhelmingly good reason to express yourself in English, instead of Esperanto, that you really don't need to postulate any additional reasons.

Most things like programming language choice follow heavy-tailed distributions, which means that there are a few that are overwhelmingly popular, as well as many that are extremely unpopular. The reasons that C++ turned out to be overwhelmingly popular may be mainly historical.

You could probably also blame popularity for making C++ so ornate. It jumped on every language trend over the years. Fortran didn't, but if Fortran had been popular...

detrino6• 12 years ago

I really enjoyed this talk. The Q&A session was great as well, Scott is an entertaining story teller.

alexvr2• 12 years ago

I think its "excessive" features make it an appealing language so long as I'm not dealing with not-so-well-written and/or expertly "clever" code.

I find straightforward, well-written C++ more comprehensible than Java and even Python (only due to Python's dynamic typing).

Of course, the definition behind straightforward, well-written C++ is very subjective.

santaclaus• 12 years ago

Why can't we simply have C + RAII + generics? That would be a baller language.

100982• 12 years ago

throw in first-order functions and lambdas as well, replace generics with templates the way they are now, and I'm all for that!

Tomte• 12 years ago

When in Stockholm, go visit the Vasa museum. It's absolutely breathtaking.

Make sure to get a guided tour. You can read all the stuff on the displays and in books, but you probably won't. So you'd lose all those nice stories about how the German ambassador protested the ship, because the figurines on the front symbolized the Roman emperors, with the Swedish king at the very front. Preposterous! The emperor of the Holy Roman Empire of the German Nation is the rightful successor to the Roman emperors, after all!

Pay attention to the fact that the Swedes weren't as stupid as people tend to assume. "Oh, they couldn't even build a ship that's floating!".

Yeah well, it was a design no-one had attempted before (bigger, three masts, two rows of cannons), the math to calculate the behaviour wasn't available, yet. And best of all -- contemporary analysis shows that they almost made it. Had the ship been just a little bit wider (I don't know, something like 20 centimeters or so?), it would have been fine.

Be amazed how the Swedes never just found a scapegoat to punish for the loss of their flagship.

Or just admire the architecture of the museum.

Whenever I'm in Stockholm I go there. It's inevitably a high point of my visits.

bjourne• 12 years ago

Several people working on the design of the ship knew it never would sail. But since voicing their criticism about the king's unrealistic spec carried the risk of getting beheaded they kept their mouths mostly shut. The master shipbuilder who was in charge of the project fled back to Holland when Vasa sank. It was a classic case of hoping someone else would get the blame when the shit hits the fan.

tragic• 12 years ago

I'd completely forgotten about that. Yes, it's a great bit of tourism - very interesting building.

On the over-arming of ships going spectacularly wrong, see also the Mary Rose[1].

[1] http://en.wikipedia.org/wiki/Mary_Rose

mrev19• 12 years ago

The second row of cannons was added at the insistence of the king, the shipbuilder knew it would doom the ship. Also, I've yet to meet anyone who thought the Vasa sank because "Swedes were stupid."

bitlevel• 12 years ago

There is also the matter of the incorrect measurements contributing to the sinking of the Vasa: http://www.pri.org/stories/2012-02-23/new-clues-emerge-centu...

vasilipupkin• 12 years ago

I've been using C++ for many years, and, sure, it has a ton of various features, not all of which I use all of the time. But, being comfortable with it, I don't find it any harder to program in than Java or Python. I am not sure if it's fair to say that the learning curve is higher to get to that point. But then again, if you do silly things in Java, won't your code be slow as well?

vilya6• 12 years ago

The line that stood out to me was the quote from Stepanov, about C++ being the only language in which it was possible to implement the STL. To most people, that would have been a hint that perhaps the design of the STL was flawed...

I think the STL may have been the worst thing to have happened to C++. It could have been so much nicer if something like Qt (the core part) was adopted instead.

stinos4• 12 years ago

I think the STL may have been the worst thing to have happened to C++

I think opinions on that greatly vary. I for one find a majority of what is in STL very well-designed and very usable.

vilya6• 12 years ago

Sure, I was just giving my opinion. Take it for what it's worth... :-)

But if you'll indulge me for a moment, consider how you'd convert a string to uppercase using the STL vs using Qt. The STL code (taken from http://en.cppreference.com/w/cpp/algorithm/transform) looks like this:

   std::string tmp = s;
   std::transform(tmp.begin(), tmp.end(), tmp.begin(), std::ptr_fun<int, int>(std::toupper));
   return tmp;

Note the use of a temporary variable, because std::transform does a destructive update.

The equivalent Qt code looks like:

   return s.toUpper();

I'll let you draw your own conclusions.

By the way if there's a simpler way to do that using the STL, I'd love to hear about it.

72deluxe9• 12 years ago

Which bit about Qt were you hoping was part of the STL? I think the design goals of the STL was to make it portable, something Qt is not, despite being multi-platform. We mustn't forget that C++ is used on very low level devices.

If Qt is anything like wxWidgets, wxWidgets reuses the STL for its container types, basically providing a thin wrapper over the STL (or it can do with a build switch).

I myself find the STL very useful, so I am genuinely interested in which bits of the STL you wish were more Qt-like? Do you mean the GUI bits of it or something?

vilya6• 12 years ago

How do you define portable? If you mean the same code compiling and running out-of-the-box on Windows, Mac and Linux then actually my experience with Qt has been very positive in that regard. Those are the only platforms I develop for right now, so I can't ocmment about portability to e.g. iOS or Android (although I believe Qt ports are available for them).

Qt doesn't reuse the STL container types, it provides its own - which I find much more pleasant to work with than their STL counterparts. The STL puts a lot of effort into providing types of flexibility that are irrelevant or useless to me (e.g. allocators) and doesn't provide lots of simple things that I need every day (e.g. an indexOf method for std::vector, a contains method for std::set, or a toUpper/toLower method for std::string).

Why C++ Sails When the Vasa Sank [pdf]

Related Stories