In article <D81DEE2FE04AD111957A00805FA6231129D9E0@SJCMAIL>,
Clem@matridigmusa.com says...

[ ... ]

>  #include <iostream>
>  // ...
>  long const i = 0;
>  cin >> i;
>
> Perfectly legal.  Compiles, runs, etc.

Hmm...in CD2, I see overloads like:

basic_istream &basic_istream::operator>>(long &);

but no corresponding one taking an argument of type `const long &'  As
such, I'm reasonably certain this code should not compile.  When I try
it with VC++ 5.0 (with <iostream> changed to <iostream.h> ) I get an
error message saying that `cin >> i;' is ambiguous, though it doesn't
tell me what the possible overloads are.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Jerry Coffin wrote:
>
> In article <D81DEE2FE04AD111957A00805FA6231129D9E0@SJCMAIL>,
> Clem@matridigmusa.com says...
>
> [ ... ]
>
> >       #include <iostream>
> >       // ...
> >       long const i = 0;
> >       cin >> i;
> >
> > Perfectly legal.  Compiles, runs, etc.
>
> Hmm...in CD2, I see overloads like:
>
> basic_istream &basic_istream::operator>>(long &);
>
> but no corresponding one taking an argument of type `const long &'  As
> such, I'm reasonably certain this code should not compile.  When I try
> it with VC++ 5.0 (with <iostream> changed to <iostream.h> ) I get an
> error message saying that `cin >> i;' is ambiguous, though it doesn't
> tell me what the possible overloads are.

There is no viable input operator but...

IMO, and as opposed as I previously wrote, this is a valid C++
statement that the compiler should accept:

  bool (cin) >> i;

ie a no-op.

Sorry for my mistake; I still have a old-iostream way of
thinking.

I think libraries should have a non conforming mode where
all resonnable programs work (for my definition of resonnable),
and with some intelligent changes:

change ios::operator bool () const to ios::operator void* () const
(the syntax bool (cout) would still work)

add a private ctor to string: string (char, size_t)

however these changes make the library non-conforming
(but still fully usable)

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

A while ago, a co-worker asked about adding "const"s to his code.
Specifically, could he just add them everywhere, and rely on the
compiler
to tell him where they were reasonable, aka "const 'em all and let the
compiler sort it out".  That seemed a reasonable first cut.

Could code be written which would take const or non-const; and
"do the wrong thing" in the const case?  Sure, it would be possible, but
I though it would take some work.

One day later, I found a nice example courtesy of the standard library.

 #include <iostream>
 // ...
 long const i = 0;
 cin >> i;

Perfectly legal.  Compiles, runs, etc.

Clem

---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Clem Dickey wrote:

> One day later, I found a nice example courtesy of the standard library.
>
>         #include <iostream>
>         // ...
>         long const i = 0;
>         cin >> i;

Perfecly illegal. Compilers complain, refuse to generate the
program, etc... (unless they are completly broken)

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Clem Dickey wrote:
>
> A while ago, a co-worker asked about adding "const"s to his code.
> Specifically, could he just add them everywhere, and rely on the
> compiler
> to tell him where they were reasonable, aka "const 'em all and let the
> compiler sort it out".  That seemed a reasonable first cut.

It doesn't seem reasonable to me. Any time you substitute brute force
for understanding you are engaged in the worst form of hacking.

> Could code be written which would take const or non-const; and
> "do the wrong thing" in the const case?  Sure, it would be possible, but
> I though it would take some work.
>
> One day later, I found a nice example courtesy of the standard library.
>
>         #include <iostream>
>         // ...
>         long const i = 0;
>         cin >> i;
>
> Perfectly legal.  Compiles, runs, etc.

Perfectly illegal. Shouldn't compile. Illustrates why you should
understand what you are doing instead of making massive changes in the
hope that the compiler will sort out your mistakes for you.
 -- Pete
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]