dhruvbird@gmx.net ("Dhruv") writes:

|>  What I'm proposing now will not necessarily break existing code, but
|>  will only break code where users define their own variables names
|>  cout, cin, cerr, etc... Which I haven't seen upto now.

The variable name cout was rather frequent in commercial software
written in C in French.  I've avoided in in C++, because most compilers
that I've used haven't supported namespaces, but I wouldn't be surprised
if newer C++ programmers, who only use more recent compilers, use it
regularly.

|>  I'm sick of having to compile the iostreams library to test out any
|>  changes made to it (AAMOF, I can't compile them!!!),

As far as the standard is concerned, any changes you make in a standard
library result in undefined behavior.  So I cannot see any point in
modifying the standard to make such things easier.

As far as actual implementations go, I rather suspect that they
invalidate your guarantee, and may be illegal, depending on the license.

Note that even in the case of g++, IF I understand the LGPL correctly,
any changes in the library remove it from LGPL, and place it under GPL,
which in turn means that any software you link with it also comes under
GPL.  (But I'm not a lawyer.)

|>   so I'm proposing that cout, cin, etc... be made objects that can be
|>  accessed though functions like what James Kanze has said on
|>  c.l.c++.m. So, the stuff would now look like:

|>  <iostream>

|>  namespace std {
|>     ostream& Get_Cout() {=20
|>     static <cout object Type> COUTO;
|>     return COUTO;
|>  }

|>     istream& Get_Cin() {=20
|>     static <cin object Type> CINO;
|>     return CINO;
|>  }

|>  }

|>  #define cout std::Get_Cout()
|>  #define cin std::Get_Cin()
|>  //and so on...

|>  This would obviously mean that std:: qualification would disappear,
|>  and ugly defines would take it's place, but would it help
|>  performace, debigging of streams, etc...?

It actually has a number of drawbacks.  The first is the obvious one,
which you mention, and which is sufficient IMHO to make the idea totally
unacceptable from the start.  (At least in France, cout is to be
expected as a variable name.)  Beyond that, there is still the problem
of using the objects in destructors of static objects.  The current
situation is that the standard streams are NEVER destructed.  In your
proposal, they would be, and trying to use them after destruction would
be undefined behavior.

You could presumably obtain a similar effect by making the standard
streams objects of some special type, which didn't have a dynamic
constructor, and which converted to istream& or ostream& in the
necessary cases.  As far as I'm concerned, however, the current
situation is acceptable; if I were to change anything, it would be
simply to require the standard stream objects to be constructed before
any user defined static objects, but I don't vue such a change as
essential.

--=20
James Kanze                             mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                 Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  +33 1 41 89 80 93

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
> It actually has a number of drawbacks.  The first is the obvious one,
> which you mention, and which is sufficient IMHO to make the idea totally
> unacceptable from the start.  (At least in France, cout is to be
> expected as a variable name.)

And clog is the name of a function in C99.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

What I'm proposing now will not necessarily break existing code, but will
only break code where users define their own variables names cout, cin,
cerr, etc... Which I haven't seen upto now.

I'm sick of having to compile the iostreams library to test out any
changes made to it (AAMOF, I can't compile them!!!), so I'm proposing that
cout, cin, etc... be made objects that can be accessed though functions
like what James Kanze has said on c.l.c++.m. So, the stuff would now look
like:

<iostream>

namespace std {
   ostream& Get_Cout() {
   static <cout object Type> COUTO;
   return COUTO;
}

   istream& Get_Cin() {
   static <cin object Type> CINO;
   return CINO;
}

}


#define cout std::Get_Cout()
#define cin std::Get_Cin()
//and so on...


This would obviously mean that std:: qualification would disappear, and
ugly defines would take it's place, but would it help performace,
debigging of streams, etc...?

Regards,
-Dhruv.






---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]