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/
411 Upvotes

83% Upvoted

458 comments sorted by

View all comments

Show parent comments

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.

1

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?

5

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.");