🚀 go-pugleaf

In article mf8@rational.rational.com, "J\ir\tme Desquilbet" <jDesquilbet@Rational.COM> writes:
>
>Reading the STL part of the CD, I understand that the sample "Hello world"
>program becomes:
>
>#include <iostream>
>int main()
>{
>  using namespace std;
>  cout << "Hello, world!" << endl;
>}

That is one way to write it. There are other ways as well. You could put
the "using namespace" at file scope, or just have using-declarations
for the items you need from <iostream>.

>If yes, what about "old" programs written using <iostream.h>? What does the
>above program become if I want to write it without using namespace std?

The ".h" versions of the standard C++ headers are not mentioned in the standard.
Implementors may supply as many other headers as they like, with any sort of
contents. I would expect a vendor to supply a header corresponding to the 
use of <iostream.h> which looked something like this:
	#include <iostream>
	using std::ios;
	using std::istream;
	using std::ostream;
	using std::cout;
	using std::cin;
	... etc

Such a header would allow typical existing programs to continue to compile.
---
Steve Clamage, stephen.clamage@eng.sun.com



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

"J\ir\tme Desquilbet" <jDesquilbet@Rational.COM> wrote:
>
>Reading the STL part of the CD, I understand that the sample "Hello world"
>program becomes:

By a using directive:

>#include <iostream>
>int main()
>{
>  using namespace std;
>  cout << "Hello, world!" << endl;
>}
>
>Am I right?

     Thats one way. Here's another with explicit qualification:

#include <iostream>
int main()
{
  std::cout << "Hello, world!" << std::endl;
}

     Here's another with the compatibility header:

#include <iostream.h>
int main()
{
  cout << "Hello, world!" << endl;
}

     Here's another with using declarations:

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

int main()
{
  cout << "Hello, world!" << std::endl;
}


>If yes, what about "old" programs written using <iostream.h>? 

    Should continue to work. iostream.h looks basically like:

// file: iostream.h
#include <iostream>
using std::cout;
using std::endl;
using std:istream;
...... (all names are 'used')


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "SC" == Steve Clamage <clamage@Eng.Sun.COM> writes:

 SC> The ".h" versions of the standard C++ headers are not mentioned in the
 SC> standard.
 (...)
 SC> Such a header would allow typical existing programs to continue to
 SC> compile.

But, of course, every one of those existing programs is non-standard.

Michael.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

John Max Skaller <maxtal@suphys.physics.su.oz.au> wrote:
>
>  #include <iostream>
>  using std::cout;
>  using std::endl;
>
>  int main()
>  {
>    cout << "Hello, world!" << std::endl;
>  }
>

Thanks for your answer.
I suppose you mean:

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

  int main()
  {
    cout << "Hello, world!" << endl;
  }

And what about <<?
Is not something like:

  using std::operator<<;

necessary?

  Jerome.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> Jirtme Desquilbet <jDesquilbet@Rational.COM> writes:

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

>   int main()
>   {
>     cout << "Hello, world!" << endl;
>   }

> And what about <<?
> Is not something like:

>   using std::operator<<;

> necessary?

Nope; << is looked up in the context of ostream, which is namespace std, so
the definition there is found.  This is known as 'Koenig lookup'.

  13.3.1.2  Operators in expressions                   [over.match.oper]

1 If  no  operand  of  an operator in an expression has a type that is a
  class or an enumeration, the operator is  assumed  to  be  a  built-in
  operator  and  interpreted according to clause _expr_.  [Note: because
  ., .*, ::, and ?: cannot be overloaded,  these  operators  are  always
  built-in  operators  interpreted according to clause _expr_.  ] [Exam-
  ple:
          class String {
          public:
             String (const String&);
             String (char*);
                  operator char* ();
          };
          String operator + (const String&, const String&);

          void f(void)
          {
             char* p= "one" + "two"; // ill-formed because neither
                                     // operand has user defined type
             int I = 1 + 1;          // Always evaluates to 2 even if
                                     // user defined types exist which
                                     // would perform the operation.
          }
   --end example]

2 If either operand has a type that is a  class  or  an  enumeration,  a
  user-defined  operator function might be declared that implements this
  operator or a user-defined conversion can be necessary to convert  the
  operand  to  a  type  that is appropriate for a built-in operator.  In
  this case, overload resolution is used  to  determine  which  operator
  function  or builtin operator is to be invoked to implement the opera-
  tor.  Therefore, the operator notation is  first  transformed  to  the
  equivalent  function-call  notation  as summarized in Table 1 (where @
  denotes one of the operators covered in the specified subclause).

    Table 1--relationship between operator and function call notation

  +--------------+------------+--------------------+------------------------+
  |Subclause     | Expression | As member function | As non-member function
  |
  +--------------+------------+--------------------+------------------------+
  |_over.unary_  | @a         | (a).operator@ ()   | operator@ (a)
  |
  |_over.binary_ | a@b        | (a).operator@ (b)  | operator@ (a, b)
  |
  |_over.ass_    | a=b        | (a).operator= (b)  |
  |
  |_over.sub_    | a[b]       | (a).operator[](b)  |
  |
  |_over.ref_    | a->        | (a).operator-> ()  |
  |
  |_over.inc_    | a@         | (a).operator@ (0)  | operator@ (a, 0)
  |
  +--------------+------------+--------------------+------------------------+

3 For     a     type     T     whose     fully-qualified     name     is
  ::N1::...::Nn::C1::...::Cm::T  where  each  Ni is a namespace name and
  each  Ci  is  a  class  name,  the  fully-qualified   namespace   name
  ::N1::...::Nn  is  called the "namespace of the type T."  To look up X
  in the "context of the namespace of the type T" means to  perform  the
  qualified  name  lookup of ::N1::...::Nn::X (_over.call.func_), except
  that only names actually declared in the namespace are visible.  Names
  made  visible  by using-directives (_namespace.udir_) in the namespace
  are not considered.

  +-------                 BEGIN BOX 1                -------+
  Change: This last sentence is an  editorial  proposal.   The  Monterey
  resolution  17  changed the name look up rules for qualified namespace
  members. This last sentence ensure that the rule above keeps its  pre-
  Monterey meaning. See email message core-6081.
  +-------                  END BOX 1                 -------+

4 For a type T whose fully-qualified name is ::C1::...::Cm::T where each
  Ci is a class name, to look up X in the "context of the  namespace  of
  the  type T" means to perform the qualified name lookup of ::X, except
  that only names actually declared in global scope are visible.   Names
  made  visible  by  using-directives (_namespace.udir_) in global scope
  are not considered.

  +-------                 BEGIN BOX 2                -------+
  Change: This previous paragraph is an editorial proposal.  This  para-
  graph  was  added to correctly handle classes defined in global scope.
  Otherwise, the new operator look up rules  will  not  allow  operators
  defined in global scope to be found if the type of one of the operands
  is a class from global scope. See email message core-6082.
  +-------                  END BOX 2                 -------+

5 For a unary operator @ with an operand of type T1 or reference  to  cv
  T1, and for a binary operator @ with a left operand of type T1 or ref-
  erence to cv T1 and a right operand of type T2 or reference to cv  T2,

  three  sets of candidate functions, designated member candidates, non-
  member candidates and built-in candidates, are constructed as follows:

  --If T1 is a class type, the set of member candidates is the result of
    the qualified lookup of T1::operator@ (_over.call.func_); otherwise,
    the set of member candidates is empty.

  --The set of non-member candidates is the union of the functions found
    in the following name lookups:

    --The unqualified operator@ is looked  up  in  the  context  of  the
      expression  according  to  the  usual rules for name lookup except
      that all member functions are ignored.

    --For each type Z, where Z is a class type representing either T1 or
      T2,  or  a  direct  or  indirect base class of one of these types,
      operator@ is looked up in the context of the namespace of  type  Z
      according to the usual rules for name lookup.

    --For each type Z, where Z is an enumeration type representing T1 or
      T2, operator@ is looked up in the context of the namespace of that
      type according to the usual rules for name lookup.

...

Jason
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

John Max Skaller <maxtal@suphys.physics.su.oz.au> wrote:
>
>  #include <iostream>
>  using std::cout;
>  using std::endl;
>
>  int main()
>  {
>    cout << "Hello, world!" << std::endl;
>  }
>

Thanks for your answer.
I suppose you mean:

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

  int main()
  {
    cout << "Hello, world!" << endl;
  }

And what about <<?
Is not something like:

  using std::operator<<;

necessary?

  Jerome.



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <VANDEVOD.95Oct13185849@avs.cs.rpi.edu>,
vandevod@cs.rpi.edu (David Vandevoorde) wrote:

|> Vaguely related: say I want to pull everything that has to do with 
|> valarrays (more precisely: all the classes and functions described 
|> (in 26.3)) in my program, but I'd rather not pull in all of ::std.
|> (And I don't want to issue dozens of `using's either.)

At one point the Library WG considered multiple nested namespaces for this
purpose. They backed off, I think because of problems with operator lookup
(amongst others). Now that the operator lookup is 'fixed' it would probably
be a good idea to revisit the partitioning of the library.

In answer to your question, you could synthesise your own namespaces
containing just those elements you wanted but it would be somewhat
laborious:

namespace std_valarray {
  using std::valarray;
  using std::...
  // etc etc etc
}

Then the std_valarray namespace would provide what you want.




[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]