Christopher M. Gurnee <gurnec@nospam.yahoo.com> wrote:
: Oleg Zabluda wrote in message <6mpgju$5kp@marianna.psu.edu>...
: >
: >#include <iostream.h>
: >void f(char* i) {}
: >int main() { f("aaa"); }
: >
: >(BTW, the program above is compliant)
: >
: >Oleg.

: Maybe...
: #include <iostream>
: instead.  (I'm sorry, I couldn't help it, it just sort of slipped out
: ;-) )

Actually, even smarter would be to delete it altogether, since
it's not needed. :-)

Anyway, it would not compile with g++. Soon too be fixed. It's
customary for compiler vendors to switch from iostream.h to
iostream when namespaces are introduced and traditional iostreams
are replaced with the standard ones. This will happen Real Soon Now.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jeroen Dobbelaere <dobbelaj@access.bel.alcatel.be> wrote:
: Joe Buck wrote:
: [...]

: > gcc/g++/egcs has had the flag -Wwrite_strings for years, which has the effect
: > of making string constants const (the reason for calling it this is that
: > it predated the change in the standard and was intended to warn about
: > possible attempts to modify literal strings).  It is not the default,
: > because it tends to break large numbers of existing programs.  (Arguably
: > it should at least get turned on if -ansi or -pedantic is provided).

: This option (-Wwrite-strings) doesn't has any effect on the example : calling
: f("string") still prefers
: f(char*) above f(const char *) (even without giving any warning (!))

: So, I'm right in thinking that f(const char*) should be prefered in this case
: (following the draft/standard of c++) ?

You are right. It's a bug in g++. Try compiling this with and without
-Wwrite-strings and see the effect (warning).

#include <iostream.h>
void f(char* i) {}
int main() { f("aaa"); }

(BTW, the program above is compliant)

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Oleg Zabluda wrote in message <6mpgju$5kp@marianna.psu.edu>...
>
>#include <iostream.h>
>void f(char* i) {}
>int main() { f("aaa"); }
>
>(BTW, the program above is compliant)
>
>Oleg.

Maybe...
#include <iostream>
instead.  (I'm sorry, I couldn't help it, it just sort of slipped out
;-) )

-Chris Gurnee
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>> we found following problem with egcs (egcs-2.90.23 980102 (egcs-1.0.1
>> release)), but we are not sure if it is a bug or not :

[ example deleted ]

>String literals used to be char*, for C compatibility. The change to
>const char* was fairly recent, so not all compilers have caught up.
>Since your compiler is this year's vintage, I'm a bit surprised. Could
>there be a compiler switch for this?

gcc/g++/egcs has had the flag -Wwrite_strings for years, which has the effect
of making string constants const (the reason for calling it this is that
it predated the change in the standard and was intended to warn about
possible attempts to modify literal strings).  It is not the default,
because it tends to break large numbers of existing programs.  (Arguably
it should at least get turned on if -ansi or -pedantic is provided).
--
-- Joe Buck
   work: jbuck@synopsys.com, otherwise jbuck@welsh-buck.org or jbuck@best.com
http://www.welsh-buck.org/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Joe Buck wrote:
> gcc/g++/egcs has had the flag -Wwrite_strings for years, which has the effect
> of making string constants const (the reason for calling it this is that
> it predated the change in the standard and was intended to warn about
> possible attempts to modify literal strings).  It is not the default,
> because it tends to break large numbers of existing programs.  (Arguably
> it should at least get turned on if -ansi or -pedantic is provided).

I raised this as a problem to Cygnus. When -Wwrite_strings is specified
you will find that the compiler may select a different overloaded function.
It doesn't seem quite correct that enabling a warning message changes
the generated code. Cygnus agreed and I believe this functionality
will become a compiler operational flag rather than a warning flag.

--
Gary Mussar <mussar@nortel.ca>   Phone: (613) 763-4937
Nortel                           FAX:   (613) 763-9406


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Joe Buck wrote:
[...]

> gcc/g++/egcs has had the flag -Wwrite_strings for years, which has the effect
> of making string constants const (the reason for calling it this is that
> it predated the change in the standard and was intended to warn about
> possible attempts to modify literal strings).  It is not the default,
> because it tends to break large numbers of existing programs.  (Arguably
> it should at least get turned on if -ansi or -pedantic is provided).

This option (-Wwrite-strings) doesn't has any effect on the example : calling
f("string") still prefers
f(char*) above f(const char *) (even without giving any warning (!))

So, I'm right in thinking that f(const char*) should be prefered in this case
(following the draft/standard of c++) ?

Greetings,

Jeroen Dobbelaere


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello,

we found following problem with egcs (egcs-2.90.23 980102 (egcs-1.0.1
release)), but we are not sure if it is a bug or not :

following program outputs

this is f(char*) test not const
this is f(const char*) test const 1
this is f(char*) test should be const

instead of

this is f(char*) test not const
this is f(const char*) test const 1
this is f(const char*) test should be const

what we would expect after checking the c++ draft :

from the  1997 C++ Public Review Document :

2.13.4  String literals                                   [lex.string]
[..]
1 A  string  literal  is  a  sequence  of  characters  (as  defined   in
  _lex.ccon_) surrounded by double quotes, optionally beginning with the
  letter L, as in "..." or L"...".  A string literal that does not begin
  with  L  is  an  ordinary string literal, also referred to as a narrow
  string literal.  An ordinary string literal has type "array of n __const__
  char"  and  static storage duration
[..]

Is this a bug in the overloading mechanism of this compiler or is the
compiler permitted to do so ?

Greetings,

Jeroen Dobbelaere


/* begin */
#include <iostream.h>

void
f(char* i)
{
  cout << "this is f(char*) " << i << endl;
}

void
f(const char* i)
{
  cout << "this is f(const char*) " << i << endl;
}



int
main(int argc, char *argv[])
{
  char a1[] = "test not const";
  const char a2[] = "test const 1";

  f(a1);
  f(a2);
  f("test should be const");
}
/* end */




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jeroen Dobbelaere wrote:
>
> we found following problem with egcs (egcs-2.90.23 980102 (egcs-1.0.1
> release)), but we are not sure if it is a bug or not :
>
> following program outputs
>
> this is f(char*) test not const
> this is f(const char*) test const 1
> this is f(char*) test should be const
>
> instead of
>
> this is f(char*) test not const
> this is f(const char*) test const 1
> this is f(const char*) test should be const
>
> what we would expect after checking the c++ draft :

[obvious code snipped]

String literals used to be char*, for C compatibility. The change to
const char* was fairly recent, so not all compilers have caught up.
Since your compiler is this year's vintage, I'm a bit surprised. Could
there be a compiler switch for this?

--

Ciao,
Paul
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]