6 ms·

no. you put that thing in the language. fix the language. This kind of nonsense is why people don't like using c++, I remember Qt had a similar thing with QThre

no. you put that thing in the language. fix the language. This kind of nonsense is why people don't like using c++, I remember Qt had a similar thing with QThread. They published a popular article called QThread you're doing it wrong, and it turns out their own documentation was doing it wrong.

jjnoakes 10y ago
Except in C++, std::endl has been documented from the start to end the line and flush the buffers.
- dicroce 10y ago
  But why couldn't it have been named std::eol_flush? or something else that communicates what it actually does?
  - jjnoakes 10y ago
    Who said it couldn't have been named std::eol_flush? And why do you think its name (std::endl) doesn't match its effect (ends the line)?
    - smitherfield 10y ago
      It does match one effect, but it doesn't match the most important effect (flushes the output stream). And so a lot of people get the wrong idea. (I had multiple experienced professors teach me that std::endl was the "C++ way" as opposed to "\n" being the "C way"). You always want to follow the Principle of Least Astonishment. Suppose a hypothetical programming language has two DSLs for interfacing with SQL databases. Which of these is immediately understandable without having to consult the docs? Which one are you more likely to "learn" in a way that litters your codebase with subtle bugs? // Returns the SQL query as a string DB.table("users").where("id").in($args).toSQL() // Returns the results of the query DB.table("users").where("id").in($args) // Locks the DB connection and returns the results of the query DB.conn.lock() { DB.table("users").where("id").in($args) } vs. // Returns the SQL query as a string DB.query.find("users", ["id", sqlSafe($args)]) // Returns the results of the query DB.query.find("users", ["id", sqlSafe($args)]).run() // Locks the DB connection and returns the results of the query DB.query.find("users", ["id", sqlSafe($args)]).exec()
      - jjnoakes 10y ago
        You assume "ending the line" means only "move to the next line". But "ending the line" could just as easily mean "ensure the line reaches its destination". If it was called std::newline I would agree with you about it being misnamed. But it isn't called that. Could the name be better? Maybe. Bike shedding.
        smitherfield 10y ago
        >You assume "ending the line" means only "move to the next line". But "ending the line" could just as easily mean "ensure the line reaches its destination". Besides the other suggestions, I'd say something like std::eof_nl would make that interpretation a lot more obvious. Although like others I'd question the need for it at all as opposed to just an explicit "\n" << std::flush . >Bike shedding. I don't think anything is "bike shedding" when it comes to defining the standard library of a programming language (especially one for which all updates to the standard must maintain 100% backwards compatibility). (Not) choosing descriptive identifiers might not have the glamour of defining semantics or optimizing performance, but it can have huge real-world implications. The (std::endl == "\n") misconception is enormously widespread even amongst experienced C++ people, and is one of the most common sources of performance issues with the language.
        jjnoakes 10y ago
        You would propose std::eof_nl and have it not mean "end of file something"? > [std::endl] is one of the most common sources of performance issues with the language. Citation needed.
  - kazinator 10y ago
    Because that name is too verbose for regular use. People would hate it and make their own ad hoc nicknames for it not to have to type eol_flush: // ef -> std::eol_flush template class <typename X, typename Y> basic_ostream<X, Y> &ef(basic_ostream <X, Y> &os) { return std::eol_flush(&os); } A four-letter name could have been found with better mnemonic value covering the full semantics. We can look toward assembly languages for inspiration: they pack a lot into one, two, three or four letters. For instance std::nlfl (add NewLine and FLush). It's been years since I used C++ iostreams. I totally forgot that endl also flushes. When I saw this submission, my reaction was: what is this fuss about. Then "oh, right! That endl manipulator flushes, even on a fully buffered stream!". The name didn't remind me of this at all; but "nlfl" would almost certainly have served that purpose.
hellofunk 10y ago
endl is not broken, and does not need fixing. it's one of several ways to do things and this video is pointing out that its documented features may not be exactly what you want, and alternatives are available. However, sometimes endl is indeed what you want. There is nothing to "fix" here, except maybe your attitude.
- stormbrew 10y ago
  I think there's a valid argument to be made that it is at least poorly named, and that naming has resulted in people using it wrong, including among people who teach the language and so compound the problem.
  - arcticbull 10y ago
    Agreed, names are the first line of documentation. Having endl flush is like using single letter variable names, but maybe a bit worse since single letter variables make you go find where they were declared but this lulls you into a false sense of security. This violated the principal of least surprise enough that someone made a 10 minute long video on it :) It's really hard to blame the user this time.
    - smitherfield 10y ago
      People not using descriptive names for the important stuff is probably my number one pet peeve. We're not on a VAX, bytes aren't precious, and we aren't naming terminal commands, keystrokes aren't either. And nowadays every editor has autocomplete, so there's really no excuse.
      - arcticbull 10y ago
        The great vowel shortage of the late 80s is finally behind us :)
- byuu 10y ago
  I don't see any reason why, in the few instances you actually intend to flush, you won't just say << std::flush. This will make it very clear that you intend to flush the output. And we should definitely be prioritizing the documentation of our intentions over shaving a few bytes off of our source code file sizes. It was weird to ever merge two unrelated functions into something, and then name it something as cryptic as "endl". Especially when the most common case novices would encounter this would be std::cout, where terminals will automatically flush text to the screen upon receiving "\n" anyway.
slavik81 10y ago
> I remember Qt had a similar thing with QThread. They published a popular article called QThread you're doing it wrong, and it turns out their own documentation was doing it wrong. The main thrust of that article [1] was suggesting a new way to use the existing class and pointing out common mistakes he'd seen. Yeah, the docs were slightly outdated and needed a little TLC. They didn't mention the alternatives that had recently been made possible, but that's hardly an earth-shattering mistake. [1] http://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/ http://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/

jjnoakes 10y ago

Except in C++, std::endl has been documented from the start to end the line and flush the buffers.

dicroce 10y ago
But why couldn't it have been named std::eol_flush? or something else that communicates what it actually does?
- jjnoakes 10y ago
  Who said it couldn't have been named std::eol_flush? And why do you think its name (std::endl) doesn't match its effect (ends the line)?
  - smitherfield 10y ago
    It does match one effect, but it doesn't match the most important effect (flushes the output stream). And so a lot of people get the wrong idea. (I had multiple experienced professors teach me that std::endl was the "C++ way" as opposed to "\n" being the "C way"). You always want to follow the Principle of Least Astonishment. Suppose a hypothetical programming language has two DSLs for interfacing with SQL databases. Which of these is immediately understandable without having to consult the docs? Which one are you more likely to "learn" in a way that litters your codebase with subtle bugs? // Returns the SQL query as a string DB.table("users").where("id").in($args).toSQL() // Returns the results of the query DB.table("users").where("id").in($args) // Locks the DB connection and returns the results of the query DB.conn.lock() { DB.table("users").where("id").in($args) } vs. // Returns the SQL query as a string DB.query.find("users", ["id", sqlSafe($args)]) // Returns the results of the query DB.query.find("users", ["id", sqlSafe($args)]).run() // Locks the DB connection and returns the results of the query DB.query.find("users", ["id", sqlSafe($args)]).exec()
    - jjnoakes 10y ago
      You assume "ending the line" means only "move to the next line". But "ending the line" could just as easily mean "ensure the line reaches its destination". If it was called std::newline I would agree with you about it being misnamed. But it isn't called that. Could the name be better? Maybe. Bike shedding.
      - smitherfield 10y ago
        >You assume "ending the line" means only "move to the next line". But "ending the line" could just as easily mean "ensure the line reaches its destination". Besides the other suggestions, I'd say something like std::eof_nl would make that interpretation a lot more obvious. Although like others I'd question the need for it at all as opposed to just an explicit "\n" << std::flush . >Bike shedding. I don't think anything is "bike shedding" when it comes to defining the standard library of a programming language (especially one for which all updates to the standard must maintain 100% backwards compatibility). (Not) choosing descriptive identifiers might not have the glamour of defining semantics or optimizing performance, but it can have huge real-world implications. The (std::endl == "\n") misconception is enormously widespread even amongst experienced C++ people, and is one of the most common sources of performance issues with the language.
        jjnoakes 10y ago
        You would propose std::eof_nl and have it not mean "end of file something"? > [std::endl] is one of the most common sources of performance issues with the language. Citation needed.
- kazinator 10y ago
  Because that name is too verbose for regular use. People would hate it and make their own ad hoc nicknames for it not to have to type eol_flush: // ef -> std::eol_flush template class <typename X, typename Y> basic_ostream<X, Y> &ef(basic_ostream <X, Y> &os) { return std::eol_flush(&os); } A four-letter name could have been found with better mnemonic value covering the full semantics. We can look toward assembly languages for inspiration: they pack a lot into one, two, three or four letters. For instance std::nlfl (add NewLine and FLush). It's been years since I used C++ iostreams. I totally forgot that endl also flushes. When I saw this submission, my reaction was: what is this fuss about. Then "oh, right! That endl manipulator flushes, even on a fully buffered stream!". The name didn't remind me of this at all; but "nlfl" would almost certainly have served that purpose.

hellofunk 10y ago

endl is not broken, and does not need fixing. it's one of several ways to do things and this video is pointing out that its documented features may not be exactly what you want, and alternatives are available. However, sometimes endl is indeed what you want. There is nothing to "fix" here, except maybe your attitude.

stormbrew 10y ago
I think there's a valid argument to be made that it is at least poorly named, and that naming has resulted in people using it wrong, including among people who teach the language and so compound the problem.
- arcticbull 10y ago
  Agreed, names are the first line of documentation. Having endl flush is like using single letter variable names, but maybe a bit worse since single letter variables make you go find where they were declared but this lulls you into a false sense of security. This violated the principal of least surprise enough that someone made a 10 minute long video on it :) It's really hard to blame the user this time.
  - smitherfield 10y ago
    People not using descriptive names for the important stuff is probably my number one pet peeve. We're not on a VAX, bytes aren't precious, and we aren't naming terminal commands, keystrokes aren't either. And nowadays every editor has autocomplete, so there's really no excuse.
    - arcticbull 10y ago
      The great vowel shortage of the late 80s is finally behind us :)
byuu 10y ago
I don't see any reason why, in the few instances you actually intend to flush, you won't just say << std::flush. This will make it very clear that you intend to flush the output. And we should definitely be prioritizing the documentation of our intentions over shaving a few bytes off of our source code file sizes. It was weird to ever merge two unrelated functions into something, and then name it something as cryptic as "endl". Especially when the most common case novices would encounter this would be std::cout, where terminals will automatically flush text to the screen upon receiving "\n" anyway.

slavik81 10y ago

> I remember Qt had a similar thing with QThread. They published a popular article called QThread you're doing it wrong, and it turns out their own documentation was doing it wrong. The main thrust of that article [1] was suggesting a new way to use the existing class and pointing out common mistakes he'd seen. Yeah, the docs were slightly outdated and needed a little TLC. They didn't mention the alternatives that had recently been made possible, but that's hardly an earth-shattering mistake. [1] http://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/ http://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/