View Poll Results: Do C++ output streams need a better interface?

Voters
3. You may not vote on this poll
  • Definitely

    0 0%
  • Doesn't even matter

    1 33.33%
  • Absolutely not

    2 66.67%
Multiple Choice Poll.

Thread: Do C++ output streams need a better interface?

  1. #1
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    277

    Do C++ output streams need a better interface?

    Do you ever get the feeling when you're working with std ostreams that there's just way too much typing going on? I do. Never quite understood why the left-shift operator was chosen either.

    So thinking about it for a bit and wondering just how much time and effort it would take to put a better output interface together. Started coding and then something like twelve lines of code later, I'm done!

    Code:
    /* osprint.hpp */
    
    #include <iostream>
    
    struct osprint
    {
     std::ostream& stream;
    
     osprint()
     : stream(std::cout)
     { }
    
     osprint(std::ostream& stream)
     : stream(stream)
     { }
    
     template <typename V>
     osprint& operator = (const V& rhs)
     {
      stream << rhs; 
      return *this;
     }
    };
    
    template <typename V>
    inline osprint& operator , (osprint& lhs, const V& rhs)
    {
     return lhs = rhs; 
    }
    
    #include <string>
    
    const std::string eol = "\n";
    
    /* Usage */
    
    #include <cmath>
    
    using namespace std;
    
    osprint out;
    
    int main()
    {
     out = "Euler's number is ", exp(double(1)), eol;
    }
    If that isn't a testament to the power of C++, I don't know what is!

    Anyway, I just like the interface better. Plus it's about half as much typing. Kind of doesn't work for those who use commas a lot to separate statements of course. But who really does that anyway?
    Last edited by Sir Galahad; 12-03-2019 at 06:22 PM.

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Out of curiosity, but have you tested your code?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    277
    Quote Originally Posted by laserlight View Post
    Out of curiosity, but have you tested your code?
    Well I compiled and ran it if that's what you're asking. Otherwise no. It has only been like an hour now so...

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Sir Galahad
    Never quite understood why the left-shift operator was chosen either.
    Probably because Stroustrup was thinking of cout << x as sending x to output, and cin >> x as sending from input into x, so using (abusing?) the shift operators was a nice way to indicate the "direction" of I/O.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    277
    Quote Originally Posted by laserlight View Post
    Probably because Stroustrup was thinking of cout << x as sending x to output, and cin >> x as sending from input into x, so using (abusing?) the shift operators was a nice way to indicate the "direction" of I/O.
    I just don't see it. So output is like doubling and input halving? Meh. Operator + would've been more natural than that at least.

    And what, no vote? Surely even witches have opinions...

  6. #6
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Sir Galahad
    I just don't see it. So output is like doubling and input halving?
    Think "arrows", not shift operators. This is why I included "abusing?" as a comment: it changes the meaning of the operators entirely.

    Of course, you did the same by using operator= to mean "output" rather than "copy/move assignment".

    Quote Originally Posted by Sir Galahad
    And what, no vote? Surely even witches have opinions...
    Okay then. I'll vote. Basically, you're tackling a non-problem: beyond student programs, test programs, logging, and debugging, overloading these operators aren't all that important: objects may well not have a single useful canonical form for the end user. Your suggestion thus breaks conventions without sufficiently good reason, and you offer no corollary for input. So nope.

    (Oh wait, I should have voted "Doesn't even matter" because that comes closer to my reasoning.)
    Last edited by laserlight; 12-03-2019 at 09:20 PM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #7
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    277
    Quote Originally Posted by laserlight View Post
    Think "arrows", not shift operators. This is why I included "abusing?" as a comment: it changes the meaning of the operators entirely.

    Of course, you did the same by using operator= to mean "output" rather than "copy/move assignment".

    Assigning a print object to a value and having that, well, print is not a very surprising result. Seems quite natural actually. Unlike associating output with "leftness" or something anyway...

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Sir Galahad
    Assigning a print object to a value and having that, well, print is not a very surprising result.
    Not really: with the original semantics of operator= it looks like you're trying to replace the output stream with the object. Surely that is wrong.

    The argument that these constitute abuse of operator overloading is that it would be semantically better to use named functions instead. Unfortunately, that makes it even more verbose if we want to stick to the chaining.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #9
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    277
    Quote Originally Posted by laserlight View Post
    Not really: with the original semantics of operator= it looks like you're trying to replace the output stream with the object. Surely that is wrong.

    The argument that these constitute abuse of operator overloading is that it would be semantically better to use named functions instead. Unfortunately, that makes it even more verbose if we want to stick to the chaining.
    Kind of pedantic but okay. I prefer function over form I guess. I would rather not have to type ten times what I could be just to be "semantically correct".

    Quote Originally Posted by laserlight View Post
    Basically, you're tackling a non-problem: beyond student programs, test programs, logging, and debugging, overloading these operators aren't all that important: objects may well not have a single useful canonical form for the end user. Your suggestion thus breaks conventions without sufficiently good reason, and you offer no corollary for input. So nope.

    (Oh wait, I should have voted "Doesn't even matter" because that comes closer to my reasoning.)
    Well I'm not so willing to waste my time sticking to arbitrary conventions. Sorry. Just being useful is enough for me. And stretching a language is good exercise anyway. For one thing you discover interesting mechanisms that you otherwise wouldn't have.
    Last edited by Sir Galahad; 12-03-2019 at 10:34 PM.

  10. #10
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Sir Galahad
    I would rather not have to type ten times what I could be just to be "semantically correct".
    I agree, which is why I'm fine with overloading operator<< for ostream. I'm also fine with what may be the most epic abuse of operator overloading ever: the Spirit parser framework, which tries to make a DSL for EBNF notation directly in C++ syntax.

    Quote Originally Posted by Sir Galahad
    Well I'm not so willing to waste my time sticking to arbitrary conventions.
    But this convention doesn't waste your time (notice that your convention only saves a little bit of typing and amounts to the same thing), and saves the time of readers of your programs having to understand your own arbitrary convention!

    Contrast this with Boost.Format, e.g.,
    Code:
    cout << format("%2% or %1%?") % 36 % 77;
    This library uses operator overloading too, but improves on ostream's operator<< syntax by allowing the programmer to specify a flexible format string, which is then interpolated by the arguments provided through operator overloading. The interpolation actually does rely on operator<< being overloaded for ostream, so the format string can thus handle objects of any type that has the overload.

    So, there is the cost of having to learn the syntax and conventions of this library, but there is considerable benefit in having the use of a flexible format string.
    Last edited by laserlight; 12-04-2019 at 12:05 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 5
    Last Post: 04-17-2019, 11:32 AM
  2. input/output streams
    By cybernike in forum C++ Programming
    Replies: 2
    Last Post: 08-07-2007, 11:15 PM
  3. Input/Output Streams
    By mikeprogram in forum C++ Programming
    Replies: 6
    Last Post: 12-23-2005, 02:58 PM
  4. output file streams
    By neilman88 in forum C++ Programming
    Replies: 1
    Last Post: 04-16-2003, 07:11 PM
  5. Checking for errors on output streams
    By Heraclitus in forum C Programming
    Replies: 1
    Last Post: 03-27-2003, 03:47 PM

Tags for this Thread