 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Gennaro Prota
Guest
|
 Posted: Mon Apr 02, 2007 8:52 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
 |
|
On Sun, 1 Apr 2007 14:40:30 CST, James Kanze wrote:
| Quote: | 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 ] |
|
| Back to top |
|
 |
James Kanze
Guest
|
| Posted: Mon Apr 02, 2007 3:41 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Apr 2, 5:52 am, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
| Quote: | 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 (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 |
|
|
jam
Guest
|
| Posted: Mon Apr 02, 2007 3:42 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 31, 12:39 am, 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?
--
|
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 ] |
|
| Back to top |
|
|
Guest
|
| Posted: Mon Apr 02, 2007 6:07 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
jam wrote:
| Quote: | 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 ] |
|
| Back to top |
|
|
jam
Guest
|
| Posted: Mon Apr 02, 2007 6:07 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Apr 1, 10:53 pm, SeeWebsiteForEm...@erdani.org ("Andrei
Alexandrescu (See Website For Email)") wrote:
| Quote: | 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 ] |
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Mon Apr 02, 2007 8:09 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
Gennaro Prota ha scritto:
| Quote: | On Sun, 1 Apr 2007 14:40:30 CST, James Kanze wrote:
(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?)
|
I think the technique in itself has a value and should be considered in
the design of future library additions.
About existing classes, as you pointed out, replacing the const char*
signature is not feasible because of backward compatibility, but adding
a new signature might be feasible. Of course, it should be considered
case by case whether such signature should be added or not.
| Quote: |
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?
|
By using this technique, with the additional indirection of the
get_c_str() accessor, there would not be such a strict coupling with
basic_string, as far as I see it. In fact we provide the user with the
capability to use his/her own string-like classes seamlessly.
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 |
|
|
Greg Herlihy
Guest
|
| Posted: Tue Apr 03, 2007 3:41 am Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On 4/1/07 1:39 PM, in article
1175349363.714091.265050 (AT) p77g2000hsh (DOT) googlegroups.com, "James Kanze"
<james.kanze (AT) gmail (DOT) com> wrote:
| Quote: | 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?
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.
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 ] |
|
| Back to top |
|
|
Daniel
Guest
|
| Posted: Tue Apr 03, 2007 5:25 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Apr 3, 12:41 (Greg Herlihy) wrote:
| Quote: |
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 ] |
|
| Back to top |
|
|
Daniel
Guest
|
| Posted: Tue Apr 03, 2007 5:25 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Apr 2, 5:09 pm, Alberto Ganesh Barbati
| Quote: | 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 ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Tue Apr 03, 2007 5:45 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Apr 3, 12:41 am, gre...@pacbell.net (Greg Herlihy) wrote:
| Quote: | 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.
| Quote: | 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 (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: Tue Apr 03, 2007 6:09 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Apr 3, 7:25 pm, "Daniel" <Danne.Es...@gmail.com> wrote:
| Quote: | 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 (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 |
|
|
Nevin :-] Liber
Guest
|
| Posted: Tue Apr 03, 2007 9:18 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
In article <C236CED6.60BD%greghe (AT) pacbell (DOT) net>,
greghe (AT) pacbell (DOT) net (Greg Herlihy) wrote:
| Quote: | 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.
| Quote: | 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 (AT) eviloverlord (DOT) 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 ] |
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Tue Apr 03, 2007 9:25 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
Greg Herlihy wrote:
| Quote: |
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?
|
Efficiency.
--
-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
---
[ 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 |
|
|
Pablo Halpern
Guest
|
| Posted: Sun Apr 29, 2007 10:55 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
On Mar 31, 3: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*.
|
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 ] |
|
| Back to top |
|
|
Alf P. Steinbach
Guest
|
| Posted: Sun Apr 29, 2007 11:57 pm Post subject: Re: Thoughts about a standard string_argument to unify char* |
|
|
* Pablo Halpern:
| Quote: | 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?
|
Regarding weirdness, consider
char const * const data[] = { "a", "b", "c" };
void foo( char static const * static const * strings ) { ... }
int main() { foo( data ); }
The possible occurrence of multiple "static" keywords in a declarator is
an additional weirdness. But perhaps it's better (no introduction of
new keyword) than writing
void foo( char static_const * static_const strings ) { ... }
In another direction, a template based syntax has been proposed for this
kind of thing (except that as far as I can see the problem of character
string literals, which do not have external linkage, was not discussed)
in 2004, by Daniel Frey, <url: http://preview.tinyurl.com/yoo3m2>.
Repeating Daniel's original example, where "ICE" means "Integral
Constant Expression" -- some generalization needed for strings:
void f( int i ) // #1
{
// Used if f is called with a non-ICE
}
template< int I > void f( const int I ) // #2
{
// Used if f is called with an ICE != 2
}
template<> void f<2>( const int ) // #3
{
// Specialized if f is called with an ICE == 2
}
int main()
{
const int i = 2;
f(i); // calls #1
f(1); // calls #2
f(2); // calls #3
}
And the ensuing discussion (see URL above) brought to view that
essentially the same mechanism had been suggested in 2002 by Aleksey
Gurtovoy, <url: http://tech.groups.yahoo.com/group/boost/message/24271>.
From that perspective what's needed seems to be not new syntax, but
just new semantics in order to make this mechanism work for integral
values and in order to make it deal conveniently with literal strings
and perhaps -- ouch -- floating point values.
In a third direction, this may not be needed. First, it's complicating
the language just to make a generally premature optimization less
unsafe. Second, that safety might be achieved in other ways, such as
registering (pointers to) static data with a static data repository, so
that it can be determined efficiently at run-time whether the data is
static or not -- if measurements show that the copying is too costly,
with that scheme it may be possible to fix it by registering the data,
e.g. by using macros to declare things.
Disclaimer: I haven't really thought this through, just Googled.
Cheers,
- Alf
--
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 |
|
|
Powered by phpBB © 2001, 2006 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
