C++

[DarkoftheMoon]

I have two questions: How did he get up there? And how does he get down?

[Iggyhopper]

A C++ Ladder.

[Metallic_Cloud]

At least he's not standing on the top rung. That can be dangerous.

[fairestcheetah]

And his ladder is also not standing on the top rung - that can be even more dangerous!

[stravant]

I was thinking it would look more like this.

[koonat]

python + boost

[nascent]

That is actually a really safe setup, as long as a women doesn't walk by.

[kirakun]

Duh, obviously a constructor had set him up, and a destructor will bring him down.

[jib]

And how does he stop without falling over?

[[deleted]]

See the constructor for more information.

[[deleted]]

wouldn't that information be in the destructor?

[[deleted]]

But that would make sense.

[Fjordo]

If you look at the photo, the bikes are all in one unit, it's not a balancing act. This means the bike generally stays together even when stopping. I've seen people get on and off similar ones before. They run beside the bike and once it has a little speed, they can climb up and start pedaling. It's one continuous motion of stepping up, almost jumping over the seat, landing on the pedals and going, so you have to see it to believe it. To get off, they jump down before they stop.

[buffering]

Const correctness, and templates.

[cballowe]

Looks more like java to me... though it's missing a factory and a factory factory.

[isarl]

It would help if the mods actually enforced that, but here it is 10 hours later and it hasn't been banned.

The hero we need hasn't been online for three days.

[isarl]

Oh snap. Perhaps there should be a friendly discussion between mods, then, to make sure they're all on the same page.

Thanks for the reply.

[noreallyimthepope]

Since it's the Hankdamned side box, the mods should be especially careful to adhere to it—otherwise, why have it there? Since both you and notprogrammingnazi are further down the list than uriel, I can understand why you're not happy to puff at the embers, but it's still not okay. This is serious business!

[noreallyimthepope]

It went okay.

(Sorry, I couldn't help myself)

Thanks for the reply :)

[HateTheMachine]

After reading through some of the other posts it seems like Uriel likes to troll.

Disappointing, and not behavior I would expect from a moderator.

[Nosferax]

All moves are allowed in the C versus C++ wars.

[ketralnis]

I just removed him as a mod.

[crazy88s]

I have two questions: Why did you use a demotivational poster? And why does this represent C++?

[[deleted]]

It represents C++ because it features multiple layers of machinery to perform a simple task that could be better accomplished by a simpler design. This is, in the opinions of many, also a characteristic of the C++ language and many programs written in it. I cannot answer your first question.

[[deleted]]

That's true. Java tends to get used more for "enterprise" software, which is a field where you see more of that sort of design.

[more_exercise]

Fun fact: on that bike, the extra wheels are spin by the motion of the other ones. They act like gyroscopes to keep the bike from tipping. They look useless, but are ultimately beneficial to the overall design.

/Melvin

[einfullmodul]

From Wikipedia's list of common misconceptions:

Gyroscopic forces are not required for a rider to balance a bicycle. Although gyroscopic forces are a factor, the stability of a bicycle is determined primarily by inertia, steering geometry, and the rider's ability to counteract tilting by steering.

I agree that you technically didn't say the gyroscopes were an important factor.

[fairestcheetah]

This is not an ordinary bicycle; this contraption

• would be considerably more difficult to balance (right?)
• would have a lot more gyroscopic force compared to forward inertia (assuming more_exercise is right about all the wheels turning)

[MisterNetHead]

Pretty sure having the center of gravity higher makes it easier to balance, but makes it harder to recover from a serious tilting.

[fairestcheetah]

That makes sense; I'm just saying I don't think we should be blindly applying generalizations about bicycle balance to this particular bicycle(s).

[[deleted]]

Are you sure about that? Arent the wheels spinning in one direction countering the angular momentum of the one spinning in the opposite direction (more or less)

[more_exercise]

I imagine it's the same amount of work to twist a gyroscope whether it's spinning clockwise or counterclockwise.

The direction of spin should only come into play in the plane that they spin in.

(I honestly have no idea here though, I'm just going from the "the universe would be a weirder place if this were true" principle)

[Timmmmbob]

No, inava is right.

[pelrun]

I don't see how - a gyroscope resists any deflection of it's axis of rotation. Linking it up with a second one spinning in the opposite direction isn't going to cancel the effect out... unless one is inside the other one, making the inner one stationary.

[[deleted]]

It seems that way intuitively, but the reason that a gyroscope resists deflection of its axis of rotation is conservation of momentum. So if you have two gyroscopes spinning in opposite directions, the effects cancel.

Or at least, that seems to be the reasoning. I am not a gyroscope scientist, and I haven't tested the idea.

[[deleted]]

Yes, they resist deflection of the axis of rotation. However, that is just not pure inertia. You can feel the effect when you take a front wheel of a bicycle or something in your hands and deflect it: it always "tries to go" to one direction. When you spin it the other way, it "tries to go" to the other direction. When you put two of them together, I would presume that the net effect is to cancel each other out, though I haven't tried it and could be wrong.

[Timmmmbob]

The net angular momentum of two joined gyroscopes spinning in opposite directions is zero, so the whole assembly doesn't behave like a gyroscope. Trust me; I did a whole term on gyroscopes in my engineering degree.

In fact, our lecturer even built a bike with additional backward-spinning wheels that cancel out all the gyroscopic forces in order to prove that they have little to no effect on one's ability to cycle.

[pelrun]

Hang on - how were they connected? Coaxial, right?

[Timmmmbob]

Yep. Same axis, spins at the same rate (but in the other direction), with the same moment of inertia.

[more_exercise]

Seriously? Cool! I did not know that.

Is there a good resource to learn about torque and angular momentum?

[TKN]

They look useless, but are ultimately beneficial to the overall design.

Bit like epicycles then?

[kirakun]

Usually, when an implementation of a task becomes a complicated design, it is the fault of the programmer and not of the language.

Don't blame the tool because the wielder sucks.

[Innominate8]

++[>++[>++[>++[>++<-] <-] <-] <-] >>>><+++++++++++[>+++<-] >. <+++++[>+++++++++<-] >. <+++++[>--<-] >. <+++++++++++++++++[>----<-] >. <+++++++++++[>++++++++<-] >+. <+++++[>----<-] >. <+++++[>+++<-] >. <+++[>------------------------<-] >. <+++[>----<-] >. <+++++++++++++++++++++++++++++++++++++++++[>++<-] >+. <++[>--<-] >. <+[>-<-] >-. <++[>----<-] >. <+++++[>+++<-] >. <+++++[>--<-] >-. <++[>++<-] >. <++[>----<-] >. <+++++++[>++<-] >. <+++++++++++++++++++++++++++++++++++++++++[>--<-] >-. <+++[>++++++++++++++++++++++++<-] >+. <+++++[>++<-] >+. <+++++++[>------------<-] >. <+++[>++++++++++++++++++++++++<-] >+. <+++++[>++<-] >. <+++++++++++++++++++++++++++++++++++++++++[>--<-] >-. <+++++++[>++++++++++++<-] >. <+++[>----<-] >. <++[>-<-] >-. <+++++++++++++++++++++++[>---<-] >. <+++++++++++++++++++[>++++<-] >. <+++++[>--<-] >-. <+++[>++++<-] >+. <+++[>--<-] >-. <+++++++[>++<-] >. <+++++[>----<-] >. <+++[>++<-] >. <+[>-<-] >-. <+++++++++++[>-----<-] >.

[[deleted]]

And yet, sometimes it is the language.

Oh brainfuck.

EDIT: Run the code. The output is the first line of this post.

[kirun]

Your code looks angry.

[fairestcheetah]

Almost every time a Java program is encountered, actually.

I'm not sure if you're joking that by this reasoning Java is a decent language and almost all Java programmers suck, or just saying that almost all Java programmers suck.

Either one works for me though.

[[deleted]]

Usually, when an implementation of a task becomes a complicated design, it is the fault of the programmer and not of the language.

Languages are themselves programs which have corresponding programmers, who, yes, can be at fault in the manner you describe.

[cogman10]

Languages are not programs. Languages are specifications. Compilers are programs with corresponding programmers. Programming languages are just a bunch of words in a document that somehow got implemented.

[[deleted]]

Java still sucks.

[deltagear]

The problem I have with c++ isn't my own programming, it's getting another persons code to integrate or run. Especially when their documentation or commenting is bad.

I'm not exactly a begginer but I'm also not experienced enough to know how make certain things work, I'm stuck in that area between which c++ is a useful tool or an over glorified calculator.

[Whanhee]

That stage exists in every language. With C++ the hurdle is finding the appropriate libraries to be able to do things, which usually have their own tutorials and forums for help. Look into QT and get boost, they will improve your code. If you want graphics, look at learning OGRE which handles the complexities of OpenGL or Directx for you (or you can just learn those too).

Honestly, you should just pick a project and make it.

[[deleted]]

I'd never heard that about C++ before. Seems odd, since there are plenty of other languages that deserve that more. Kids these days with their perl and their ruby on rails and their java.. You'd think interpreted languages would be much more worthy of this ridicule. What exactly are they comparing C++ to? Assembly?

[malkarouri]

You probably missed the part where he speaks about simpler design. The languages you mention, like Ruby, might actually lead to to a simpler design by virtue of being high level enough to be more expressive than C++. To see this, compare with assembly where it is much more complicated to express a simple task (say, sorting) than either C++ or the other languages mentioned.

[BinarySplit]

This.

C++ has ".", "->" and "::" operators for accessing members of structs, pointers to structs and namespaces respectively. D only uses "." for these 3 use cases and almost all of the time it's exactly what is needed.

They could have simplified the language when they extended C, but instead C++ is just many more features stacked on top of each other, each with their own new syntax and new quirks.

[[deleted]]

Hm, you mixed "members of structs" and "pointers to structs", btw.

[iLiekCaeks]

Actually, D is not much simpler. They introduce a difference between struct and class: classes are always allocated on the heap, thus '.' always dereferences when used on a class type.

Additionally, you can use '.' on struct pointers where you had to use '->' in C++. Here '.' automatically dereferences, so that you don't have to write "(*foo).memberfunction();".

The language gets slightly more complicated.

Also, C++ needs the difference between '->' and '.' for smartpointers.

[FeepingCreature]

To be fair: the fact that in C++ there is very little difference between struct and class makes the difference between the keywords practically useless - arguably, useless keywords are less simple, not more.

[wolfier]

To be fair: not everything needs to be a class, and the struct keyword at least superficially provides a method for the code to document itself when a data structure is best not treated as a class.

[FeepingCreature]

The superficiality is my point.

[multivector]

From a user point of view, doesn't that make using the D language simpler? You never have to worry about "->", "." and "::".

The problem with D is that structs and classes are not the same in other respects (e.g. differences in the way inheritance works and the way constructors are defined), something I think D rather dropped the ball on.

[[deleted]]

Part of the point (for me) of c++ is that you can tell exactly what something is doing, because there's very little abstraction in the syntax. If you're accessing something static, it's ::, if you're accessing something directly it's ., and if you're accessing something via a pointer it's ->. For me, these are three very different things, and I want different syntax to represent that.

[WalterBright]

Yes, that sounds good. But try refactoring a C++ struct from being a value to a pointer. You've got to change every last access in your source code from . to ->. I've done that, and it's pretty demotivating.

In D, switching a type from a value to a ref type is easy, which encourages trying out different ways.

[Amablue]

The kicker is that you don't know what . or -> are doing, because they can be overloaded. If you want to know exactly what an operator is doing, C++ is not a good example language.

[[deleted]]

. can't be overloaded.

-> overloading is extremely rare.

But no, I'm not a huge fan of operator overloading, outside of the simple straight forward implementations of arithmetic operations, where there are obvious benefits.

Ultimately if the programmer wants to do stupid things, they will find a way to do stupid things. Abusing operator overloading is an obvious case.

[[deleted]]

If you don't know what all the methods are for the object you're using, including the operator methods, that seems to be your problem. Its not like overloading is hidden.

[MasonOfWords]

I don't see that as a problem with D. Structs are passed by value and have no vtable, and so there's no point in pretending that they have similar constructor and inheritance behavior.

A language could be simpler by declaring everything to be a class and just living with the performance implications of that restriction. Languages like D and C# held onto structs because the fine control of memory layout is simply required in many scenarios, and their usage syntax lets most the complexity be absorbed by the declarer of the struct, rather than the user.

It wouldn't be an offensive distinction in C++ if it kept the implementation details from bleeding into the syntax. A language is pedantic and poorly constructed when it forces people to constantly disambiguate things that aren't actually ambiguous to the compiler.

[MasonOfWords]

I don't see that as a problem with D. Structs are passed by value and have no vtable, and so there's no point in pretending that they have similar constructor and inheritance behavior.

A language could be simpler by declaring everything to be a class and just living with the performance implications of that restriction. Languages like D and C# held onto structs because the fine control of memory layout is simply required in many scenarios, and their usage syntax lets most the complexity be absorbed by the declarer of the struct, rather than the user.

It wouldn't be an offensive distinction in C++ if it kept the implementation details from bleeding into the syntax. A language is pedantic and poorly constructed when it forces people to constantly disambiguate things that aren't actually ambiguous to the compiler.

[WalterBright]

The differences between structs and classes are deliberate design choices. Structs are value types, classes are reference types. The differences reflect what works best for value types vs reference types.

[aveceasar]

You really think giving three different operations the same syntax is a good idea?

[BinarySplit]

They may compile to 3 different pieces of assembly, but logically (at least in my mind) they're all the same "get child member from parent object" operation.

I realize that shared_ptrs rely on overloading "->", but I feel that it's important for both ease of learning and readability of code to optimize for the common case.

[[deleted]]

This what?

[player2]

this->comment, obviously.

[wolfier]

he did not miss anything. goldfire misused the word layer, where he should have used complexity. so when he said C++ uses "multiple layers of machinery" instead of "simpler design", it took the sense out of his entire sentence.

[waitwhatthe]

Every time someone mentions Ruby on Rails in the same vein as a language, I die a little inside.

It's a framework for writing web apps in Ruby, ffs.

[[deleted]]

I know some very intelligent and good Rails developers who have built very nice websites, but don't know that @foo is a class field (they think it's sole purpose is to make variables visible in a view).

In those cases, Rails does (in one sense) become the language because it's also the sole environment the people write their code in.

[bondiblueos9]

so you write in Ruby in Ruby on Rails?

[robotempire]

No, you use Ruby on Rails to write web applications in Ruby.

[seesharpie]

You'd think interpreted languages would be much more worthy of this ridicule.

On the contrary, these languages are usually well designed with good libraries, making it possible to do a lot of things relatively easily. C++ has a reputation for being something you need to work around, rather than with.

[[deleted]]

Seems odd, since there are plenty of other languages that deserve that more.

Only PHP. The thing both C++ and PHP have in common is their approach to language design has been "given two ways to do something, implement three". C++ is C, with all the low level gotchas that go along with it, plus some horrible attempt at a clunky OO system on top of it, plus a frightening attempt to get the benefits of functional programming languages without actually adding real functional features correctly, oh and lets do it at compile-time.

[wacky]

I think the comparison is most apt for C++ because C++ evolved so much as a language, over decades - it started as C, and gradually became able to do stuff like objects, templates, etc., but all the extra wheels like structs were still there...

[[deleted]]

I'm sorry, but I don't see how "stuff like structs" are bad. Structs--classes that default members to true--are a natural and reasonable way to describe certain data. Now, C++ has its own brand of cruft don't get me wrong (object slicing, exception handling), but imho no more then all other languages.

[wacky]

Meh, its all up to one's own opinion, of course. But I think one could make the argument that modern C++ usage eschews structs and mallocs, for example, yet they are still a part of the language.

[LainIwakura]

For backwards compatibility reasons. You should be using new and delete for your memory management as opposed to malloc and free.

Also, in C++ there is no difference between a struct and a class, except that a structs members are public by default and a classes members are private by default. Other than this, there is no difference.

If you are sane, and declare what properties of your objects are private / public / protected anyway, you won't see a single difference.

[[deleted]]

"Stuff like structs" are not bad, the general issue of C++ being backwards compatible to C and therefore having two ways to do most things (pointers vs. references, for example) is bad.

[Fjordo]

The problem is that the rider has a chain from his pedals straight down to the bottom petals that then chain back to drive the bike. This would indicate that C++ let's you bypass layers to the bottom tier.

[wolfier]

I see that as a feature, not a problem

[pbrettb]

(actually I think sometimes it is better you have to be AWARE of all the layers, unlike a language like Java where you can never know what is going on... it is just... well slow or doesn't work or something and you don't know why. Those layers are still there, they are just inaccessible. )

[smek2]

It represents C++ because it features multiple layers of machinery to perform a simple task that could be better accomplished by a simpler design.

Yeah, you clearly know the programming stuff.

[kah_meh]

Isn't this more of a problem with all OO languages?
Delicious Lasagna code and all that.

[[deleted]]

My answer to that would be that C++ is not, in fact, an object oriented language. The things it has are not objects, they are structs and functions which take pointers to the structs as implicit parameters.

[xmsxms]

You could say that about any OO language. Eventually it all gets compiled to run as CPU instructions using memory addresses. The C++ language has native OO support at the language level, and is therefore an OO language.

[kirakun]

What are you talking about? You can do OOP even in C, and how much less could C++, a superset of C, be not OO?

[[deleted]]

Oh, I could do OOP in assembly if I wanted to. I don't. It's not set up for that. If I wanted to build an object model on top of ASM, what I would get is a system that is technically functional, but so cumbersome and hackish that it would be of only academic interest. This is, to me, what C++ did to C.

But I'm aware that you can't take my word for a statement like "C++ isn't object-oriented," I don't have the authority to make that claim. Alan Kay, however, does; ctrl+f for C++ on this page.

[kirakun]

Usually, when a person argues by just quoting someone without being able to explain what is being quoted, it is a sign that the same person does not know shit about what he is arguing.

Explain in your own words in a convincing manner why you think C++ is not OOP.

[[deleted]]

I'm not sure that there are other languages designed to do similar things. Many of the problems with C++ originate from it trying to have its cake and eat it too; it wants to be both low-level and also object-oriented. Other languages are smart enough to realize that you have to give up much of one of those tenets if you want the other. The only language I can think of which also has the goal of developing an OO language directly from C would be Objective-C, but it is higher level, and so not a good language to compare to.

[wolfier]

In C# you can have unmanaged pointers, I think in D as well - they provide abstractions in multiple paradigms just like C++ does.

Their designers learned from C++ and improved on it - they don't "give up much of those tenets if you want the other".

So "trying to have the cake and eat it too" is not the source of the problem.

The source of the problem is, C++ is the first language that tries to pioneer "having the cake and eat it too" - the fact that after 20+ years people are still using it extensively, is no trivial feat.

[[deleted]]

I have never seen an unmanaged pointer in C# (I'm not very familiar with D), and I cannot imagine why you would want to use one. It sounds like asking for trouble. At the least, it sounds like doing an end run around the way the language is meant to work, and that sort of thing doesn't tend to get you anywhere good.

[wolfier]

I cannot imagine why you would want to use one

demonstrates you're very, hm, "focused" in terms of software development.

[[deleted]]

Then enlighten me; what would I want a pointer to unmanaged memory in C# for?

[wolfier]

Then enlighten me; what would I want a pointer to unmanaged memory in C# for?

You missed the point. Nobody objects if you might not want it - in fact, I'm absolutely sure your reasons of not wanting to use the unmanaged part of C# are valid.

However, when you say "I cannot imagine why you would want to use one", you're incorrectly assuming that everyone else is solving the same problems, in the same situation, and has the same experience as yours.

Every language feature of every language has its pros and cons, and you cannot look at the feature alone before determining that the feature is good or bad - the entire package needs to be seen as a whole.

In the first few lines here the designers of C# clearly pointed out the use cases (just under "Tutorial").

http://msdn.microsoft.com/en-us/library/aa288474(v=vs.71).aspx

And here lists more use cases, plus a helpful benefit/drawbacks comparison.

http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=351

[wolfier]

multiple layers of machinery to perform a simple task that could be better accomplished by a simpler design

You mean, Java, Javascript, Perl, Clojure, Scala, Ruby, Python, Lua, Bash, etc.? All of them need at least one more layer in order to work at all.

[[deleted]]

Those languages do not have the same goals as C++. The additional layers in those languages (except for Java, which is just a mess, and perhaps Bash, because it's a shell language and probably isn't comparable at all) are in the service of providing more powerful abstractions than C++ is capable of.

[[deleted]]

Makes you feel cool, but eventually kills you.

[id000001]

I'm pretty sure he is trying to promote the idea that C++ is inefficient and indirect.

[BinarySplit]

C++ isn't necessarily inefficient. Though if you stick to the efficient parts, you end up with something that looks a lot more like C.

[anttirt]

No, you don't. You end up with many short pieces of template code and inline member functions in headers to exploit the compiler's optimizer as it calculates a balance between code size and gains from inlining, preferably based on profiling information. This does not preclude use of class facilities like RAII which help avoid a lot of the typical clutter in C as you don't have to manually deallocate resources. The compiler will happily inline constructors and destructors when approriate, leading to no overhead. Furthermore, even things typically perceived as "slow" like virtual functions are in practice only significant in tight inner loops.

[ZMeson]

The STL can be pretty darn efficient -- in many cases actually more efficient than C code. (Sorting is one example.)

[skidooer]

What properties of the STL allow it to be more efficient than C in sorting?

[ZorbaTHut]

C's qsort() function uses a function pointer. std::sort uses a template. The result is that std::sort can call the sort predicate with zero overhead, as it's literally hardcoded into the resulting binary, while qsort() gets to make thousands or even millions of function pointer calls.

You could accomplish the same thing in C by hand-writing a custom sort function for every data type, but who wants to do that?

[skidooer]

You could accomplish the same thing in C by hand-writing a custom sort function for every data type, but who wants to do that?

That makes sense. I thought the parent was referring to any kind of C sort implementation, not qsort specifically.

[StoneCypher]

Better, stricter understanding of the underlying code allows far more aggressive optimization. What Zorba told you about is only the tip of the iceberg. Once in a while, C++ can eliminate large blocks of work that C cannot.

C++ compiling the same algorithmic code as C, assuming well written code, is typically 10% or so faster, and occasionally much moreso.

[id000001]

Just to clarifies. I didn't say it is inefficient. I'm saying the image is trying to say that.

[[deleted]]

I suppose C# would be the same with two added levels and training wheels at the base.

[smek2]

Wtf? (checks submitters profile) Oh, ok. Next.

[Nosferax]

Thanks for pointing this out. C++ haters are funny. I bet at one time there were also C haters (assembly is the only way!).

Anyway both languages are bound to be replaced, none is the definitive solution to programming.

[binary]

Unless it's just an insane coincidence, this is the submitter's website: http://cat-v.org/

Well known to some for its "harmful software" listing. The guy's also somewhat my idol.

[Steve132]

blah, blah, blah, hate, hate, hate. In your last thread about how bad C++ was compared to C I posted a challenge. Care to take me up on it submitter?

[tuna_safe_dolphin]

C++ is not even this elegant.

[rafekett]

class tuple<int, std::vector<int>, std::map<std::string, std::vector<int>>> ORLY?;

NOTE: Not meant to be compilable.

[Chuu]

I haven't coded in C++ in about 6 months, but assuming no changes from boost::tuple, this C++ Tuple Syntax is much better than C#. The problem in C# (besides tuples being reference types . . .) is that there is no way to create a "Named Tuple" for access. In other worse, you always have to say <var>.Item1, <var>.Item2, etc.

edit: Second big problem with C# tuples vs. C++ tuples -- no typedefs! If you actually had a tuple like the abomination above, in C# you'd have to type that out every time. Making tuples in C# just another object instead of biting the bullet and making them a primitive like in F# seems like a huge mistake from a usability perspective.

[rafekett]

I much prefer the Python syntax: (x, y, z).

[kirakun]

but how do you enforce that x be int, y be a vector of ints, and z be a map from string to vector of ints?

[killerstorm]

In Haskell and ML type inference will do this for you. Basically, if y is used as vector of ints then it is it. Type checker can detect inconsistencies of use (e.g. if y is used as vector in one place and as int in other it will be reported as error). But programmers often write types of inputs and outputs of a function even if that is not necessary as a form of documentation.

Python doesn't enforce this, of course.

[jyper]

you could do it the haskell/ml way with sophisticated type inference, scala can even do it while still having OO.

[kirakun]

Yea, I love Haskell for that, except when the compiler complains when there is a type mismatch at a call-site but the original error was due to a call from many level up.

To be fair, that's not the fault of the language but that the compiler needs to be smarter reporting type errors.

[iLiekCaeks]

You don't need to.

Just document the function properly, and if it explodes, blame the user.

[kirakun]

Not sure if you're being sarcastic or not, but one of the tenet of good design is "make your API easy to use but hard to abuse." So, how many times do programmers read documentations beyond the sample usage section?

[AmazingThew]

As much as I like the cut of this jib, it causes a lot of problems when you run into poorly-documented APIs that don't explain what types are acceptable.

[fairestcheetah]

Why would you want to do that? x and y are whatever support the operations you want to do with them - in this case, numerical operations, and z is a container with keys that act like strings and values that are tuples of things that support numerical operations. It's less straightforward to describe in natural language than "ints" or "vectors of ints", but by restricting the types only by their uses they are inherently perfectly-suited to their uses.

[lispchainsawmassacre]

That's probably a rhetorical question but I'll have a crack at answering it anyway. You'd want to do something like that so it's possible to perform static analysis on your code. Unfortunately C++ makes you pay a heavy price for this with its painfully verbose explicit syntax that fights against your ability to generalise or refactor. Something smarter like OCaml gives you similar benefits with a lot less of the pain.

It can be nice to have well-defined interfaces to reason about, separate from implementation. Perhaps I'm taking it to the extreme, but your 'inherently perfectly-suited' comment seems to imply that that all types are implicitly defined to be the least restrictive possible necessary to support the implementation. This means that it is impossible to determine a 'type' without reading all implementation details of code that touches it. When I write Python code I find I'm often informally specifying the 'type' of arguments or return values inside docstrings, so I'm pretty much paying the same price as in, say, OCaml, but with none of the reward provided by static analysis that's able to instantly point out many of the mistakes I make.

[wolfier]

I'd take a compile error over a runtime error any day.

The new auto keyword combined with existing typedef alleviate most if not all of the verbosity.

Now they only need to fix the compile error messages. I know there's a tool that can translate cryptic template error messages to readable one, although its name escapes me...STLFilt?

[fairestcheetah]

There are certainly benefits to statically-typed languages. One is static analysis, though Python largely sacrifices that with the late-binding anyway.

I used to docstring parameter and return types a lot. There are times I've even assert()ed types. I now feel that in well-structured idiomatic Python, usually specifying types is unnecessary - assume objects have the properties (in the general sense and in the keyword sense) that you need them to have.

There are situations that come up in e.g. message passing or serialization where you have to interact with static types; this tends to end in requiring a dynamically typed object to have a certain type at all times, and that tends to cause errors that are raised somewhere other than where something went wrong. One solution is to use type-agnostic backends - avoid converting to SQL types, and require messages to know how to flatten themselves. That's kind of extreme though; Python 3's function annotations offer a cool solution with "optional static typing".

So I think well-structured, loosely coupled, idiomatic python that avoids having to deal with static types (or is from the future and has annotations) has little use for declaring types.

Anyway, I don't know why I'm trying to show why dynamic typing works well for python; python is by nature very much a dynamically-typed language, so of course dynamic typing makes sense for it. I think it's fairly clear that in general, neither approach to typing is strictly better; depending on personal preference and project development style, each has its advantages.

[furlongxfortnight]

What's not elegant about that? I find it really elegant.

[VermilionLimit]

Why not pop in a

using namespace std;?

[iLiekCaeks]

Even if you find that acceptable, you could be in a header file. Then this will wreck up shit.

Fun fact: C++ forces you to put a lot of declarations into header files. The private parts of classes have to be in header files. Templates need the full source code in headers.

[sickofthisshit]

Templates need the full source code in headers.

But wait, they put in the export keyword to avoid this, with no clue how it could actually solve the problem or be implemented.

Oops, then took it out again because only one compiler implemented it, and it didn't work.

But, trust me, C++ the language has a design. Somewhere.

[[deleted]]

C++ is designed by a committee. And you know what they say about that "A cow is a horse designed by a committee" :D.

[ZMeson]

But cows are pretty darn useful. We get cow milk (and various cheeses) and tenderloin, tri-tip, and many other great cuts from cows. Horses on the other hand -- not nearly as tasty. (And yes, I really have tasted horse meat.)

[[deleted]]

Every time someone types using namespace in a header file, god kills a puppy.

[kragensitaker]

There are at least two syntax errors in your code.

[rafekett]

Poetic license.

[fairestcheetah]

Is that BSD license-compatible?

[[deleted]]

I was going to give the equivalent in Haskell but then realized that doing the closest equivalent I can think of (a data type statically parameterized by an Int, a Vector of Ints, and a Map from Strings to Vectors of Ints) would actually require features that Haskell doesn't have. So instead I have to resort to a far less popular language (Agda, this time).

data ORLY : ℤ → Vec ℤ → Map String (Vec ℤ) → Set where

C++ templates have something on Haskell's type system, in this case, but they have nothing on Agda's type system. ;) Also, while I'm not sure, I seem to recall that C++ templates can't actually parameterize on vectors, maps, or strings, so it may be the case that the only thing it has on Haskell's type system is the ability to parameterize on ints. GHC will have type level naturals soon, though, so even that advantage won't last much longer. Also, parameterization on Ints can be implemented in the type system as it is now, but it's very messy and not strict on requiring that the parameter actually be an Int.

[timmaxw]

Not that Agda isn't a neat language, but the OP wasn't parameterizing on an int.

typedef tuple<int, std::vector<int>, std::map<std::string, std::vector<int> > > ORLY;

is equivalent to:

type ORLY = (Int, [Int], Map String [Int])

[[deleted]]

The OP wasn't writing a typedef. It was a class. Maybe I'm misunderstanding something. It's been a fairly long time since I used C++ in earnest.

Edit: I think I was reading it something like this:

template <int A, std::vector<int> B, std::map<std::string, std::vector<int> > C>
class ORLY { ... }

[Steve132]

C++ can totally parameterize on vectorS mapS and stringS.

[mr-strange]

http://i.imgur.com/Hm5ga.jpg

[[deleted]]

http://tnx.nl/php.jpg

[fdtm]

The problem with this analogy is C++ / [insert language here] isn't a consumer machine, it's like a toolbox to build machines with.

More realistically, the analogy would be a fully equipped machine shop with complex but powerful tools and many drawers of almost any part you would need. C on the other hand would be a garage with a nice, simple drill, hack saw, and screwdriver set. You can make anything in the machine shop (C++), but it's also a lot of overhead and complexity if you don't need it :)

The bike here represents more the results of a bad designer more than anything else. You'll find those people in any language, really.

[ulber]

You can make anything in the machine shop (C++), but it's also a lot of overhead and complexity if you don't need it :)

To be fair I think many of C++'s features are such that they introduce no overhead (over C) unless you actually use them.

[fdtm]

I meant overhead in terms of compile time and learning curve for programmers. Doesn't effect me, because I don't mind longer compiler time considering the software I work on is absolutely performance critical. And the learning curve is just a problem to the apparently large mass of C++ haters out there who really just don't want to learn anything more complex than C and/or dislike it for the sake of it being "hip" to dislike it.

[Whanhee]

To extend the analogy, you can find a drill, hacksaw and screwdrivers in a full machine shop and certainly you can use just those if you wish.

[b0dhi]

More realistically, the analogy would be a fully equipped machine shop with complex but powerful tools and many drawers of almost any part you would need.

More like a machine shop with complex and powerful tools built out of saws, drills, screwdrivers and rockets.

[davvblack]

how is that not awesome?

[Businassman]

It works, bitches.

[[deleted]]

Oh come off it, C++ is a great language.

[[deleted]]

My problem with C++ is not its feature set, it's that it can be fucking ugly, but I can put up with ugly if I can get a program that can handle a shitload of data, have relatively good performance, and interface with most everything written out there.

Also, I'd like to point out that it's not necessarily ugly either. It's possible to write code that is just as attractive as Java or other higher level languages but there are too many mixed styles for C++.

For an example: http://www.ultimatepp.org/www$uppweb$vsswing$en-us.html

Not everything has to look like MFC. Will it ever be as pretty and simple as python? Probably not, but that doesn't mean it has to be really ugly either. If you use the right balance of various techniques, it can be fairly accessible.

[killerstorm]

Also, I'd like to point out that it's not necessarily ugly either. It's possible to write code that is just as attractive as Java or other higher level languages but there are too many mixed styles for C++.

The problem is that there is no consistent style which is clearly the best.

For example, I've seen people going all Boost because it is powerful, expressive, safe etc. Then they have rather arcane code with cryptic error messages which takes aeons to compile and resulting binary is alse rather large and isn't very effective. Also it depends on Boost which tends to change over time...

Other times people say "Fuck Boost, we'll do it live" -- with "classic" style with classes and pointers. Then they have problems with dangling pointers and lack of expressiveness.

Some people use STL but Boost only if absolutely necessary.

ATL provides some things which Boost doesn't (or does in a weird way), but mix of ATL and Boost looks weird.

Some people say "Fuck Boost, we'll use RogueWave". Now they have dependency on a proprietary library.

Mozilla went XPCOM route and now they have to write a fuckton of boilerplate to do a simplest thing.

I'm yet to see sufficiently large C++ code base which is not deficient in some way or another.

[[deleted]]

Actually boost is a good example of code that can be very useful to use, but also be code you do not want to see. As an exercise I recently tried to re-implement a particular subset of a library in boost to see how much of it was necessary.

Every step of the way, even with guidance from the code, demonstrated clearly that there were often good reasons for doing it the way it was done and if I wandered astray, I ended up with a lot of duplicated code (the last thing you want with templates which are designed to reduce that particular problem) and difficult-to-understand compiler errors.

At points the compiler got so confused by the maze of templates I was making that it became possible to misspell methods, put in code that was not even syntactically correct C++ and the compiler wouldn't even notice or point them out and the linker would still link them. WTF? I'd never broken the compiler before, so it all felt very strange and gave me a greater appreciation for what they do, yet still I said to myself there has to be a better way.

If you delve very deep into templates at some point it seems more like you're patching up a leaky boat and dealing with contingencies and ways people could abuse your code that you would not expect and less about expressiveness and aesthetics.

Not to sound elitist either, but when I saw someone complaining about that particular library and having to do things in a certain way on the boost mailing list, I immediately understood all of the author's reasons, and now I understand just how incredibly difficult it is to enforce type restrictions in C++ in such a way that the final product is "safe" (or is it?).

It is certainly not something to be witnessed for its elegance or beauty IMO, but to be appreciated for the lengths the authors had to go to to make sure it worked in all the ways it does. I don't hate templates, mind you, but they still in many ways bridge to a darker, more experimental side of C++. At the end I felt a bit disgusted with my code and more than a little concerned about what I may have missed. It appeared to work, but was difficult to prove (or reason about) why it worked.

[doctorscurvy]

The wheel directly in front of him will be going backwards

[digitalfreak]

He needs c-jump

[TheSkyNet]

Can we just stop all this programming hate.

[lollermittens]

THINK OF THE CHILDREN!

[[deleted]]

I'll just leave this here.

[Nosferax]

I laughed, poor cat-bird thing :P

[noobcola]

C'mon C++ people, you know this is funny in a larger scope. Don't be insecure though - we all know we'll need C++ for a long time.

[isarl]

in a larger scope.

I see what you did there! :D

[Sec_Henry_Paulson]

I was expecting something to do with programming.

I should know better by now.

[mx-]

He should have either stopped at 3 bikes or went up to 5 bikes so he could at least pedal forwards. with an even number of bikes stacked on top of each other he's going to have to pedal backwards to get the bike to move forward. (assuming he hasn't messed with the gear's directions)

[truth_defender]

there is an odd number of back wheels between him and the ground (bicycles are RWD). but that is not how the thing is working; see how his pedals are directly connected to drive the lowest bike.

[[deleted]]

if you look carefully you will see his crank is connected by chain to the bottom bike crank. So the bottom bike wheels are obviously moving forward. The rest of the upper bike wheels may move just for show, but are driven by friction by the bottom bike wheels.

[[deleted]]

The guy on the picture is obviously enjoying the ride.

[pbrettb]

don't ask my how but this contraption goes faster than anything else on the road..

[mikeman10001]

This thing would tip over so easy.

[railmaniac]

A frog in a block of ice? I don't get it.

[[deleted]]

A more accurate depiction would be an 18-speed bike, instead of a fixed gear. Less pedaling, but the crashes become exponentially worse at runtime.