Which way should this be done? <Theory Question>

Discussion in 'C++' started by da Vinci, Aug 28, 2003.

  1. da Vinci

    da Vinci Guest

    Hello.

    First off, I am not sure of the exact jargon used, so I will ask a
    question regarding it. Then on to my other question.

    When you use things like cout and cin from the iostream header file,
    what are those called? Is cout and cin functions? What is the proper
    term for them a command listed in a header file? Or is it just a
    "command"?

    My next question.....

    We use a Deitel book in my C++ class. All of their sample code in the
    book shows that they use the following format for including header
    files and using the "term from above" contained in them.

    #include <iostream>
    using std::cout;
    using std::cin;

    I have also seen it in other places as

    #include <iostream>
    using namespace std;

    What I have always done, and what my teacher says is a carry over from
    C, is this....

    #include <iostream.h>

    so that none of the using commands are needed. When your using quite a
    few header files, those using statements get a bit cumbersome.

    So, what is the "proper" way to do it? I am sure everyone has their
    own way of doing it and likes to stick to their way. What are the
    rewards or benifits from doing it each way? Are there any or is it
    strictly personal taste?

    Thanks in advance for any ideas.

    DV
     
    da Vinci, Aug 28, 2003
    #1
    1. Advertising

  2. da Vinci

    Greg P. Guest

    "da Vinci" <> wrote in message
    news:p...
    | When you use things like cout and cin from the iostream header file,
    | what are those called? Is cout and cin functions? What is the proper
    | term for them a command listed in a header file? Or is it just a
    | "command"?

    cin and cout are predifined objects from the iostream classes. There is also
    clog and cerr (which are pretty much the same mostly) that write to the
    error stream (usually just the screen on some systems, unless overridden as
    you can do in Linux).

    What do you mean by "command"? Are you referring to macros, function/class
    declarations, pragmas,...? I can only assume that you are referring to
    "using": it's a statement.

    | We use a Deitel book in my C++ class. All of their sample code in the
    | book shows that they use the following format for including header
    | files and using the "term from above" contained in them.
    |
    | #include <iostream>
    | using std::cout;
    | using std::cin;

    std refers to the C++ standard namespace. Everything is in this namespace. A
    namespace is basically a way for names to coincide with other similar names
    (that you may write for example). If you were to write a class vector<> for
    example, you could distinguish between instantiating yours and the
    standards:

    vector<int> myVec; // Your vector type
    std::vector<int> stdVec; // standard vector

    | I have also seen it in other places as
    |
    | #include <iostream>
    | using namespace std;

    This brings every name, function, class, type (etc) into the global
    namespace. This means that you may conflict with something from the standard
    (like indentical function names w/ signatures). Your professor should cover
    namespaces in your course eventually.

    | What I have always done, and what my teacher says is a carry over from
    | C, is this....
    |
    | #include <iostream.h>

    You need a better teacher. iostream.h is not from C, but rather from C++
    before there was a standard for it. It is archaic and only kept for
    backwards compatibility (for that lazy asses that won't update their
    software to reflect ANSI/ISO IEC 14882-1998). All standard headers carry no
    extension (no .h). For the standard C headers, the same is true but a 'c' is
    prepended to their name (stdio.h becomes cstdio).

    | so that none of the using commands are needed. When your using quite a
    | few header files, those using statements get a bit cumbersome.

    There is nothing wrong with just writing "using namespace std". Never use
    iostream.h.

    | So, what is the "proper" way to do it? I am sure everyone has their
    | own way of doing it and likes to stick to their way. What are the
    | rewards or benifits from doing it each way? Are there any or is it
    | strictly personal taste?

    The proper way to do it is to qualify (as your teacher about this) anything
    in the std namespace. There is no personal taste involved, just the extra
    typing. I could do:

    std::vector<int> vecInt;

    using std::vector;
    vector<int> vecInt;

    using namespace std;
    vector<int> vecInt;

    All are the same. The only difference is the using namespace std brings
    everything into scope;
     
    Greg P., Aug 29, 2003
    #2
    1. Advertising

  3. da Vinci

    Bob Jacobs Guest

    "Greg P." <> wrote in message
    news:9%D3b.8311$...
    > "da Vinci" <> wrote in message
    >
    > | So, what is the "proper" way to do it? I am sure everyone has their
    > | own way of doing it and likes to stick to their way. What are the
    > | rewards or benifits from doing it each way? Are there any or is it
    > | strictly personal taste?
    >
    > The proper way to do it is to qualify (as your teacher about this)
    > anything in the std namespace. There is no personal taste involved,
    > just the extra typing. I could do:
    >
    > std::vector<int> vecInt;
    >
    > using std::vector;
    > vector<int> vecInt;
    >
    > using namespace std;
    > vector<int> vecInt;
    >
    > All are the same. The only difference is the using namespace std brings
    > everything into scope;


    They're not all the same. As Stroustrup points out in The C++ Programming
    Language, C.10, a using declaration adds a name to a local scope whereas a
    using directive doesn't. Much of the time it may not matter but it can do.
     
    Bob Jacobs, Aug 29, 2003
    #3
  4. da Vinci

    da Vinci Guest

    Thanks for the knowledge so far!

    But now I have something else troubling me about this. Everyone has
    pretty much pointed out that using the .h form in the include
    statement is not standard c++ and should not be used.

    What advantage do you get over using the "namespace std;" line? What
    advantage would you get using the "using std::cout;". I mean the
    advantage over using just the .h under the include statement....

    It seems to me that adding all of these lines of code for namespace
    inclusions and such is a waste of time when you can just use the .h in
    the include line.

    I know that ANSI would not change something like this, make it harder
    or more bulky in the code, for no reason. So, what was their reason?
    Does this make programs compatible across many different platforms or
    compilers? Does it save on the memory useage of the program?

    Again, I am just a beginner. I like to know the whole story instead of
    just "Do it this way because ANSI says so!" answer. I like having the
    indepth, behind the sense, kind of knowledge.

    I appreciate all the help so far.

    DV
     
    da Vinci, Sep 1, 2003
    #4
  5. "da Vinci" <> wrote in message
    news:...
    > Thanks for the knowledge so far!
    >
    > But now I have something else troubling me about this. Everyone has
    > pretty much pointed out that using the .h form in the include
    > statement is not standard c++ and should not be used.
    >
    > What advantage do you get over using the "namespace std;" line? What
    > advantage would you get using the "using std::cout;". I mean the
    > advantage over using just the .h under the include statement....
    >
    > It seems to me that adding all of these lines of code for namespace
    > inclusions and such is a waste of time when you can just use the .h in
    > the include line.
    >
    > I know that ANSI would not change something like this, make it harder
    > or more bulky in the code, for no reason. So, what was their reason?
    > Does this make programs compatible across many different platforms or
    > compilers? Does it save on the memory useage of the program?
    >
    > Again, I am just a beginner. I like to know the whole story instead of
    > just "Do it this way because ANSI says so!" answer. I like having the
    > indepth, behind the sense, kind of knowledge.
    >
    > I appreciate all the help so far.
    >
    > DV


    The purpose of namespaces is to avoid name collisions in code when program
    are written by many authors (I think I said that already).

    Suppose the std namespace did not exist, and suppose your favourite variable
    name was foo, you used it thousands of times in your program. The a new
    version of the standard comes out and the standards committee have added foo
    to the standard library! As a template type, the bastards! Now your program
    won't compile, and you have a headache.

    Because of namespaces this cannot happen. The names you choose and the names
    the standards committee choose are safely separated by namespaces. That is
    of course unless you write

    using namespace std;

    at the top of all your code. Now it can happen again, but its YOUR fault.

    john
     
    John Harrison, Sep 1, 2003
    #5
  6. Well, first of all, the ".h"-style headers are now obsolete,
    and that's a good reason for not using them. They're like
    the words "thou" and "thy" -- you could use them and be
    understood, but you'll do better not using them. :)

    When you use the "new" headers (those without the ".h"),
    you get their variables wrapped in a namespace -- believe it
    or not, that's for your convenience, as John had pointed out
    a post earlier. The purpose of the namespace is to let you
    use *your* own variables without having to make sure there's
    no such variable already in some of the headers you've included.

    But to get to the variables in a namespace you have to
    do either of these:

    a) type the namespace qualifier everywhere, like in:
    std::cout << "Testing 123" << std::endl

    b) explicitly bring some variables into scope, like in:
    using std::string;
    which will then allow you to skip the corresponding
    namespace identifiers

    c) explicitly bring the whole namespace into scope, like in
    using namespace std;
    which is a good solution for you

    d) be stubborn and stick to ".h" headers which could be
    so old they've never seen a thing like a namespace,
    which is not a good idea, just like using "thou" isn't.

    Anyway, having to type "using namespace std;" once
    per source file isn't a great disadvantage, is it?

    HTH,
    - J.
     
    Jacek Dziedzic, Sep 1, 2003
    #6
  7. da Vinci

    Greg Schmidt Guest

    On Mon, 01 Sep 2003 17:22:58 GMT, da Vinci <> wrote:

    >Thanks for the knowledge so far!
    >
    >But now I have something else troubling me about this. Everyone has
    >pretty much pointed out that using the .h form in the include
    >statement is not standard c++ and should not be used.
    >
    >What advantage do you get over using the "namespace std;" line? What
    >advantage would you get using the "using std::cout;". I mean the
    >advantage over using just the .h under the include statement....


    The advantage of "using namespace std;" is that you don't have to do any
    more typing. The disadvantage is that everything in the namespace gets
    pulled into the global namespace. Doing this in a source file is not a
    big problem, but doing it in a header can be disastrous.

    The advantage of "using std::cout;" is that you can then just type
    "cout" instead of "std::cout" whenever you want to use it. The
    disadvantage is that there are generally more such lines required, one
    for each thing you want to import into your local namespace.

    >It seems to me that adding all of these lines of code for namespace
    >inclusions and such is a waste of time when you can just use the .h in
    >the include line.


    The technique of using the .h header may or may not work. The .h
    headers date from before the ANSI standard, and at that time each
    vendor's implementation was different. Now, some vendors iostream.h
    file might look like this:

    #include <iostream>
    using namespace std;

    while others may still be the same as they were in the bad old days.
    The only way to be sure of what you are getting is to abandon the .h
    versions and use the new, standard, "no .h" include files.

    So, yes, you waste about 5 seconds each time you type "using namespace
    std;" in a source file, but you will likely get all that back and then
    some the first time you try to compile your source with a different
    compiler, or the first time you run into a situation where your
    compiler's .h differs from the ANSI header which is documented in all
    the good books on the subject.

    >I know that ANSI would not change something like this, make it harder
    >or more bulky in the code, for no reason. So, what was their reason?


    ANSI didn't really change this, it's just that what they chose to
    standardise didn't quite match what anyone had implemented. To avoid
    the large problem of breaking existing code, they standardised on a new
    file structure and a new namespace that nobody was using, and let
    compiler vendors decide for themselves what path they would take with
    their existing and now-obsolete .h headers.

    >Does this make programs compatible across many different platforms or
    >compilers? Does it save on the memory useage of the program?


    ANSI standardisation has made programs compatible across many different
    platforms, and this particular choice made sure that people know exactly
    what they are getting when they include a standard header, rather than
    using a header which is now standard but used to vary and you're never
    sure which version you have.

    >Again, I am just a beginner. I like to know the whole story instead of
    >just "Do it this way because ANSI says so!" answer. I like having the
    >indepth, behind the sense, kind of knowledge.


    Hope this helps! Of course, this is all a big simplification of the
    ANSI process, and there were other good reasons for using the std
    namespace, but that's outside the scope of your original question.

    --
    Greg Schmidt ()
    Trawna Publications (http://www.trawna.com/)
     
    Greg Schmidt, Sep 2, 2003
    #7
  8. da Vinci

    da Vinci Guest

    On Mon, 1 Sep 2003 20:16:29 +0100, "John Harrison"
    <> wrote:


    >The purpose of namespaces is to avoid name collisions in code when program
    >are written by many authors (I think I said that already).


    Ah, ok, now I think I am starting to understand what you meant. I had
    seen that you wrote that and meant to write a comment on it in my last
    response but forgot. I just didnt understand what name collisions
    meant.

    My programming experiance was BASIC as a kid, PASCAL in high school,
    and I self taught myself C++ when I was in the Marines (nothing else
    to do when on deployment!). But because I self taught myself, I didn't
    get alot of the intricate details on the laungage. Now that I am in
    college, I am trying to pick all of that stuff up.

    Thanks for explaining that out.

    DV
     
    da Vinci, Sep 2, 2003
    #8
  9. da Vinci

    da Vinci Guest

    On Mon, 1 Sep 2003 22:26:47 +0200, "Jacek Dziedzic"
    <> wrote:


    >d) be stubborn and stick to ".h" headers which could be
    >so old they've never seen a thing like a namespace,
    >which is not a good idea, just like using "thou" isn't.


    <LAUGH>

    >Anyway, having to type "using namespace std;" once
    >per source file isn't a great disadvantage, is it?


    No, not at all. From previous posts and this one, I am really
    beginning to understand the reasons not to use the .h that the teacher
    just couldn't explain. She doesn't care how we do it, as long as it
    compiles and works. I want to do it the right way because bad habits
    are hard to break when your looking for a computer engineering job.
    Learn it right the first time is what I say.

    I went through and changed all of my code that I have writen so far to
    reflect the "using namespace std;" addition. It just threw me through
    a loop trying to figure out that <math.h> is now <cmath> and not just
    <math>.

    DV
     
    da Vinci, Sep 2, 2003
    #9
  10. da Vinci

    da Vinci Guest

    On Mon, 01 Sep 2003 23:56:40 GMT, Greg Schmidt <>
    wrote:

    >Hope this helps! Of course, this is all a big simplification of the
    >ANSI process, and there were other good reasons for using the std
    >namespace, but that's outside the scope of your original question.


    Yes, it has been very valuable.

    From the beginning it was a matter of me seeing three diferent ways to
    do it, from three diferent sources, and none of them state that one
    way is better than another. Then everyone I asked (outside of this
    newsgroup) couldn't explain which was the better or "more correct" way
    of doing it.

    Again, appreciate the clarification on the matter. (same to all of
    those who have responded.)
     
    da Vinci, Sep 2, 2003
    #10
  11. In article <>,
    da Vinci <> wrote:

    >I went through and changed all of my code that I have writen so far to
    >reflect the "using namespace std;" addition. It just threw me through
    >a loop trying to figure out that <math.h> is now <cmath> and not just
    ><math>.


    This is because <math.h> got imported from the C library, so (like any
    other C library header) it can be used either as <foo.h> (which puts the
    names in the global namespace) or as <cfoo> (which puts them in namespace
    std). (Unlike the pre-standard forms of C++ headers, it's perfectly valid
    (though not such a good thing in new code) to leave <math.h> (or any other
    C header) as is and use the names from the global namespace instead.)

    Knowing about things like this is also a Good Thing if you want to be
    able to write C as well as C++, since knowing what's the same between
    them lets you spend more time learning the differences.


    dave

    --
    Dave Vandervies
    [Y]ou can write bad code that just barely works in both languages, or good
    code that works only in one language -- so pick one, and write good code in
    that language. --Chris Torek in comp.lang.c (crossposted to comp.lang.c++)
     
    Dave Vandervies, Sep 2, 2003
    #11
    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. Replies:
    7
    Views:
    4,187
  2. Rayle
    Replies:
    2
    Views:
    300
    Mark Space
    Feb 9, 2007
  3. Jeff
    Replies:
    0
    Views:
    327
  4. Paul
    Replies:
    0
    Views:
    120
  5. Zhidian Du
    Replies:
    0
    Views:
    158
    Zhidian Du
    Feb 21, 2004
Loading...

Share This Page