string types (was: switch on strings) - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

string types (was: switch on strings)

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Chris Frey
Guest

Posted: Thu Jun 16, 2005 8:10 am Post subject: string types (was: switch on strings)

This is a late followup post, but something Francis Glassborow mentioned
got me worried...

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk>:

Quote:

Then you may be pleased to learn that one of the proposals on the table
for C++0x is to extend the switch statement. The exact details are still
being worked out and will probably depend on whether some support for
udt literals (possibly via const construtors) makes it into C++0x)

The latter is arguably even more important because it is a continuing
oddity that literals for std::string are of type char const *.

Where can I find information on how this "defect" is supposed to be
fixed? Is there an intention to make const char* and std:: string
more closely tied together? I like that they are different types, and
would like them to be even more different.

The reason I mention it is that I find it useful to know whether
a string is a user data type or one the programmer typed in as a
string literal. In fact, I would like to have const char* be a different
type for in-program constant strings, since const char* is not a
strict flag, and this difference must be maintained by the programmer.

For example:

cout << "hello world"; // string could be new type...
// char literal * ?

void foo(const char *str) { ... }
// this takes any C style string, has no
// special meaning besides normal const

void foo(const std::string &s) {...}
// C++ string

This would allow code behaviour to be determined by what are "safe strings"
vs. "unsafe user-entered strings", i.e. ideal for web application work.

- Chris

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow
Guest

Posted: Fri Jun 17, 2005 1:15 pm Post subject: Re: string types (was: switch on strings)

In article <42b0b52b$1 (AT) news (DOT) sentex.net>, Chris Frey <cdfrey (AT) sentex (DOT) ca>
writes

Quote:

This is a late followup post, but something Francis Glassborow
mentioned
got me worried...

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk>:

Then you may be pleased to learn that one of the proposals on the
table
for C++0x is to extend the switch statement. The exact details are
still
being worked out and will probably depend on whether some support for
udt literals (possibly via const construtors) makes it into C++0x)

The latter is arguably even more important because it is a continuing
oddity that literals for std::string are of type char const *.

Where can I find information on how this "defect" is supposed to be
fixed?

You mean you do not think that it is a defect that 'naked values' of a
type have a different type from that for which they are values? C
certainly thinks so as C99 introduced the concept of compound literals
to try to provide a mechanism for this.

Quote:

Is there an intention to make const char* and std:: string
more closely tied together? I like that they are different types, and
would like them to be even more different.

No, the problem being addressed only indirectly impinges on that. Yes,
it is a complicated issue and strings are a good poster child for it.

Quote:

The reason I mention it is that I find it useful to know whether
a string is a user data type or one the programmer typed in as a
string literal. In fact, I would like to have const char* be a
different
type for in-program constant strings, since const char* is not a
strict flag, and this difference must be maintained by the programmer.

For example:

cout << "hello world"; // string could be new type...
// char literal * ?

void foo(const char *str) { ... }
// this takes any C style string,
has no
// special meaning besides normal const

void foo(const std::string &s) {...}
// C++ string

And if you overload foo() that way foo("xyz") resolves to the first one.
I am not saying that is wrong, but what I am saying is that the
consequence of not have any 'values' for std::string is counter
intuitive, and makes C++ an unusual language.

Quote:

This would allow code behaviour to be determined by what are "safe
strings"
vs. "unsafe user-entered strings", i.e. ideal for web application
work.

I am not sure I understand your point.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/
youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Maxim Yegorushkin
Guest

Posted: Fri Jun 17, 2005 1:59 pm Post subject: Re: string types (was: switch on strings)

On Thu, 16 Jun 2005 12:10:56 +0400, Chris Frey <cdfrey (AT) sentex (DOT) ca> wrote:

Quote:

This is a late followup post, but something Francis Glassborow mentioned
got me worried...

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk>:
Then you may be pleased to learn that one of the proposals on the table
for C++0x is to extend the switch statement. The exact details are still
being worked out and will probably depend on whether some support for
udt literals (possibly via const construtors) makes it into C++0x)

The latter is arguably even more important because it is a continuing
oddity that literals for std::string are of type char const *.

Where can I find information on how this "defect" is supposed to be
fixed? Is there an intention to make const char* and std:: string
more closely tied together? I like that they are different types, and
would like them to be even more different.

Well, IMO they are too different even now, so you may get counterintuitive
behaviour like in this snippet:

#include <string>

void f(bool);
void f(std::string);

int main()
{
f("hey"); // calls f(bool)
}

--
Maxim Yegorushkin <firstname.lastname (AT) gmail (DOT) com>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Chris Frey
Guest

Posted: Sat Jun 18, 2005 9:32 am Post subject: Re: string types

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> wrote:

Quote:

A const char* is not the same thing as a std::string, so yes, I think they
should be different types.

I can understand needing a standard way to convert between them reliably,
but it should be optional, like explicit is for constructors.

Quote:

Is there an intention to make const char* and std:: string
more closely tied together? I like that they are different types, and
would like them to be even more different.

No, the problem being addressed only indirectly impinges on that. Yes,
it is a complicated issue and strings are a good poster child for it.

I'd love to read up on this, but I admit I don't know where to look
for the recommendations and suggested C++ standard changes.

Quote:

Unusual from a newbie's point of view, but not from a C++ point of view.
The underlying representation of a const char* and std::string are quite
different. And it's my view that the programmer should know which one
he intends to use.

A literal string is not a std::string. It's an array of chars referenced
by a pointer. If the programmer wants a std::string, he should ask
for it: std::string("hello world")

Now if there was some new syntax to create a 'value type' for std::string,
I don't mind that at all. Perhaps, just for discussion sake, we can use
the following syntax:

std::string data = `this is a std::string value`;
// note the backticks

Quote:

This would allow code behaviour to be determined by what are "safe
strings"
vs. "unsafe user-entered strings", i.e. ideal for web application
work.

I am not sure I understand your point.

I'm working on a side project to use C++ as a language for programming
web applications. I chose C++ because of its strict typing and compile
time checks, which in my opinion makes it superior for large applications
compared to things like PHP.

Since const char* is a different type than std::string, I want to use one
for "safe strings" and the other for "user data" such as comes from
forms or the database. Thus, quoting and escaping of data can be handled
automatically based on the type, source, and destination of the string data.

html << "
would be handled differently than:

std::string data = "<p>hello</p>";
html << data;

And it is the difference of types that allows this. I'm just concerned
about making const char* and std::string more convertable than they
already are.

When I said that I wanted the types to be even more different, I meant
that I would like to be able to tell the difference between a string
embedded in the source code and strings that just happen to be data
in the form of a const char* coming from the user.

For my application, there is value in knowing the difference, for safety
and trust reasons, and I can't do that currently. Hence my suggestion
for something like:

const char literal *str;
or
char literal *str;

Which would only match "hello world" type strings embedded directly in the
source.

- Chris

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow
Guest

Posted: Sun Jun 19, 2005 4:38 pm Post subject: Re: string types

In article <42b3401c (AT) news (DOT) sentex.net>, Chris Frey <cdfrey (AT) sentex (DOT) ca>
writes

Quote:

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> wrote:
You mean you do not think that it is a defect that 'naked values' of a
type have a different type from that for which they are values? C
certainly thinks so as C99 introduced the concept of compound literals
to try to provide a mechanism for this.

A const char* is not the same thing as a std::string, so yes, I think they
should be different types.

I can understand needing a standard way to convert between them reliably,
but it should be optional, like explicit is for constructors.

I understand your reservations but built-in types have literals that are
rvalues of the same type. Currently we have no equivalent mechanism for
udts. The consequence is that the compiler can treat literals of
built-in types directly but there is no corresponding opportunity for
udts. This makes udts that value types second class. C++ has tried to
make udts and built-in types have equal status so that there should be
no need for continually adding new types to the core of the language (as
there is in C)

One idea is to provide const ctors that would allow (encourage) the
compiler to explore optimisations for udt literals. In some
circumstances the const ctor could be called implicitly. Given such a
language addition I could, with my extended switch proposal, write:

std::string control;
std::cin >> control;
switch(control){
case "next" : // actions
case "last" : // actions
case "abandon" : // actions
default : // actions
}

and the compiler would deduce that the three items in quotes were
literal std::string values and not arrays of const char.

Obviously there is a good deal to sort out and C++ cannot follow exactly
the same mechanism that C has for handling compound literals.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gabriel Dos Reis
Guest

Posted: Mon Jun 20, 2005 9:06 am Post subject: Re: string types

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> writes:

Quote:

In article <42b3401c (AT) news (DOT) sentex.net>, Chris Frey <cdfrey (AT) sentex (DOT) ca
writes
Francis Glassborow You mean you do not think that it is a defect that 'naked values' of a
type have a different type from that for which they are values? C
certainly thinks so as C99 introduced the concept of compound literals
to try to provide a mechanism for this.

A const char* is not the same thing as a std::string, so yes, I think they
should be different types.

I can understand needing a standard way to convert between them reliably,
but it should be optional, like explicit is for constructors.

I understand your reservations but built-in types have literals that are
rvalues of the same type. Currently we have no equivalent mechanism for
udts. The consequence is that the compiler can treat literals of
built-in types directly but there is no corresponding opportunity for
udts. This makes udts that value types second class. C++ has tried to
make udts and built-in types have equal status so that there should be
no need for continually adding new types to the core of the language (as
there is in C)

Yup. And we should have assignment for C-arrays too :-)

--
Gabriel Dos Reis
[email]gdr (AT) integrable-solutions (DOT) net[/email]

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Peter Dimov
Guest

Posted: Mon Jun 20, 2005 9:08 am Post subject: Re: string types

Francis Glassborow wrote:

[...]

Quote:

One idea is to provide const ctors that would allow (encourage) the
compiler to explore optimisations for udt literals. In some
circumstances the const ctor could be called implicitly. Given such a
language addition I could, with my extended switch proposal, write:

std::string control;
std::cin >> control;
switch(control){
case "next" : // actions
case "last" : // actions
case "abandon" : // actions
default : // actions
}

and the compiler would deduce that the three items in quotes were
literal std::string values and not arrays of const char.

In theory, given a 'std::string::operator==( char const (&rhs) [N] ) const'
templated comparison operator and a reasonably smart compiler, the above
could result in something like

size_t const __n = control.size();
char const * __p = control.data();

if( __n == 4 && memcmp( __p, "next", 4 ) == 0 )
{
// ...
}
else if( __n == 4 && memcmp( __p, "last", 4 ) == 0 )
{
// ...
}
else if( __n == 7 && memcmp( __p, "abandon", 7 ) == 0 )
{
// ...
}
else
{
// ...
}

This isn't too bad, and requires no dedicated compiler support.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Chris Frey
Guest

Posted: Mon Jun 20, 2005 9:15 am Post subject: Re: string types

Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> wrote:

Quote:

I was thinking about this in anticpation of your response, and thought
overloading the keyword 'literal' would be a very powerful method to
accomplish this.

In my earlier code suggestion, you could do:

void foo(char literal *str) {
// do something
}

foo("hello world"); // compiles fine

char literal *s = "hello world";
foo(s); // compiles fine, literal "sticks"
// like const does

const char *cs = "hello world";
foo(cs); // error or warning

Overloading the literal keyword in the case of a class would be a
high-precedence overload, and optional, like explicit.

class foo {
public:
literal foo(char literal *str); // this constructor handles all
// high-precedence literal conversions
// for this class
};

With this structure, you'd have 3 levels of constructors: literal, normal,
and explicit. Each in descending order of "automated-ness".

Plus, the programmer could add literal overloads for classes that don't
support them, like:

class foo {
public:
foo(const char *str); // old style
};

// programmer adds:
operator literal <foo> (const char *str); // now foo handles C-style
// string literals

I imagine there would need to be rules that restrict this overloading
in a given module so only one is active at a time for a given literal
type. Maybe regular usage, like your switch example, could handle this
automatically, since only one class is in use there. I'd also imagine
that it would be handy to turn them off or override them too.

Has anyone thought of this before?
- Chris

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

ThosRTanner
Guest

Posted: Mon Jun 20, 2005 2:10 pm Post subject: Re: string types (was: switch on strings)

Maxim Yegorushkin wrote:

Quote:

On Thu, 16 Jun 2005 12:10:56 +0400, Chris Frey <cdfrey (AT) sentex (DOT) ca
wrote:

This is a late followup post, but something Francis Glassborow
mentioned
got me worried...

Francis Glassborow
Then you may be pleased to learn that one of the proposals on the
table
for C++0x is to extend the switch statement. The exact details
are still
being worked out and will probably depend on whether some support
for
udt literals (possibly via const construtors) makes it into C++0x)

The latter is arguably even more important because it is a
continuing
oddity that literals for std::string are of type char const *.

Where can I find information on how this "defect" is supposed to be
fixed? Is there an intention to make const char* and std:: string
more closely tied together? I like that they are different types,
and
would like them to be even more different.

Well, IMO they are too different even now, so you may get
counterintuitive
behaviour like in this snippet:

#include
void f(bool);
void f(std::string);

int main()
{
f("hey"); // calls f(bool)
}

Isn't that mainly due to a hangover from C, namely that anything at all
can be coerced into a boolean (possibly because C didn't have a
boolean). Certainly, not allowing this would make certain things a lot
clearer, but break a lot of existing C / C++ code.

Frankly, I'd like to see that hangover be put out to grass, I really
don't see the advantage of being able to write

if (a & b) //i.e. if ((a & b) != 0)

I know the first is shorter, but what if you meant to write

if (a && b) //completely different.

It's a bug I've seen more than a few times (it's a little like if (a =
b) vs if (a == b), but it isn't so obvious in its unfortunate side
effects) and I really have grown to appreciate those languages that
just don't allow that short cut.

And unfortunately it grows, as there is pressure on classes to allow
themselves to be coerced to bool (such as streams), where another
operation would be less ambiguous, even if it required more typing...

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Tue Jun 21, 2005 4:13 pm Post subject: Re: string types (was: switch on strings)

ThosRTanner wrote:

Quote:

Maxim Yegorushkin wrote:

Well, IMO they are too different even now, so you may get
counterintuitive behaviour like in this snippet:

#include <string

void f(bool);
void f(std::string);

int main()
{
f("hey"); // calls f(bool)
}

Isn't that mainly due to a hangover from C, namely that
anything at all can be coerced into a boolean (possibly
because C didn't have a boolean). Certainly, not allowing
this would make certain things a lot clearer, but break a lot
of existing C / C++ code.

The implicit conversions certainly come from C originally.

In the initial proposition for bool, the authors (Andy Koenig
and Dag Bruck, if I remember correctly) recognized the need for
the conversions, in order to support existing code, but proposed
deprecating them, to encourage compiler warnings. The
deprecation was removed from the final proposal.

At the same time, more or less, the grammar for a "condition" in
a while, if or for was extended to allow a declaration. This
extension, of course, only makes sense if the implicit
conversion is present and used. One can argue about the
"elegance" of this, but I can't think of a better solution in
cases like:

if ( D1* pD1 = dynamic_cast< D1* >( pB ) ) {
...
} else if ( D2* pD2 = dynamic_cast< D2* >( pB ) {
...
} ...

I don't have a good answer. (If I were writing a compiler, I'd
probably warn about the implicit conversion, in all cases except
the declaration in a condition. Which is a special case anyway,
since the conversion is of a declaration, and not an
expression.)

--
James Kanze GABI Software
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

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Greg
Guest

Posted: Tue Jun 21, 2005 4:20 pm Post subject: Re: string types

Chris Frey wrote:

Quote:

I think that it is possible that C++ is able to provide most of
facilities of a literal string type, though of course without the
syntax of a built-in type.

The idea would be to declare a "string_literal" class to represent the
"trusted" character array. A string_literal could decay into an
ordinary const char * or std::string, but a conversion in the other
direction would be barred by string_literal's private constructor.
Routines that required "trusted" strings would accept a string_literal
type.

The key to making this idea practical is to have a means to ensure that
string_literals are constructed from, well, string literals. To do so,
a special function that is a friend of string_literal will produce
string_literal objects, but this special function is never to be
invoked directly. Rather a macro is used to ensure that the string
argument passed to the helper function is properly double-quoted:

class string_literal
{
public:
friend string_literal do_not_call_this_function(const char *s);
~string_literal();

operator const char *() const;
const char *str() const { return s; }

private:
string_literal(const char *inStr) : s(inStr) {}
const char * const s;
};

#define LITERAL(x) do_not_call_this_function(""x"")

static void RequireLiteral( string_literal inStr)
{
std::printf("%s", inStr.str());
}

int main()
{
string_literal stringLiteral = LITERAL("String");
char * charPtr = "String";
const char * constCharPtr = "String";

RequireLiteral( LITERAL("String"));// OK
RequireLiteral( stringLiteral ); // OK
RequireLiteral( "String" ); // Error: must use LITERAL
RequireLiteral( constCharPtr ); // Error: not a literal
RequireLiteral( LITERAL(charPtr) ) // Error: charPtr not quoted

return 0;
}

By not publicizing the actual helper function's name and using LITERAL
where needed, there is little risk that the string_literal's safety
guarantee would be compromised by programmer error.

Greg

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

ThosRTanner
Guest

Posted: Wed Jun 22, 2005 1:12 pm Post subject: Re: string types (was: switch on strings)

[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:

Quote:

I have had occasion to spend a lot of time looking for problems

caused by this "flexibility". Purchase of pc-lint by the company and
switching on bool checking was a great help.

Quote:

At the same time, more or less, the grammar for a "condition" in
a while, if or for was extended to allow a declaration. This
extension, of course, only makes sense if the implicit
conversion is present and used. One can argue about the
"elegance" of this, but I can't think of a better solution in
cases like:

if ( D1* pD1 = dynamic_cast< D1* >( pB ) ) {
...
} else if ( D2* pD2 = dynamic_cast< D2* >( pB ) {
...
} ...

I would be inclined to write
if ( D1* pD1 = dynamic_cast< D1* >( pB ), pD1 != NULL ) {
(subject to a suitable definition of NULL! - I've had problems with the
language not being able to distinguish between 0 (a small number) and 0
(a null pointer) before now)

more typing certainly, but it's clear enough (according to feedback
from people who didn't realise you could do that), and doesn't require
special code in the compiler.

Quote:

I don't have a good answer. (If I were writing a compiler, I'd
probably warn about the implicit conversion, in all cases except
the declaration in a condition. Which is a special case anyway,
since the conversion is of a declaration, and not an
expression.)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Falk Tannhäuser
Guest

Posted: Wed Jun 22, 2005 4:28 pm Post subject: Re: string types (was: switch on strings)

ThosRTanner wrote:

Quote:

I would be inclined to write
if ( D1* pD1 = dynamic_cast< D1* >( pB ), pD1 != NULL ) {

Unfortunately, this (a variable definition with initialisation,
followed by an expression separated by a comma) is not allowed
by the grammar - neither in the context of an "if" condition
nor elsewhere.

D1* pD1;
if(pD1 = dynamic_cast<D1*>(pB), pD1 != NULL) {
would be legal, but has the disadvantage of defining pD1 without
initialising it and giving it a larger scope than necessary.

Falk

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT
Page 1 of 1

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