 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daniel Svensson
Guest
|
 Posted: Wed Mar 28, 2007 9:09 pm Post subject: Thoughts about a standard string_argument to unify char* and |
 |
|
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 ] |
|
| Back to top |
|
 |
Gennaro Prota
Guest
|
| Posted: Thu Mar 29, 2007 7:55 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Wed, 28 Mar 2007 16:09:26 GMT, Daniel Svensson wrote:
| Quote: | 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?
| Quote: | 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 ] |
|
| Back to top |
|
|
Daniel
Guest
|
| Posted: Fri Mar 30, 2007 3:06 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
Gennaro Prota Wrote:
| Quote: | 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?
I think this is a good idea to be able to use std::string where you |
earlier was forced to use either a c-string or call string::c_str().
| Quote: | 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)
I understand that, but the produced executables can become bigger then |
needed and slightly less code would be required.
I made a test dll exporting 100 simple functions. One version of the dll
used a string_arg class and another made it the normal way using
overloading resulting in 200 functions. In implementing the function I
used exactly the same code in the char* and string_arg functions. While
the std::string version uses the const char* function.
Then I made a program (dlluser) that called each of these functions.
Here are the different sizes of the files produced using VS 8.0 Release.
|using string_arg | using overloading | Difference
--------------------------------------------------------------
dll | 12 288 byte | 22 528 byte | >10kB
dlluser | 15 360 byte | 21 504 byte | >6kB
I have realized that this is probably not the best solution to use in
standard C++ since to benefit from it old functions would have to change
their function signature. Still new functions like the filesystem and
regex library may make good use of it.
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 ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Fri Mar 30, 2007 4:46 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 29, 4:55 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
| Quote: | 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.
| Quote: | 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 (AT) gmail (DOT) 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 ] |
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Fri Mar 30, 2007 5:27 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
Gennaro Prota ha scritto:
| Quote: | 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.
| Quote: |
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)
|
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. I find this very useful. Don't you
hate to write:
ostringstream path;
// compose path
ifstream file(path.str().c_str()); // ugly
or worse:
string name;
ifstream file((name + ".txt").c_str()); // ugly
Well, if the c_str() could be left out, I would be much happier.
[Note: please let's not focus on ifstreams and pathnames specifically...
I know there are better alternatives like boost::filesystem, but cases
like the one above pop up in a lot of places.]
It's also easily extensible:
template <class T>
const char* get_c_str(const T& str)
{
return str.c_str();
}
class string_arg
{
const char* _str;
public:
string_arg(const char* str)
: _str(str)
{}
template <class T>
string_arg(const T& str)
: _str(get_c_str(str))
{}
operator const char*() const { return _str; }
const char* c_str() const { return _str; }
};
By specializing the get_c_str() template, user-provided string-like
classes can also be supported. The library need not even be aware of
that, one single signature per function needs to be provided and will
work in any case.
Just my opinion,
Ganesh
---
[ 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 ] |
|
| Back to top |
|
|
Gennaro Prota
Guest
|
| Posted: Sat Mar 31, 2007 2:39 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Fri, 30 Mar 2007 10:46:36 CST, James Kanze wrote:
| Quote: | 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 ] |
|
| Back to top |
|
|
Mathias Gaunard
Guest
|
| Posted: Sat Mar 31, 2007 6:17 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 28, 6:09 pm, Danne_es...@hotmail.com (Daniel Svensson) wrote:
| Quote: | 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 ] |
|
| Back to top |
|
|
Andrei Alexandrescu (See
Guest
|
| Posted: Sat Mar 31, 2007 7:05 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
Mathias Gaunard wrote:
| Quote: | 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*.
As of OP's question, don't we need a total of four overloads (for
wchar_t and wstring as well)?
Andrei
P.S. The typo "operloaded" suggests the word "operloading" as a
contraction for "operator overloading"  ).
---
[ 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 ] |
|
| Back to top |
|
|
Mathias Gaunard
Guest
|
| Posted: Sun Apr 01, 2007 12:37 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 31, 9:05 pm, "Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEm...@erdani.org> wrote:
| Quote: | 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 ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Apr 01, 2007 4:03 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 31, 9:05 pm, "Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEm...@erdani.org> wrote:
| Quote: | 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 (AT) gmail (DOT) 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 ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Apr 01, 2007 8:39 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 30, 11:39 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
| Quote: | 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 (AT) gmail (DOT) 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 ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Apr 01, 2007 8:40 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 30, 7:27 pm, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
| Quote: | 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?)
[...]
| Quote: | 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 (AT) gmail (DOT) 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 ] |
|
| Back to top |
|
|
Carl Barron
Guest
|
| Posted: Mon Apr 02, 2007 12:42 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
Andrei Alexandrescu (See Website For Email)
<SeeWebsiteForEmail (AT) erdani (DOT) org> wrote:
| Quote: |
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 ] |
|
| Back to top |
|
|
Andrei Alexandrescu (See
Guest
|
| Posted: Mon Apr 02, 2007 12:53 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
James Kanze wrote:
| Quote: | 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-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Alf P. Steinbach
Guest
|
| Posted: Mon Apr 02, 2007 7:32 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
* Andrei Alexandrescu (See Website For Email):
| Quote: |
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.
|
Well, you can, it's even a FAQ. Well, all right, it's not a FAQ item in
its own right, just a part of a FAQ item, and that item isn't
specifically about detecting literals. But, it applies:
"The (even easier) non-technical approach is to put a big fat ugly
comment next to the class definition. The comment could say, for
example, // We'll fire you if you [...] or even just [...]. Some
programmers balk at this because it is enforced by people rather than
by technology, but don't knock it on face value: it is quite effective
in practice."
The C++ standard library isn't as type safe as it could be, it is in
most cases very pragmatically type unsafe, relying on programmers being
sensible rather than the compiler saving them from doing silly things.
A /standard/ practical, efficient immutable string carrier class that
made the pragmatic choice of treating char const[n] as a literal --
unless otherwise instructed -- would IMHO be great.
But once such a class is proposed, SomeOne will probably start arguing
that it should have tread safe reference counting (for the case where
it's initialized with a non-literal), customizable destruction, real
string content instead of just a sequence of encoding values, etc. ad
nauseam, so much baggage that the proposal would never fly.
I'd like the customizable destruction (otherwise that wheel has to be
reinvented every time you get a string from some C API that requires the
string to be destroyed using a special function), but nothing else.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
---
[ 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 ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
