Re: cout vs std::cout

Discussion in 'C++' started by Hendrik Schober, Sep 28, 2008.

  1. Mark Casternoff wrote:
    > I'm getting back into C++ after a long hiatus (they didn't have
    > namespaces back then).
    >
    > I know this question is completely subjective, but I'd be interested in
    > hearing which is
    > the "better" style and what the pros and cons are (I'm using cout as
    > example, but it really
    > applies to any similar construct):
    >
    > 1) using std::cout;
    > cout << "This is a test";
    >
    > 2) std::cout << "This is a test";
    >
    > The difference being prefixing every cout with 'std' or declaring it
    > ahead of time. The second
    > method could be used if cout existed in more than one spot, but how
    > often is that an issue?
    >
    > I've seen both methods in code, but I'm seeing #2 a lot more frequently.


    Here's my EUR 0.02:
    I have heard lots of complaints that #2 produces longish, unreadable
    code from people who shy from it and never used it.
    OTOH, I have used #2 for about a decade now and worked on projects
    where it was required that /all/ identifiers have to be within some
    namespaces and that /all/ identifiers are to be addressed with their
    fully qualified name. So I /know/ that it isn't hard to read code
    which fully qualifies all identifiers after a short while of looking
    at such code (that's a "short" as in "weeks" or "months"). And this
    isn't only my personal POV. Most of the time I worked under the rule
    that using declarations (and even using directives!) where allowed
    within any local scopes not bigger than a function, but this was
    rarely ever used by anyone (with "rarely" meaning "far less than 1%
    of the project's code"). I suppose that was because, after a short
    while, people who really tried to work that way liked code better
    that used fully qualified identifiers. (I abhor code that uses a
    naked 'list' beside a naked 'cout', as I have no idea whether that
    is 'std::list' or some other identifier.)

    What I've learned, though, is to avoid creating namespaces which are
    long and hard to type right even after weeks ('StringUtility') of
    usage. :)

    HTH,

    Schobi
    Hendrik Schober, Sep 28, 2008
    #1
    1. Advertising

  2. Yannick Tremblay wrote:
    > In article <gbonpf$2ve$-online.de>,
    > Hendrik Schober <> wrote:
    >> Mark Casternoff wrote:
    >> OTOH, I have used #2 for about a decade now and worked on projects
    >> where it was required that /all/ identifiers have to be within some
    >> namespaces and that /all/ identifiers are to be addressed with their
    >> fully qualified name. So I /know/ that it isn't hard to read code
    >> which fully qualifies all identifiers after a short while of looking
    >> at such code (that's a "short" as in "weeks" or "months"). And this
    >> isn't only my personal POV. Most of the time I worked under the rule
    >> that using declarations (and even using directives!) where allowed
    >> within any local scopes not bigger than a function, but this was
    >> rarely ever used by anyone (with "rarely" meaning "far less than 1%
    >> of the project's code"). I suppose that was because, after a short
    >> while, people who really tried to work that way liked code better
    >> that used fully qualified identifiers. (I abhor code that uses a
    >> naked 'list' beside a naked 'cout', as I have no idea whether that
    >> is 'std::list' or some other identifier.)
    >>
    >> What I've learned, though, is to avoid creating namespaces which are
    >> long and hard to type right even after weeks ('StringUtility') of
    >> usage. :)

    >
    > So essentially, the virtual ban on "using" coupled with the compulsory
    > namespace for everything leads to the creation of crytic namespace
    > identifiers?
    > [Ridiculous example deleted]


    No. The next project introduced its string utilities
    in a namespace 'Strings'.

    > Yannick


    Schobi
    Hendrik Schober, Sep 29, 2008
    #2
    1. Advertising

  3. Yannick Tremblay wrote:
    > In article <gbqqk9$v30$-online.de>,
    > Hendrik Schober <> wrote:
    >> Yannick Tremblay wrote:
    >>> [Ridiculous example deleted]

    >> No. The next project introduced its string utilities
    >> in a namespace 'Strings'.

    >
    > But the point remains that "Strings" is less clear than "StringUtility".
    >
    > In this particular case, the loss of clarity is probably acceptable
    > but that virtual ban on namespaces is IMO a bad thing because I
    > think it encourages bad naming.


    Which ban?

    > Yannick


    Schobi
    Hendrik Schober, Sep 29, 2008
    #3
  4. Yannick Tremblay wrote:
    > In article <gbqvc0$2um$-online.de>,
    > Hendrik Schober <> wrote:
    >> Yannick Tremblay wrote:
    >>> In article <gbqqk9$v30$-online.de>,
    >>> Hendrik Schober <> wrote:
    >>>> Yannick Tremblay wrote:
    >>>>> [Ridiculous example deleted]
    >>>> No. The next project introduced its string utilities
    >>>> in a namespace 'Strings'.
    >>> But the point remains that "Strings" is less clear than "StringUtility".
    >>>
    >>> In this particular case, the loss of clarity is probably acceptable
    >>> but that virtual ban on namespaces is IMO a bad thing because I
    >>> think it encourages bad naming.

    >> Which ban?

    >
    > I did write *virtual* ban but sorry, I mean virtual ban of "using
    > namespace" not on "namespace" themselves.
    >
    > The exact quote was:
    > "Most of the time I worked under the rule that using declarations (and
    > even using directives!) where allowed within any local scopes not
    > bigger than a function,"
    >
    > IMO, this amount to a virtual ban. [...]


    <shrug>
    It's what usually all developers agreed on in those projects.
    It only encourages bad naming when you're afraid of typing
    (or whatever it is that makes people obsessed with writing the
    fewest possible characters.)

    > Yannick


    Schobi
    Hendrik Schober, Oct 1, 2008
    #4
  5. Yannick Tremblay wrote:
    > In article <gc0i06$qc8$-online.de>,
    > Hendrik Schober <> wrote:
    >> Yannick Tremblay wrote:
    >>> In article <gbqvc0$2um$-online.de>,
    >>> Hendrik Schober <> wrote:
    >>>> Yannick Tremblay wrote:

    > [...]
    >>> IMO, this amount to a virtual ban. [...]

    >> <shrug>
    >> It's what usually all developers agreed on in those projects.
    >> It only encourages bad naming when you're afraid of typing
    >> (or whatever it is that makes people obsessed with writing the
    >> fewest possible characters.)

    >
    > But you said it yourself:
    > "What I've learned, though, is to avoid creating namespaces which are
    > long and hard to type right even after weeks ('StringUtility') of
    > usage. :)"
    >
    > So it did encourage you to use shorter and less informative
    > identifiers [...]


    No. It encouraged to use names that are easier to type.
    That doesn't mean they had to be shorter or even less
    informative. (But that was when we used an editor that
    had no useful typing support. Nowadays probably nobody
    would care.)
    (Oh, and it was "Strings", not "String". :^> )

    > In this case, "String" might be acceptable but this a only the first
    > step on a slippery road. Be careful or the namespaces created by
    > worse programmers than yoursel will start ressembling hungarian
    > warts.


    Don't you think that a bunch of programmers who decide
    that they generally want to explicitly spell out every
    namespace name for every identifier have a typing pain
    threshold high enough to not to shorten names beyond
    usability?

    > Yannick


    Schobi
    Hendrik Schober, Oct 2, 2008
    #5
  6. Hendrik Schober

    Jerry Coffin Guest

    In article <gc27vf$nvj$-online.de>,
    says...

    [ ... ]

    > Don't you think that a bunch of programmers who decide
    > that they generally want to explicitly spell out every
    > namespace name for every identifier have a typing pain
    > threshold high enough to not to shorten names beyond
    > usability?


    Some of us have a bit of both. In particular, for years I've used
    namespace names that were intentionally _very_ long and would be (quite
    frankly) ridiculous to type out very often at all. In particular, to
    give nearly absolute insurance against namespace clashes, I usually
    include my name and the date of creation in the name of the namespace.
    For (a real) example: Jerry_Coffin_Julian_Date_Dec_21_1999.

    I then, however, use the namespace alias feature to create a short,
    easy-to-type alias for that, something like:
    namespace Julian = Jerry_Coffin_Julian_Date_Dec_21_1999;

    The rest of the code would then use things like Julian::year_day, just
    as if the namespace was named Julian.

    A namespace alias can also be useful for switching out code when
    necessary -- for example, at one time I had some problems with the
    implementations of a container or two in the standard library. To fix
    the problem I created replacement containers in my own namespace, but
    otherwise conforming to the interface for the containers in the standard
    library. Again, the namespace in which I put the containers had a long
    name that wouldn't be duplicated by accident -- but then I had:

    namespace containers = My_Replacement_Container_Namespace_Name;

    A few versions of the compiler later, when the compiler vendor had
    repaired their library code, I switched over to using that by just
    editing that line to read:

    namespace containers = std;

    As I recall, the editing to fix the code actually took less time than
    the re-compilation...

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Oct 5, 2008
    #6
  7. Jerry Coffin wrote:
    > In article <gc27vf$nvj$-online.de>,
    > says...
    >
    > [ ... ]
    >
    >> Don't you think that a bunch of programmers who decide
    >> that they generally want to explicitly spell out every
    >> namespace name for every identifier have a typing pain
    >> threshold high enough to not to shorten names beyond
    >> usability?

    >
    > Some of us have a bit of both. In particular, for years I've used
    > namespace names that were intentionally _very_ long and would be (quite
    > frankly) ridiculous to type out very often at all. In particular, to
    > give nearly absolute insurance against namespace clashes, I usually
    > include my name and the date of creation in the name of the namespace.
    > For (a real) example: Jerry_Coffin_Julian_Date_Dec_21_1999.
    >
    > I then, however, use the namespace alias feature to create a short,
    > easy-to-type alias for that, something like:
    > namespace Julian = Jerry_Coffin_Julian_Date_Dec_21_1999;
    >
    > The rest of the code would then use things like Julian::year_day, just
    > as if the namespace was named Julian.


    That's a good idea. But for the users of the code, 'Julian'
    wasn't really all that different from the ordinary namespaces
    we used to use.

    > A namespace alias can also be useful for switching out code when
    > necessary -- for example, at one time I had some problems with the
    > implementations of a container or two in the standard library. To fix
    > the problem I created replacement containers in my own namespace, but
    > otherwise conforming to the interface for the containers in the standard
    > library. Again, the namespace in which I put the containers had a long
    > name that wouldn't be duplicated by accident -- but then I had:
    >
    > namespace containers = My_Replacement_Container_Namespace_Name;
    >
    > A few versions of the compiler later, when the compiler vendor had
    > repaired their library code, I switched over to using that by just
    > editing that line to read:
    >
    > namespace containers = std;
    >
    > As I recall, the editing to fix the code actually took less time than
    > the re-compilation...


    :)

    (Implementing a bunch of std lib containers so that they have
    less errors than bought ones isn't something most of us finish
    on a sunny Sunday afternoon.)

    Schobi
    Hendrik Schober, Oct 6, 2008
    #7
  8. Hendrik Schober

    Jerry Coffin Guest

    In article <gcchsu$287$-online.de>,
    says...

    [ ... ]

    > > As I recall, the editing to fix the code actually took less time than
    > > the re-compilation...

    >
    > :)
    >
    > (Implementing a bunch of std lib containers so that they have
    > less errors than bought ones isn't something most of us finish
    > on a sunny Sunday afternoon.)


    The quick part was changing the code so it used the containers in the
    standard libary (after it was fixed) instead of my replacements. The
    replacements themselves did take just a bit longer (though my
    recollection is that implementing them wasn't quite as much work as I
    expected either).

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Oct 7, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pmb

    std::cout vs cout

    Pmb, Jun 2, 2004, in forum: C++
    Replies:
    2
    Views:
    4,397
    Leor Zolman
    Jun 2, 2004
  2. Stefan Ram

    Re: cout vs std::cout

    Stefan Ram, Sep 28, 2008, in forum: C++
    Replies:
    7
    Views:
    464
  3. Matthias Buelow

    Re: cout vs std::cout

    Matthias Buelow, Sep 28, 2008, in forum: C++
    Replies:
    10
    Views:
    597
    Hendrik Schober
    Oct 1, 2008
  4. saurabh29789

    Sending std::cout to std::cout !!

    saurabh29789, Jun 11, 2009, in forum: C++
    Replies:
    1
    Views:
    282
    Harald Finster
    Jun 11, 2009
  5. saurabh29789

    Sending std::cout to std::cout

    saurabh29789, Jun 11, 2009, in forum: C++
    Replies:
    2
    Views:
    333
    Rolf Magnus
    Jun 12, 2009
Loading...

Share This Page