On Mar 31, 3:05 pm, "Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEm...@erdani.org> wrote:
> Wow. It would be great if the language could distinguish (by e.g.
> assigning a different type) a literal from a const char*.

I was thinking about exactly this problem earlier today.  Such a
feature would most often be associated with string literals, but could
be useful for any kind of pointer-to-statically-allocated object.  I
was thinking of a syntax something like this (using basic_string) as
an example:

basic_string(static const charT* s) {
    // s is a string literal or a pointer to a const array of char, so
we don't need to
    // copy its contents.
}

basic_string(const charT* s) {
   // s is NOT a string literal.  We must copy its contents
}

The idea is that, within an argument declaration, the word "static" is
used to modify a pointer or reference so that it will only match (and
will be the preferred match) if the actual argument is a pointer or
reference to statically-allocated storage.  An important restriction,
though, is that a pointer to non-const static storage will NOT match
an argument of type pointer-to-static-const-object.  In other-words,
the normal cvq promotions will not occur for pointer arguments that
are declared static.  That restriction does make it a bit weird.

Any opinions/refinements?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 3, 12:41 (Greg Herlihy) wrote:
>
> What's the rationale for retaining a "const char *" constructor after a
> "const std::string&" constructor has been added to a Standard Library class?
> In other words, why not replace the current constructor instead of
> overloading it?
>
I can come up with two reasons why not to:
- First as you said it could break existing code. So far backwards-
compability with existing programs (even C) has been very important
during the evolution of c++ and breaking changes.
- The second and quite important reason is speed. By only allowing a
string argument means that each time a c-string is used to call the
function a memory allocation and string copy would have to be
performed. This could severely decrease performance in some
applications.

Daniel Svensson

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 2, 5:09 pm, Alberto Ganesh Barbati

> I think the technique in itself has a value and should be considered in
> the design of future library additions.

I agree with that and I think that the technique should be considered
for libraries like the tr1 libraries which will be added to the next
standard.

Specially functions working with the new unicode characters support
could benefit from the usage of a helper class like one of the
proposed since there are no functions using them today.

Example class for arbitrary character types:

  template<class Ch>
  basic_string_arg // string_input, string_argument or another
appropriate name
  {
      const Ch * _str:
      ....
      template<class Str>
      string_arg( const Str & s) : _str( get_c_str<Ch>(s)  )
      {}
  };

  typedef basic_string_arg<char> string_arg; //string_arg may not be
the best name but at least the intention is clear
  typedef basic_string_arg<wchar> wstring_arg;
  ... And so on for unicode characters like char16_t and char32_t

Daniel Svensson

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 3, 12:41 am, gre...@pacbell.net (Greg Herlihy) wrote:
> On 4/1/07 1:39 PM, in article
> 1175349363.714091.265...@p77g2000hsh.googlegroups.com, "James Kanze"
> <james.ka...@gmail.com> wrote:
> > On Mar 30, 11:39 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> >> On Fri, 30 Mar 2007 10:46:36 CST, James Kanze wrote:
> >>> On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> >>>> On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
> >>>>> Many functions like ifstream::open() should be operloaded in C++09  to
> >>>>> handle std::string as well plain char pointers.

> >>>> Do you find that to be a good idea?

> >>> The committee apparently does; it's already in the draft.

> >> What about you? Do you find it to be a good idea?

> > Given the current starting point, yes.  As I said, you can't do
> > away with the char const* functions.  And you certainly want to
> > support both std::string and string literals; anything less
> > would be perverse.  As I also said, when I implemented my own
> > versions of such things, way, way back in pre-standard days, I
> > actually used something like what the original poster suggested.
> > I don't think that this is an option today.  (I'm not sure that
> > it was the best option even then, but it was an option.  And it
> > worked pretty well for my style of programming, in the contexts
> > I used it.)

> What's the rationale for retaining a "const char *" constructor after a
> "const std::string&" constructor has been added to a Standard Library class?

Removing it would break existing code.

> In other words, why not replace the current constructor instead of
> overloading it?

> It seems to me that the only kind of program that would break if the const
> char * constructor were eliminated, would have to contain code so contrived
> and so contrary to widely-accepted "best practices" that the chances that
> any "real-world" C++ program would be adversely affected by eliminating the
> current constructor - are close to none.

You assumtions are almost surely wrong.  For whatever reasons,
existing code does use char const*.  There are doubtlessly cases
where it uses it as a result of a user defined conversion (e.g.
in some legacy code).  It's not for the standard to enforce
coding guidelines.  Many pre-standards String classes, for
example, supported implicit conversion to char const*, and many
are still in use because they are what some legacy library is
using.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 3, 7:25 pm, "Daniel" <Danne.Es...@gmail.com> wrote:
> On Apr 2, 5:09 pm, Alberto Ganesh Barbati

> > I think the technique in itself has a value and should be considered in
> > the design of future library additions.

> I agree with that and I think that the technique should be considered
> for libraries like the tr1 libraries which will be added to the next
> standard.

If anyone's interested, you might want to have a look at the
code under
http://kanze.james.neuf.fr/code/Old/Collections/String/index.html;
it's my pre-standard string class, and it used this techique.
(Note that I don't know how long this will be there.  To tell
the truth, it's only there now because I forgot to clean up the
directory on my home disk before copying it to the web site.
The Old in the path name means exactly that.)

Anyway, all I can say that it worked well for me.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Many functions like ifstream::open() should be operloaded in C++09  to
handle std::string as well plain char pointers. To not force mutliple
definitions (and implementations) of the same function, one may solve
this by implementing a class with the sole purpose of letting the user
use either string or char* without any special overhead.

string filename("myfile.txt");

Pre C++09:
 ifstream fin( filename.c_str() );
C++09:
 ifstream fin( filename );

I have successufullt used the following class in a library I've written
and instantly all functions were able to be called using either
std::string or char* without any extra allocations (from char* to
string) or the need to call string::c_str().

class string_arg
{
 const char* _str;
 public:
 string_arg(const char const* str) :_str(str)
 {}
 string_arg(const std::string & str) :
                                 _str(str.c_str() )
 {}

 //For code that previusly used char*
 operator const char*() const
  {return _str;}

 //for code that previusly used std::string
 const char* c_str() const
 {return _str;}
};


Of course one may want to make a template of the class to support other
character types (ex wchar_t) as well.


Daniel Svensson

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:

>Many functions like ifstream::open() should be operloaded in C++09  to
>handle std::string as well plain char pointers.

Do you find that to be a good idea?

>To not force mutliple
>definitions (and implementations) of the same function,

What do you mean by "multiple definitions"? (As to the
implementation(s), it's all the usual dance of forwarding to a common
"back-end" function --not a real problem IMHO)

--
 In search of passioned C++ developers?   I'm available.
 Breeze C++:    https://sourceforge.net/projects/breeze/
                      (incomplete, preview state)
 Gennaro Prota

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
> >Many functions like ifstream::open() should be operloaded in C++09  to
> >handle std::string as well plain char pointers.

> Do you find that to be a good idea?

The committee apparently does; it's already in the draft.

> >To not force mutliple
> >definitions (and implementations) of the same function,

> What do you mean by "multiple definitions"? (As to the
> implementation(s), it's all the usual dance of forwarding to a common
> "back-end" function --not a real problem IMHO)

In the case of filebuf::open(), probably, but in the case of
constructors, it's more complex.  I know that I used a technique
similar to what he proposes in conjunction with my pre-standard
string class.  For the standard, don't think it would work,
however, since it's only interesting if you replace the multiple
constructors with one single constructor, and eliminating the
constructors which take a char const* would break code.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Fri, 30 Mar 2007 10:46:36 CST, James Kanze wrote:

>On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
>> On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
>> >Many functions like ifstream::open() should be operloaded in C++09  to
>> >handle std::string as well plain char pointers.
>
>> Do you find that to be a good idea?
>
>The committee apparently does; it's already in the draft.

What about you? Do you find it to be a good idea?

--
Gennaro Prota.
In search of passioned C++ developers?   I'm available.
Breeze C++:    https://sourceforge.net/projects/breeze/
                     (incomplete, preview state)

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 28, 6:09 pm, Danne_es...@hotmail.com (Daniel Svensson) wrote:
> Many functions like ifstream::open() should be operloaded in C++09  to
> handle std::string as well plain char pointers. To not force mutliple
> definitions (and implementations) of the same function, one may solve
> this by implementing a class with the sole purpose of letting the user
> use either string or char* without any special overhead.

A better solution would be to only provide a constructor with a string
type and design the string type so that constructing one from a
literal doesn't copy.
That would mean the string type is immutable.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 31, 9:05 pm, "Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEm...@erdani.org> wrote:

> Wow. It would be great if the language could distinguish (by e.g.
> assigning a different type) a literal from a const char*.

A literal is not a const char* but a const char[N].
This is already slightly different. What's remaining is distinction
between named and unnamed arrays.
For that, we normally have rvalue references. However, for some
reason, string literals seems to bind without any problem to non const
references at the moment.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 31, 9:05 pm, "Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEm...@erdani.org> wrote:
> Mathias Gaunard wrote:
> > On Mar 28, 6:09 pm, Danne_es...@hotmail.com (Daniel Svensson) wrote:
> >> Many functions like ifstream::open() should be operloaded in C++09  to
> >> handle std::string as well plain char pointers. To not force mutliple
> >> definitions (and implementations) of the same function, one may solve
> >> this by implementing a class with the sole purpose of letting the user
> >> use either string or char* without any special overhead.

> > A better solution would be to only provide a constructor with a string
> > type and design the string type so that constructing one from a
> > literal doesn't copy.
> > That would mean the string type is immutable.

> Wow. It would be great if the language could distinguish (by e.g.
> assigning a different type) a literal from a const char*.

It can.  A literal is not a const char*, but a char const[N].
Which are two distinct types in C++.

Of course, the implicit conversion makes it somewhat different
to exploit the difference (as does the two iterator idiom,
because if I want iterators, I can't directly use a string
literal, but have to declare a veriable).

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 30, 11:39 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> On Fri, 30 Mar 2007 10:46:36 CST, James Kanze wrote:
> >On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> >> On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
> >> >Many functions like ifstream::open() should be operloaded in C++09  to
> >> >handle std::string as well plain char pointers.

> >> Do you find that to be a good idea?

> >The committee apparently does; it's already in the draft.

> What about you? Do you find it to be a good idea?

Given the current starting point, yes.  As I said, you can't do
away with the char const* functions.  And you certainly want to
support both std::string and string literals; anything less
would be perverse.  As I also said, when I implemented my own
versions of such things, way, way back in pre-standard days, I
actually used something like what the original poster suggested.
I don't think that this is an option today.  (I'm not sure that
it was the best option even then, but it was an option.  And it
worked pretty well for my style of programming, in the contexts
I used it.)

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Andrei Alexandrescu (See Website For Email)
<SeeWebsiteForEmail@erdani.org> wrote:

>
> Wow. It would be great if the language could distinguish (by e.g.
> assigning a different type) a literal from a const char*.
   Does it need to?  It already handles const char *, whether it is
a literal string or some other C style string.  Providing a templated
ctor using const basic_string<char,T,A> & to hold the filename, means
you have two possible ctors for const char *, the non templated [as is
C++98 ] and the templated one with a conversion [which is not chosen]
the proper ctor would unambiguously be determined.

If this logic is correct thats 3 additional templated ctors and 3
overloaded similiarly open functions and one for basic_filebuf::open
thats 7 overloads for just string support.

Now add in wchar_t support and thats 14 additional overloads. Totaling
21 overloads for string and wchart_t support for filenames.

Did I miss any:)

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 30, 7:27 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
> Gennaro Prota ha scritto:

> > On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:

> >> Many functions like ifstream::open() should be operloaded in C++09  to
> >> handle std::string as well plain char pointers.

> > Do you find that to be a good idea?

> Personally I think so. In fact this trick is so simple and convenient
> that I would like it proposed for boostification.

That's a different question.  The problem is that using his
classes introduces an additional user defined conversion
operator.  Which would break code.  (None of my code, hopefully,
but legal code.)

(And I have a question: I interpreted Gennaro's question to
concern only whether the functions in question should be
overloaded.  You seem to interpret it as concerning the
proposted technique.  So which is it?)

    [...]
> This trick has a narrower scope than forwarding and because of that it's
> much simpler to use and apply. Writing one function that works for both
> char* and strings is just a one-token change and it allows you to forget
> putting c_str() all over the place.

That's basically why I did it.  Rather than double the number of
functions everywhere, I added a helper class.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Sun,  1 Apr 2007 14:40:30 CST, James Kanze wrote:

>On Mar 30, 7:27 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
>wrote:
>> Gennaro Prota ha scritto:
>
>> > On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
>
>> >> Many functions like ifstream::open() should be operloaded in C++09  to
>> >> handle std::string as well plain char pointers.
>
>> > Do you find that to be a good idea?
>
>> Personally I think so. In fact this trick is so simple and convenient
>> that I would like it proposed for boostification.
>
>That's a different question.  The problem is that using his
>classes introduces an additional user defined conversion
>operator.  Which would break code.  (None of my code, hopefully,
>but legal code.)
>
>(And I have a question: I interpreted Gennaro's question to
>concern only whether the functions in question should be
>overloaded.  You seem to interpret it as concerning the
>proposted technique.  So which is it?)

Whether it *should* be overloaded. Actually even more: whether a
constructor, or any other member, taking a basic_string, should exist
at all. Am I paranoid about coupling?

--
Gennaro Prota.
In search of passioned C++ developers?   I'm available.
Breeze C++:  https://sourceforge.net/projects/breeze/
                    (incomplete, preview state)

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mar 31, 12:39 am, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> On Fri, 30 Mar 2007 10:46:36 CST, James Kanze wrote:
> >On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> >> On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
> >> >Many functions like ifstream::open() should be operloaded in C++09  to
> >> >handle std::string as well plain char pointers.
>
> >> Do you find that to be a good idea?
>
> >The committee apparently does; it's already in the draft.
>
> What about you? Do you find it to be a good idea?
>
> --

Standards should be conforming and this is a defect (inconsistency) in
std library that you can not pass a standard data type as string
directly to functions who have 'char *' argumented std counterparts.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 2, 5:52 am, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:

> Whether it *should* be overloaded. Actually even more: whether a
> constructor, or any other member, taking a basic_string, should exist
> at all. Am I paranoid about coupling?

Coupling of what?  Are you afraid that the standard library
might depend on the standard library? :-)

Seriously, I understand your concern, but something like the
standard library should be a hierarchy, and higher level
elements should be able to use lower level ones.  In particular,
logically, I would expect string to be very near the base; the
iostream stuff can use string, but not vice versa.  Practically,
however, the library developped historically in such a way that
this layered model cannot be applied, and everything does depend
on everything else.  I imagine that it's a serious problem for
the implementors, but it really doesn't affect the rest of us
that much.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 1, 10:53 pm, SeeWebsiteForEm...@erdani.org ("Andrei
Alexandrescu (See Website For Email)") wrote:
> James Kanze wrote:
> > On Mar 31, 9:05 pm, "Andrei Alexandrescu (See Website For Email)"
> > <SeeWebsiteForEm...@erdani.org> wrote:
> >> Mathias Gaunard wrote:
> >>> On Mar 28, 6:09 pm, Danne_es...@hotmail.com (Daniel Svensson) wrote:
> >>>> Many functions like ifstream::open() should be operloaded in C++09  to
> >>>> handle std::string as well plain char pointers. To not force mutliple
> >>>> definitions (and implementations) of the same function, one may solve
> >>>> this by implementing a class with the sole purpose of letting the user
> >>>> use either string or char* without any special overhead.
>
> >>> A better solution would be to only provide a constructor with a string
> >>> type and design the string type so that constructing one from a
> >>> literal doesn't copy.
> >>> That would mean the string type is immutable.
>
> >> Wow. It would be great if the language could distinguish (by e.g.
> >> assigning a different type) a literal from a const char*.
>
> > It can.  A literal is not a const char*, but a char const[N].
> > Which are two distinct types in C++.
>
> > Of course, the implicit conversion makes it somewhat different
> > to exploit the difference (as does the two iterator idiom,
> > because if I want iterators, I can't directly use a string
> > literal, but have to declare a veriable).
>
> And as Mathias mentioned, literals further convert to char* for C
> compatibility. But even if that were deprecated, you can't share
> addresses of literals for two reasons:
>
> 1. You can't tell a literal from a mutable char[N] because "const" is at
> the same time a type qualifier and a storage class. Consider:
>
> auto a = "Hi!"; // type of a is const char[4]
> char b[4];
> const char (&c)[4] = b;
> // a and c are indistinguishable, yet c's content can be mutated
>
> 2. You can't tell a static const char[N] from a stack-allocated const
> char[N]. This is because static is a storage class and not a type qualifier.
>
> This all means that you can't add a constructor to string taking a const
> char[N] that actually just stores the pointer in knowledge that that
> pointer refers to immutable memory of static duration.
>
> Andrei
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]- Hide quoted text -
>
> - Show quoted text -

Instead of defining two overloads for 'const char *' and 'string' we
can define std functions so that they accept a helper class as their
argument that accepts both 'const char *' and 'string'  as its
initializer and produces the least overhead.take this for example:

void std_func(const str_type s){
   *s++;
   s[1];
};

class str_type{
    const char* ptr;
public:
    str_type(const char *);
    str_type(const string&);

    const char operator *();
    const char operator[](unsigned);

    const char operator ++();
    const char operator ++(int);

    const char operator --();
    const char operator --(int);
}

having such a class we can just change the input parameter type of
existing std functions without breaking existing code or changing the
implementation of any existing std function.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

jam wrote:
> On Mar 31, 12:39 am, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> > On Fri, 30 Mar 2007 10:46:36 CST, James Kanze wrote:
> > >On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> > >> On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
> > >> >Many functions like ifstream::open() should be operloaded in C++09  to
> > >> >handle std::string as well plain char pointers.
> >
> > >> Do you find that to be a good idea?
> >
> > >The committee apparently does; it's already in the draft.
> >
> > What about you? Do you find it to be a good idea?
> >
> > --
>
> Standards should be conforming

What should they conform to? In particular, what does the C++ standard
fail to conform with in this case? In what way does it fail to
conform?

I can think of many ways to describe the possible problem that this
suggestion is intended to solve; but I can't figure out how to use the
word "conform" as the central point in any of those descriptions.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <C236CED6.60BD%greghe@pacbell.net>,
 greghe@pacbell.net (Greg Herlihy) wrote:

> What's the rationale for retaining a "const char *" constructor after a
> "const std::string&" constructor has been added to a Standard Library class?

Besides a performance hit, onstructing the std::string from a const
char* may throw an exception that currently isn't being caught.

> It seems to me that the only kind of program that would break if the const
> char * constructor were eliminated, would have to contain code so contrived
> and so contrary to widely-accepted "best practices" that the chances that
> any "real-world" C++ program would be adversely affected by eliminating the
> current constructor - are close to none.
>
> Greg
>
> ---
> [ 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.comeaucomputing.com/csc/faq.html                      ]

--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  773 961-1620

---
[ 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.comeaucomputing.com/csc/faq.html                      ]