using std::string; string("hello") vs std::string("hello") in header file.

Discussion in 'C++' started by Fei Liu, Mar 30, 2006.

  1. Fei Liu

    Fei Liu Guest

    In Accellerated C++, the author recommends that in a header file one should
    not declare
    using std::string, using std::vector etc instead one should directly specify
    the namespace specifier in code.

    for example, this is bad practice:

    header.h
    #include <string>
    using std::string;
    class a{
    string x;
    };

    instead, one should write:
    #include <string>
    class a{
    std::string x;
    };

    The reason given by the author is that 'using std::string' actually pollutes
    the scope where 'using std::string' is declared.
    I find this style is rather inconvenient when I want to experiment with
    different implementation of certain classes in large projects. For example,
    I may want to try myns::string or john::string, it's actually much easier to
    replace 'using std::string' to 'using myns::string' and instantly switch to
    another string implementation. This is much better than going through all
    the instances of 'std::string variable' and replace them to 'myns::string
    variable'.

    What are your thoughts on this coding style?
    Fei Liu, Mar 30, 2006
    #1
    1. Advertising

  2. Fei Liu

    Phlip Guest

    Fei Liu wrote:

    > In Accellerated C++, the author recommends that in a header file one
    > should
    > not declare
    > using std::string, using std::vector etc instead one should directly
    > specify
    > the namespace specifier in code.


    Doesn't it say "at top level"?

    > The reason given by the author is that 'using std::string' actually
    > pollutes
    > the scope where 'using std::string' is declared.
    > I find this style is rather inconvenient when I want to experiment with
    > different implementation of certain classes in large projects. For
    > example,
    > I may want to try myns::string or john::string, it's actually much easier
    > to
    > replace 'using std::string' to 'using myns::string' and instantly switch
    > to
    > another string implementation. This is much better than going through all
    > the instances of 'std::string variable' and replace them to 'myns::string
    > variable'.
    >
    > What are your thoughts on this coding style?


    In general, write a friggin "using std::string;" wherever you like, in fresh
    code where nothing is called "string" except the std:: class.

    The guideline is to never put anything in a .h file that could cause trouble
    in any .cpp file that includes it. This rule implies the area outside a
    class{} or namespace{} block should be reserved for things that absolutely
    must go there, and convenient things like typedef or using are more trouble
    than this minor convenience.

    In your case, you could write this in a header:

    namespace zone {
    // using john::string;
    using myns::string;
    }

    Now use zone::string everywhere you would have used std::string.

    (And please don't let us think you are redefining 'string' for your own
    nefarious purposes! Leave the std:: classes alone!!)

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 30, 2006
    #2
    1. Advertising

  3. Fei Liu

    Fei Liu Guest

    "Phlip" <> wrote in message
    news:59HWf.22277$...
    > Fei Liu wrote:
    >
    > > In Accellerated C++, the author recommends that in a header file one
    > > should
    > > not declare
    > > using std::string, using std::vector etc instead one should directly
    > > specify
    > > the namespace specifier in code.

    >
    > Doesn't it say "at top level"?


    I'll double check that tomorrow when I get a hold of the book again.

    >
    > > The reason given by the author is that 'using std::string' actually
    > > pollutes
    > > the scope where 'using std::string' is declared.
    > > I find this style is rather inconvenient when I want to experiment with
    > > different implementation of certain classes in large projects. For
    > > example,
    > > I may want to try myns::string or john::string, it's actually much

    easier
    > > to
    > > replace 'using std::string' to 'using myns::string' and instantly switch
    > > to
    > > another string implementation. This is much better than going through

    all
    > > the instances of 'std::string variable' and replace them to

    'myns::string
    > > variable'.
    > >
    > > What are your thoughts on this coding style?

    >
    > In general, write a friggin "using std::string;" wherever you like, in

    fresh
    > code where nothing is called "string" except the std:: class.
    >
    > The guideline is to never put anything in a .h file that could cause

    trouble
    > in any .cpp file that includes it. This rule implies the area outside a
    > class{} or namespace{} block should be reserved for things that absolutely
    > must go there, and convenient things like typedef or using are more

    trouble
    > than this minor convenience.
    >
    > In your case, you could write this in a header:
    >
    > namespace zone {
    > // using john::string;
    > using myns::string;
    > }
    >
    > Now use zone::string everywhere you would have used std::string.


    This is a good technique, thanks!

    >
    > (And please don't let us think you are redefining 'string' for your own
    > nefarious purposes! Leave the std:: classes alone!!)


    Think what you will, but I can assure you that redefining 'string' for a C++
    programmer is like taking the first step for a baby. It has to be done
    sooner or later. :)
    Fei Liu, Mar 30, 2006
    #3
  4. Fei Liu

    Phlip Guest

    > The guideline is to never put anything in a .h file that could cause
    > trouble in any .cpp file that includes it.


    What kind of trouble? Consider Noah Roberts's recent charming post "Gotta
    love it":

    > DComponent(const DComponent & copy) : DGenericNode(copy) {}
    >
    > c:\src\PIPE-FLO 32\DComponent.h(12) : error C2065: 'copy' : undeclared
    > identifier
    > c:\src\PIPE-FLO 32\DComponent.h(12) : fatal error C1903: unable to
    > recover from previous error(s); stopping compilation


    Of course we will never know exactly where that error came from. (And just
    saying "get a less crappy compiler" is less a useful engineering tip than a
    cheap shot at M$.)

    It resembles the kinds of bugs that VC++ has regarding namespaces,
    regardless whether Noah abused his directly. Even if your code is
    syntactically correct, avoiding namespace abuse will reduce the odds of
    these kinds of bugs, whether they are your fault's or the compiler's.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 30, 2006
    #4
  5. Fei Liu

    Phlip Guest

    Fei Liu wrote:

    > Think what you will, but I can assure you that redefining 'string' for a
    > C++
    > programmer is like taking the first step for a baby. It has to be done
    > sooner or later. :)


    Just so we remain on the same page here, "redefining 'string'" could mean
    any one of these:

    1. write your own string class as an exercise
    2. rebuild std::basic_string<> from scratch
    3. build an alternative app-specific XString class

    Two of those items are attrocities that shouldn't ever be done for any
    reason. Even if you need a string for an application-specific evil character
    set, such as an EBCDIC/UTF-7 hybrid or something, you can still provide a
    custom type for basic_string<>.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 30, 2006
    #5
  6. Fei Liu

    Fei Liu Guest

    "Phlip" <> wrote in message
    news:TPIWf.8111$%...
    > Fei Liu wrote:
    >
    > > Think what you will, but I can assure you that redefining 'string' for a
    > > C++
    > > programmer is like taking the first step for a baby. It has to be done
    > > sooner or later. :)

    >
    > Just so we remain on the same page here, "redefining 'string'" could mean
    > any one of these:
    >
    > 1. write your own string class as an exercise
    > 2. rebuild std::basic_string<> from scratch
    > 3. build an alternative app-specific XString class
    >
    > Two of those items are attrocities that shouldn't ever be done for any
    > reason. Even if you need a string for an application-specific evil

    character

    There are reasons why a different string implementation would be required.
    It all depends. std::string is a general string implementation that fits
    some (general) cases very well. But to meet specific requirement, be it
    performance, memory management etc, often than not a different domain
    specific string implementation is used.

    Thanks for your feedback.
    Fei Liu, Mar 31, 2006
    #6
  7. Fei Liu

    Axter Guest

    Fei Liu wrote:
    > In Accellerated C++, the author recommends that in a header file one should
    > not declare
    > using std::string, using std::vector etc instead one should directly specify
    > the namespace specifier in code.
    >
    > for example, this is bad practice:
    >
    > header.h
    > #include <string>
    > using std::string;
    > class a{
    > string x;
    > };
    >
    > instead, one should write:
    > #include <string>
    > class a{
    > std::string x;
    > };
    >
    > The reason given by the author is that 'using std::string' actually pollutes
    > the scope where 'using std::string' is declared.
    > I find this style is rather inconvenient when I want to experiment with
    > different implementation of certain classes in large projects. For example,
    > I may want to try myns::string or john::string, it's actually much easier to
    > replace 'using std::string' to 'using myns::string' and instantly switch to
    > another string implementation. This is much better than going through all
    > the instances of 'std::string variable' and replace them to 'myns::string
    > variable'.
    >
    > What are your thoughts on this coding style?


    If you want to experiment, it's much easier if you just create a
    typedef, and then change the typedef when you want to change it
    throughout your code.
    Axter, Mar 31, 2006
    #7
  8. Fei Liu

    Phlip Guest

    Fei Liu wrote:

    > There are reasons why a different string implementation would be required.
    > It all depends. std::string is a general string implementation that fits
    > some (general) cases very well. But to meet specific requirement, be it
    > performance, memory management etc, often than not a different domain
    > specific string implementation is used.


    I challenge all "build don't buy" decisions.

    But in the specific case of a string, I have worked in linguistics, CORBA,
    ActiveX, object databases, video games, embedded stuff, and chat servers,
    and I have _never_ seen a situation that needs an application-specific
    string class.

    I have, however, seen plenty of custom string classes. They added no value,
    and slowed down development. And their authors often held them for ransom.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 31, 2006
    #8
  9. Fei Liu

    Joe Van Dyk Guest

    Re: using std::string; string("hello") vs std::string("hello") inheader file.

    Phlip wrote:
    > Fei Liu wrote:
    >
    >
    >>There are reasons why a different string implementation would be required.
    >>It all depends. std::string is a general string implementation that fits
    >>some (general) cases very well. But to meet specific requirement, be it
    >>performance, memory management etc, often than not a different domain
    >>specific string implementation is used.

    >
    >
    > I challenge all "build don't buy" decisions.
    >
    > But in the specific case of a string, I have worked in linguistics, CORBA,
    > ActiveX, object databases, video games, embedded stuff, and chat servers,
    > and I have _never_ seen a situation that needs an application-specific
    > string class.
    >
    > I have, however, seen plenty of custom string classes. They added no value,
    > and slowed down development. And their authors often held them for ransom.


    What about a thread-safe string class?

    Joe
    Joe Van Dyk, Apr 1, 2006
    #9
  10. Fei Liu

    Guest

    Joe Van Dyk wrote:

    > > I have, however, seen plenty of custom string classes. They added no value,
    > > and slowed down development. And their authors often held them for ransom.

    >
    > What about a thread-safe string class?


    If your std::string class does COW then I would hope it does atomic,
    lock-free reference-counting which will correctly hide the fact
    internal data sharing is occuring; if it does not, then it already is
    thread safe. Of course, that doesn't mean you can't do non-thread-safe
    things with a string class -- for example, as with any object that is
    shared between threads, a global std::string object that might get
    written from multiple threads should have a mutex (or similar) to make
    it safe. But you wouldn't want to add that overhead to all std::string
    objects, would you?

    --
    Richard Smith
    , Apr 1, 2006
    #10
    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. Newsgroup - Ann
    Replies:
    4
    Views:
    688
    lilburne
    Nov 2, 2003
  2. Carl
    Replies:
    4
    Views:
    403
    Peter Hansen
    May 21, 2004
  3. Jeffrey Walton
    Replies:
    10
    Views:
    928
    Mathias Gaunard
    Nov 26, 2006
  4. Roy
    Replies:
    6
    Views:
    577
    Roedy Green
    Jan 7, 2008
  5. mlt
    Replies:
    2
    Views:
    813
    Jean-Marc Bourguet
    Jan 31, 2009
Loading...

Share This Page