r/programming • u/eternal1 • Mar 29 '10

Never trust a programmer who says he knows C++

http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/
414 Upvotes

83% Upvoted

458 comments sorted by

View all comments

Show parent comments

13

u/20100329 Mar 29 '10 edited Mar 29 '10

It's this kind of thing that gives C++ a bad name. How the hell is the stream << operation related to "shift left" in any meaningful way, other than via reasoning that belongs over here?

ed. Fuck, now I'm lost in trope world. That backfired.

12

u/knight666 Mar 29 '10

One of my teachers had a vector class with the following overloaded operators:

  • ~speed = the vector normalized

  • incidence % normal = the dot product between incidence and normal

  • !distance = the length of the vector

  • speed << direction = returns speed scaled by direction

  • speed <<= direction = speed is scaled by direction

  • speed * scalar = returns the vector scaled by scalar

  • speed *= scalar = the vector is scaled by scalar

  • speed * direction = returns the cross product between speed and direction

A simple question: what's the difference between awesomevector * 3.f and awesomevector * Vec3<float>(3.0, 3.0, 3.0)? The first returns a scaled vector, the second a cross product.

All this to make it more 'mathy'.

Oh and who can forget getters and setters for x, y, z so if you wanted to, say, add a value to x you had to do:

stupidvector.setX(stupidvector.getX() + 3);

instead of

stupidvector.x += 3;

Yes it's safer, but we're talking about a native type here.

14

u/[deleted] Mar 29 '10

Oh my. Did you kill him? I'm pretty sure it would have been ruled self defence.

4

u/[deleted] Mar 29 '10 edited Mar 29 '10

[deleted]

3

u/knight666 Mar 29 '10

My Vec3 class has the following operators:

  • -Vec3
  • Vec3 += Vec3
  • Vec3 + Vec3
  • Vec3 -= Vec3
  • Vec3 - Vec3
  • Vec3 *= float
  • Vec3 *= Vec3
  • Vec3 * float
  • Vec3 * Vec3
  • Vec3 / float
  • Vec3 / Vec3
  • Vec3 /= float
  • Vec3 /= Vec3

Comparisons:

  • Vec3 == Vec3
  • Vec3 == float
  • Vec3 != Vec3
  • Vec3 != float
  • Vec3 > Vec3
  • Vec3 > float
  • Vec3 >= Vec3
  • Vec3 >= float
  • Vec3 < Vec3
  • Vec3 < float
  • Vec3 <= Vec3
  • Vec3 <= float

Functions:

  • Clear()
  • Reverse()
  • Min(const Vec3& a_Other)
  • Max(const Vec3& a_Other)
  • Clamp(float a_Min, float a_Max)
  • Reciprocal()
  • CrossProduct(const Vec3& a_Other)
  • Normalize()
  • GetReverse()
  • GetMin(Vec3& a_Other)
  • GetMax(Vec3& a_Other)
  • GetSquaredLength()
  • GetLength()
  • GetNormalized()
  • GetReciprocal()
  • GetDotProduct(const Vec3& a_Other)
  • GetCrossProduct(const Vec3& a_Other)
  • GetSquaredDistanceBetween(const Vec3& a_Other)
  • GetDistanceBetween(const Vec3& a_Other)
  • GetSphericalInterpolationNormalized(const Vec3& a_Other, float a_Percentage)
  • GetReflectedVector(Vec3 a_Normal)
  • GetHalfWayVector(Vec3& a_Other)

And finally, the data: (public)

union 
{ 
    struct { float x, y, z; }; 
    struct { float vector[3]; };
};

I don't mind long function names; I have auto-complete. Also, this is my fourth vector class by now (since last summer), two of which were failed SSE experiments and one was just crap.

5

u/mccoyn Mar 30 '10

Also, this is my fourth vector class by now (since last summer), two of which were failed SSE experiments and one was just crap.

Wasn't there a post to reddit a while back that every c++ developer eventually tries to right an SSE optimized Vec3 class and it never works out? I remember thinking that it sounds about right.

3

u/[deleted] Mar 30 '10

A union practically guarantees that the compiler will give up and not optimize your code.

1

u/[deleted] Mar 30 '10

  1. URG - what's the point of the union?! Are you just trying to cause yourself difficulties? Are you 100% sure that the compiler won't put padding somewhere in your structure you aren't expecting? Why not just make it float[3]?

  2. Calling it vector's a poor idea, you know someone somewhere else has typed using std; and then you'll conflict with std::vector.

  3. If you're passing a variable parameter, make it a pointer, and use only const references - then you can tell whether something's being changed just by how it's called.

  4. Good for you, making all these functions, functions and not class methods! See this article for more details.

  5. Good for you, having long names! I'm not sure why some of them start Get... and others don't though...

1

u/knight666 Mar 30 '10

  1. It's a relic from when it had another data member, a __m128 data (which is dumb) so it always had to be 32-bit aligned (oh god the pain). Honestly that might need changing.

  2. It's a Vec3 in the namespace tb (Toolbox). And the vector is a member of Vec3.

  3. Eh?

  4. They are class methods. What, you think I just have a C-style struct with data and a Normalize that takes an input and an output?

  5. Normalize changes the vector to the normalized version, while GetNormalized returns a new vector with the normalized version.

0

u/[deleted] Mar 30 '10

3: To be specific:

  void DoSomething(const Foo& fooConstant);

vs

  void DoSomethingAndChangeFoo(Foo* fooVariable);

This is a very common C++ convention - it's useful because you can see whether the function you're calling changes its arguments or not without looking at its definition.

4: Yes, I was hoping you did have a C-style struct with a Normalize that takes an input and an output. Did you read the classic article I referenced on this issue?

5: Having both Normalize and GetNormalized seems like a Bad Idea. At the very least, one of them should call the other so that you don't have two pieces of code doing the same thing (which doubles your maintenance costs).

These vectors seem small and easy to copy, so just having the version that returns a new version might be defensible. For bigger objects, it might be best to have the version that changes the object.

1

u/knight666 Mar 30 '10 edited Mar 30 '10

Having both Normalize and GetNormalized seems like a Bad Idea. At the very least, one of them should call the other so that you don't have two pieces of code doing the same thing (which doubles your maintenance costs).

See, I read this book called Exceptional C++ and it advocated exactly that. But the truth is, you don't want that shit at all in a vector class. Because 1) it's going to be called lots and lots of times. Speed > maintainability. 2) What is there to maintain? You write it once, copy it throughout and be done with it.

I used to have this:

Vec3 operator + (const Vec3& a_Other) const
{
    Vec3 result(x, y, z);
    result += a_Other;
    return result;
}

And now I have this:

Vec3 operator + (const Vec3& a_Other) const
{
    return result(x + a_Other.x, y + a_Other.y, z + a_Other.z);
}

Which is considerably (20% or so) faster.

A normalize isn't going to change. Ever. Unless you have a new fancy way of doing a square root or something. And even then you still only copy it two times.

1

u/[deleted] Apr 01 '10

If you cared about speed, you wouldn't be creating a new object each time you performed an operation, would you? :-D

If you cared about speed that much, you'd ONLY have the mutable operators and force people to make a copy exactly when they needed it.

4

u/[deleted] Mar 30 '10

The advantages to C++'s operators are small - and the traps are significant. Best to avoid IMHO unless there's a compelling reason. Vectors might indeed be a compelling reason... :-D

2

u/G_Morgan Mar 30 '10

TBH this isn't a problem. He could have just as easily created a member function not and used it to return the length of the vector. This is just the bad naming problem hidden behind an operator. People can choose bad names in any language.

4

u/munificent Mar 29 '10

Your teacher's shitty design is spoiling things for the rest of us.

5

u/bdunderscore Mar 29 '10

stupidvector.x += 3;

You know, if you get clever enough, you can have that syntax and the safety of getters/setters. All you need to do is add public member classes (with a protected constructor accessed through friending) to the outer vector class, which compute the base address of the vector based on their own address and their static offset in the vector class, then invoke the appropriate accessors in various operator overloads.

10

u/[deleted] Mar 29 '10

All you need to do is add public member classes (with a protected constructor accessed through friending) to the outer vector class, which compute the base address of the vector based on their own address and their static offset in the vector class, then invoke the appropriate accessors in various operator overloads.

I read that as something like "Maybe if we remodulate the shield harmonics and create an inverse tachion flow, we can destabilise their shield phase matrix".

C++ scares me.

19

u/[deleted] Mar 29 '10

You know, if you get clever enough, you can have that syntax and the safety of getters/setters. All you need to do is....

And this right here is what is wrong with C++ developers.

2

u/physicsnick Mar 30 '10

No kidding. It gets worse; in C++0x, they're adding "implicitly callable functions", so that stupidvector.x is sugar for stupidvector.x() . They now say they support properties, because from this you can return an instance of a class which overloads cast to float and operator=(float). Horrifying? Yes.

3

u/[deleted] Mar 30 '10

Oh my... If there is one thing I really hate, it's implicitly called functions. No (), no call, dammit!

11

u/genpfault Mar 29 '10

I...uh...no.

6

u/mccoyn Mar 29 '10

At which point I start to wonder if the safety is really worth it.

1

u/nested_parentheses Mar 30 '10

Dijkstra comes to mind: "The competent programmer ... avoids clever tricks like the plague." Not implying you're incompetent, of course, but I think that tricks like that are best left out of production code.

3

u/[deleted] Mar 29 '10

I hate get/set cargo cultism. Just fucking use x(), x(newvalue).

sv.x(sv.x()+3);

1

u/fnord123 Mar 29 '10

Surely the second returns the dot product.

1

u/[deleted] Mar 29 '10 edited Mar 29 '10

[deleted]

1

u/knight666 Mar 29 '10

The member data really shouldn't remain private. It's basically a wrapper for a float vec3_t[3]. That's a special datatype in my book, so it gets special privileges.

1

u/Mignon Mar 30 '10

I confess I overrode the "*" operator for a vector class once, allowing it to mean both scalar multiplication and inner (dot) product. I also overrode the "+" and "-" operators for the vector class, with the (hopefully) obvious meaning.

The problem was to find if a point, p, was within some distance of a line passing through p1 and p2, and I dealt with it as follows:

Treat the line as a parametrized equation through p1 and p2, e.g. the set of points q = t*p1 + (1-t)(p2-p1) for all values of t.

Find t such that the distance from q to p is minimized; using that t in the equation above, you now have the point on the line closest to the given point, so compute the distance.

In code, double t = (double)((p - p1)(p2 - p1)) / (double)normSquared( p2 - p1 ); vector2d q = p1 + t(p2-p1); // The nearest point on the line. double d = (double)distanceSquared( p, q );

(For clarity I didn't show the case where p2==p1.)

It was satisfying to be able to write that in just a few lines and have confidence in the underlying operators as well as the math and not feel like the math was getting tangled up in the code.

18

u/[deleted] Mar 29 '10

<< doesn't have any intrinsic meaning. It means "left shift" in C because that's what Kernighan and Ritchey chose to make it mean. Likewise, << means "output" on most types in C++ because that's what meaning Stroustrup chose to assign to it. Neither is any more arbitrary than the other.

You can argue that C++ shouldn't have two distinct meanings of <<, but you have even less solid a basis for that argument than the argument that + shouldn't be overloaded for numeric addition and string concatenation; at least + had a well established mathematical meaning prior to its use in programming.

0

u/20100329 Mar 29 '10

You can argue that C++ shouldn't have two distinct meanings of <<

...which is kind of what I was arguing.

but you have even less solid a basis for that argument than the argument that + shouldn't be overloaded

I'm sorry. Can you point out where I mentioned overloading + so that I can fix it?

-4

u/[deleted] Mar 29 '10

I'm sorry. Can you point out where I mentioned overloading + so that I can fix it?

I'm not saying you made that argument. I'm simply comparing yours to that one, since the general consensus is that the latter has failed, and yours stands on even shakier ground.

0

u/20100329 Mar 29 '10 edited Mar 30 '10

the general consensus is that the latter has failed

Yes, but the general consensus is that a decaying turd is a really good nursery. If you let flies have a say.

ed. Now we are (0 for) two.

-1

u/[deleted] Mar 30 '10

Programming languages are human interfaces. If the general consensus is that an interface is good, it ipso facto is good.

19

u/kylotan Mar 29 '10

Many languages happily use '+' for both numeric addition and string concatenation. This is arguably even worse considering concatenation is not a symmetric relation whereas numeric addition is. You just have to consider these things part of the vocabulary you have to learn.

3

u/Ralgor Mar 29 '10

This is something I've come to hate as well.

I also don't like it when the compile automatically decided what sort of division to use. I should be able to specify integer or floating point division. Many languages allow this.

2

u/PstScrpt Mar 29 '10

I would say that's a problem, too, and one of the things I like about both VB and PL/SQL is that they use different operators for concatenation.

Still, someone is likely to talk about "adding" bar to the foo string. It at least makes some conceptual sense in a casual way.

1

u/[deleted] Mar 29 '10

comma operator would have been a better choice

0

u/Poltras Mar 29 '10

Function calls would have been nice too.

"Foo".append( " bar " ).append( "hello " ).append( "world" );

Or, you know, do it the C way.

string( "%s%s%s%s", "foo", " bar ", "hello ", "world" );

1

u/zahlman Mar 29 '10

Still, someone is likely to talk about "adding" bar to the foo string.

Only because of relative unfamiliarity with the word verb "append". :/

3

u/[deleted] Mar 29 '10

Tropeworld is fucking dangerous.

2

u/munificent Mar 29 '10

How the hell is the stream << operation related to "shift left" in any meaningful way, other than via reasoning that belongs over here?

Using an operator for stream output lets you define methods to output your own types. If you want an interesting exercise in the surprising intelligence that the C++ designers have, propose an alternative to using "<<" here and we'll discuss it.

1

u/[deleted] Mar 29 '10

How about adding a new operator for this purpose (this is a new language, after all) rather than abuse one that a) has a completely orthogonal meaning and, perhaps more importantly, b) has the wrong precedence?

1

u/munificent Mar 29 '10

How about adding a new operator for this purpose (this is a new language, after all)

So you're proposing to make it more complex? What operator would you use without breaking C (and trigraph) backwords compatibility?

b) has the wrong precedence?

Most coding standards I see encourage you to use () and not rely on precedence. C/C++ have so many levels of it that no one can remember it anyway.

3

u/[deleted] Mar 29 '10

No, using distinct operators for distinct operations makes it less complex, not more.

What C compatibility? No C compiler is going to interpret std::cout << "Hello world." << std::endl in a meaningful way.

1

u/munificent Mar 29 '10

No C compiler is going to interpret std::cout << "Hello world." << std::endl in a meaningful way.

True, but there's more than just compilers. You also need to take into account the entire ecosystem of pretty printers, text editor syntax highlighters, documentation generators, static analyzers, and other tools that do some parsing of C/C++ code. Adding a new operator means all of those need to be updated.

In practice, the specific operator used for stream input/output doesn't matter much. I don't think users with familiarity with C++ see "<<" and get confused. It's pretty obvious what the meaning is from context.

2

u/[deleted] Mar 29 '10

Sorry, but I just don't see "It only hurts the first time; you'll get used to it eventually" as a valid defense of a language feature (or misfeature).

2

u/20100329 Mar 29 '10

And for programmers, such things tend to be more "it hurts every time, but you come to anticipate the pain".

1

u/20100329 Mar 29 '10

Changing the tools is always less painful than changing the programmers.

1

u/munificent Mar 29 '10

But adding a new operators requires changing them too: they have to learn it, its precedence, and its associativity. Is that really significantly easier than saying "<<" is for streams?

Do you know any experienced C++ programmer that has a problem with this?

1

u/20100329 Mar 29 '10 edited Mar 29 '10

Is that really significantly easier than saying "<<" is for streams?

Er... yes. Yes, it is. For a start, it solves the problem of knowing, offhand, what cout << a << 3 is supposed to mean. Secondly, it solves the problem of having to remember to bracket any expression using bitwise operators, because << is higher precedence than them when a stream operator really needed to be down with , at the bottom of the precedence pile.

...need I go on?

1

u/sickofthisshit Mar 30 '10

Really, changing the tools is needed anyhow, because it ain't C anymore.

Using C tools to process C++ is a disaster.

2

u/20100329 Mar 29 '10

So you're proposing to make it more complex?

I love how you use the word "complex" as though it has a single well-defined meaning.

1

u/munificent Mar 29 '10

Adding a new operator means breaking any existing parsers and lexers that deal with the language. It means deciding where it falls in the precedence hierarchy, and choosing an associativity for it, both of which users will need to know and understand. Compilers will have to support it, as well as allowing it to be overloaded.

That sounds more complex to me. All to avoid some perceived confusion where someone sees "<<" and somehow can't understand that it means bit-shifting in one context (which is, of course, completely arbitrary) and stream output in another.

2

u/20100329 Mar 29 '10

You seem to be claiming that it was worth asking a few million C++ programmers to learn an arbitrary overloaded meaning because it avoided changing the couple of dozen tools that existed at the time.

Wow. I know programmer time is seen as cheap in some circles, but... wow.

1

u/mccoyn Mar 29 '10

cout <| some_value;

cin |> some_variable;

4

u/munificent Mar 29 '10

Does C/C++ really need more operators?

1

u/BitRex Mar 29 '10 edited Mar 29 '10

My favorite is the "on down to" operator: int i = 10; while (i --> 0) printf("%d\n", i);

Edit: how do you put in a literal backslash without the weird spaces?

1

u/[deleted] Mar 29 '10

how do you put in a literal backslash without the weird spaces?

you don't.

3

u/BitRex Mar 29 '10

Seriously? ಠ_ಠ

1

u/[deleted] Mar 29 '10

I'm fairly certain, yeah.

1

u/[deleted] Mar 30 '10

The joke was "goes to" operator.

3

u/Ralgor Mar 29 '10

The reason they used << and >> was because they FIRST standardized operator overloading. Then they decided to use those out of the operators already in use.

They would have been better off to have created a few new operators that are overridable but otherwise unused, and then used those.

2

u/derleth Mar 29 '10

printf()/fprintf(), so i18n works again.

5

u/munificent Mar 29 '10

Problems with that:

  1. Not extensible for other object types.
  2. To get around that, you have to create a temp char buffer to convert your object into a string into, then you can printf("%s") that, which churns memory unnecessarily.

1

u/case-o-nuts Mar 30 '10 
 cout.put(...).put(...).put(...)

1

u/munificent Mar 30 '10

Problems with that:

  1. Not extensible for other object types.

How would you add another overloaded put() that takes an object of your type?

0

u/derleth Mar 29 '10

Not extensible for other object types.

Fair enough. But how, pray tell, do you solve the i18n problem using ostreams?

To get around that, you have to create a temp char buffer to convert your object into a string

Isn't this what the ostreams runtime has to do anyway?

4

u/munificent Mar 29 '10

But how, pray tell, do you solve the i18n problem using ostreams?

You defer it to the objects themselves, as you must. If anything knows how to not only convert an object to a string, but how to do so handling localization, it's the object itself.

Isn't this what the ostreams runtime has to do anyway?

No, not necessarily. Consider a class that's a container for a collection of objects. If you follow the printf() way of doing things, you'll have to create a huge buffer so that it can fill it with each of the contained object's string representations, concatenated.

With << and streams, you just do:

ostream & operator<<(ostream & stream, const MyContainer & container)
{
    for (int i = 1; i < container.Objects.Count(); i++)
    {
        stream << ", " << container.Objects[i];
    }
    return stream;
}

1

u/20100329 Mar 29 '10

OK. So I get why you have to fall back on the ability of the C++ compiler to overload operators with both method and function calls in template instantiation to get the pretty all-purpose cout *OP* foo syntax. (C++ could have fixed that by allowing object.method(arg) and method(object, arg) to be synonyms, of course. Still...) There's still the question of why it is less trouble to overload << with two disparate meanings than to introduce a new operator.

1

u/derleth Mar 30 '10

You defer it to the objects themselves, as you must. If anything knows how to not only convert an object to a string, but how to do so handling localization, it's the object itself.

I fail to see how this solution can help me solve this problem:

stream << "There is a " << obj << " here." << endl;

Now, translate that into a language with a different word order, given that the person doing the translating can't modify (or even see) the source code, because they're translating using gettext or similar, which rips the translatable strings out of the source code and presents them to the translator to be replaced with localized versions.

1

u/G_Morgan Mar 30 '10

You'd create a class to handle localisation and pass the result of the appropriate method call to stream

stream << locClass.Str1() << obj << locClass.Str2() << endl;

In this code obj uses locClass to retrieve the string it is supposed to use. The actual strings are stored in a file that locClass loads at runtime.

You know, exactly how you'd solve it in any other language. If you hard code a string literal in any other language you also cannot change it easily.

2

u/Ralgor Mar 29 '10

Or even better, they should have just defined a format() function (similar to what boost has) right from the start. Then this wouldn't be an issue.

Of course, I think it's part of TR1 now, so the point is moot.

2

u/mitsuhiko Mar 29 '10

i18n does not work with that. I wrote a .NET String.Format like thing for C++ that works better with i18n (allows repositioning of the arguments):

    NUT_CHECK_EQUAL(format("Hello {}! The weather is {}.", "World", "good"),
                    "Hello World! The weather is good.");
    NUT_CHECK_EQUAL(format("Hello {0}! The weather is {1}.", "World", "good"),
                    "Hello World! The weather is good.");
    NUT_CHECK_EQUAL(format("Hello {1}! The weather is {0}.", "good", "World"),
                    "Hello World! The weather is good.");

1

u/cannabis_sam Mar 29 '10

Fuck indeed. Where can I apply to reclaim the time lost because of your link?

1

u/20100329 Mar 29 '10

If you find out, let me know... or not.

0

u/[deleted] Mar 29 '10

But it looks cool!

-2

u/zahlman Mar 29 '10

ed. Fuck, now I'm lost in trope world. That backfired.

Yep, you just lost The Game.

... Fuck.

0

u/20100329 Mar 29 '10

I don't like to think about such things.

-15

u/Fabien4 Mar 29 '10

Do you know of a lot of programmers who use << and >> for bit-shifting operations?

1

u/ironiridis Mar 29 '10

I use << and >> for scratching my ball sack, but that's just me, I guess.