Topic: tempate new syntax
Author: laurie.cheers@btinternet.com (Laurie Cheers)
Date: Tue, 5 Oct 2004 22:57:52 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<uvfdqovep.fsf@boost-consulting.com>...
> laurie.cheers@btinternet.com (Laurie Cheers) writes:
>> David Abrahams <dave@boost-consulting.com> wrote in message news:<uoejn4izv.fsf@boost-consulting.com>...
>>> A<
>>> B<
>>> C
>>> >
>>> >::foo
>>>
>>> (A.B.C)::foo
>>
>> I'm not sure what the :: would mean in this context (how can a
>> static member of a type be, itself, a type?)
>
> Nobody said there were any static members here.
>
> template <class T>
> struct A { typedef int foo; };
Ah, a type inside a type. There are more things in C++ than are dreamt of in
my philosophy...
>> , but it seems to me the
>> second one can be expressed as A.(B.C::foo)
>
> Not a chance. C has no foo member.
Yes, but (B.C) does. If . has higher precedence than :: (I don't know whether
it does or not), then B.C::foo is equivalent to (B.C)::foo, which was what
was wanted.
> > Or if necessary,
> > A.((B.C)::foo)
>
> I don't think its reasonable to read that as foo being a member of
> B<C> given the expectations set up by other uses of "." and parens in
> C++.
I'm not sure what you mean?
>> I mean, these are just two infix operators.
>
> You mean "." and "::"?
Sure. What else?
> > As with any other combination of infix operators, if precedence
> > doesn't give you the structure you want, you can put in brackets to
> > force the issue, right?
>
> I guess, but this syntax goes heavily against the grain of existing
> C++ syntax.
Actually, the more I think about it, the less I think it does.
How about looking at it a different: suppose, in C++ as it stands now, you
create a class 'vector' which contains lots of types.
class vector
{
typedef class
{
//...stuff required to make a vector of strings...
} string;
typedef class
{
//...stuff required to make a vector of ints...
} int; // yeah, it's a reserved word, but just for the sake of argument...
//...more classes for whatever types you need...
}
Given this, to create a vector of strings, you would write:
vector::string myvec;
Right?
It seems to me that templates can be seen as an automatic way to construct
such a class!
Perhaps instead of a "." operator, "::" would look more like the existing
standard?
vector::int myintvector;
vector::(std::string) mystringvector;
And ok, it's still not clear what we do with templates that have more than
one argument.
--
Laurie Cheers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Olsen <qg4h9ykc5m@yahoo.com>
Date: Tue, 5 Oct 2004 22:57:53 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> oldwolf@inspire.net.nz (Old Wolf) wrote in message
> news:<843a4f78.0409301432.364fc33f@posting.google.com>...
>>Would [[ ]] or ' ' be feasible?
>> vector[[int]] v;
>> vector 'int' v; // not very readable IMHO
>
> [[ ]] is still ambiguous. Something like:
> v[[i]a+a[j]]
> is a perfectly legal expression today.
No it's not. "a[i]" and "i[a]" are equivalent if both "a" and "i" are
builtin types. But the syntax requires that [] be a postfix operator
and does not allow it to be written "[i]a". A legal expression cannot
begin with a [ token.
I think [[ ]] is unambiguous, as long as ]] is a pair of ] tokens,
rather than a single token spelled ]] (so that the expression "a[b[c]]"
remains legal).
--
David Olsen
qg4h9ykc5m@yahoo.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Olsen <qg4h9ykc5m@yahoo.com>
Date: Tue, 5 Oct 2004 22:57:53 +0000 (UTC) Raw View
Laurie Cheers wrote:
> It's not ideal from that perspective, I admit. Maybe a slightly larger
> (harder to overlook) symbol, then? Elsewhere in the thread people were
> suggesting % and ^ as delimiters...
>
> vector%int or vector^int?
>
> (I was originally going to suggest 'of' as an operator - i.e. "vector of int" -
> but I know there's a fear of breaking backwards compatibility with new reserved
> words...)
That exact syntax ("vector of int") was proposed on comp.std.c++ some
time ago.
http://www.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=1042825062.761216%40athprx02&rnum=8&prev=/groups%3Fq%3D%2B%2522vector%2Bof%2Bvector%2Bof%2Bint%2Bs%2522%2Bgroup:comp.std.c%252B%252B%26hl%3Den%26lr%3D%26ie%3DUTF-8%26filter%3D0
The proposal was not well received. Part of the reason was making "of"
a keyword. But to me the more fundamental problem is that templates can
have multiple arguments and those arguments can contain nested template
arguments. Any structure that is variable length and that may be nested
is much easier for humans to parse if it has a closing token.
For example, in each of the following, see how quickly you can match
each template argument with its corresponding template:
A<B<C<D>, E<F, G> > > x;
A of B of (C of D), E of F, G x;
(I agree that neither of them are immediately clear. But I can figure
out the first one much more quickly than the second, because it only
requires matching up paired delimeters, which is a very simple thing to do.)
There are cases where some sort of token is needed to mark the end of
the template arguments even if there is only one template argument that
is not nested, such as
vector of int * * x;
/* "vector<int> **x;",
"vector<int*> *x;", or
"vector<int**> x;" */
I think any scheme that doesn't require a token to mark the end of the
template arguments is a non-starter.
--
David Olsen
qg4h9ykc5m@yahoo.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Wed, 6 Oct 2004 16:44:35 +0000 (UTC) Raw View
David Olsen <qg4h9ykc5m@yahoo.com> wrote in message
news:<2sgcqkF1l5cieU1@uni-berlin.de>...
> kanze@gabi-soft.fr wrote:
> > oldwolf@inspire.net.nz (Old Wolf) wrote in message
> > news:<843a4f78.0409301432.364fc33f@posting.google.com>...
> >>Would [[ ]] or ' ' be feasible?
> >> vector[[int]] v;
> >> vector 'int' v; // not very readable IMHO
> > [[ ]] is still ambiguous. Something like:
> > v[[i]a+a[j]]
> > is a perfectly legal expression today.
> No it's not. "a[i]" and "i[a]" are equivalent if both "a" and "i" are
> builtin types.
And who says they're not?
std::vector< int > v ;
int a[ 5 ] ;
int i, j ;
v[[i]a+a[j]]
The last line is perfectly legal. If we were to use [[ and ]] instead
of < and > for template syntax, we'd break this bit of code.
Or we're back where we are now: the meaning depends on whether the
symbol v is a template or not.
> But the syntax requires that [] be a postfix operator and does not
> allow it to be written "[i]a". A legal expression cannot begin with a
> [ token.
I'm sorry, but it can. All too easily.
> I think [[ ]] is unambiguous, as long as ]] is a pair of ] tokens,
> rather than a single token spelled ]] (so that the expression
> "a[b[c]]" remains legal).
I've just shown an ambiguity. It's legal C++ code, today. (IMHO, it
shouldn't be, but that is another issue.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Wed, 6 Oct 2004 16:44:36 +0000 (UTC) Raw View
Emlyn Corrin <Emlyn.NOSPAM.Corrin@cern.NOSPAM.ch> wrote in message
news:<cjtm6v$pu$1@sunnews.cern.ch>...
> kanze@gabi-soft.fr wrote:
> > oldwolf@inspire.net.nz (Old Wolf) wrote in message
> >> Would [[ ]] or ' ' be feasible?
> >> vector[[int]] v;
> >> vector 'int' v; // not very readable IMHO
> > [[ ]] is still ambiguous. Something like:
> > v[[i]a+a[j]]
> > is a perfectly legal expression today.
> Are you sure? Can you give an example of a piece of compilable code
> containing that?
std::vector< int > v ;
int a[ 5 ] ;
int i, j ;
int
f()
{
return v[[i]a+a[j]] ;
}
I'm not claiming that this is a "feature" of the language -- I would
consider it more of a bug. But it's there.
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Wed, 6 Oct 2004 22:49:02 +0000 (UTC) Raw View
jtorjo@yahoo.com (John Torjo) wrote in message
news:<c638aac5.0410041103.2d05f4ce@posting.google.com>...
> > However I believe that in some significant number of countries the
> > standard keyboard does not contain a '$' character. (Perhaps we
> > could make it $ or the euro or yen symbol..)
> you're kidding, right? Is there a (modern) keyboard that does not have
> the '$' character?
Of the five machines I regularly use, only one has a $ on the keyboard.
And that's a Sparc, with a US keyboard.
Why would a French or a German keyboard have a $ on it? (For that
matter, they don't have a Euro or a Yen character either.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Wed, 6 Oct 2004 22:49:03 +0000 (UTC) Raw View
laurie.cheers@btinternet.com (Laurie Cheers) writes:
>>> , but it seems to me the
>>> second one can be expressed as A.(B.C::foo)
>
>> Not a chance. C has no foo member.
>
> Yes, but (B.C) does. If . has higher precedence than :: (I don't know whether
> it does or not), then B.C::foo is equivalent to (B.C)::foo, which was what
> was wanted.
We're referring to A<B<C>::foo> here. Let me try to explain why
that's an unreasonable representation.
struct X { int c; Y* foo; };
struct Y { X b; } a;
a.(b.c->foo)
is an error, as is
a.((b.c).foo)
and
a.((b.c)->foo)
Dots in C++ are member access operators, and nowhere else in C++ does
parenthesizing an expression cause you to refer to an outer scope.
The existing C++ syntax sets up certain expectations that are wantonly
violated by your proposal.
>> > Or if necessary,
>> > A.((B.C)::foo)
>>
>> I don't think its reasonable to read that as foo being a member of
>> B<C> given the expectations set up by other uses of "." and parens in
>> C++.
>
> I'm not sure what you mean?
See above.
>>> I mean, these are just two infix operators.
>>
>> You mean "." and "::"?
>
> Sure. What else?
>
>> > As with any other combination of infix operators, if precedence
>> > doesn't give you the structure you want, you can put in brackets to
>> > force the issue, right?
>>
>> I guess, but this syntax goes heavily against the grain of existing
>> C++ syntax.
>
> Actually, the more I think about it, the less I think it does.
> How about looking at it a different: suppose, in C++ as it stands now, you
> create a class 'vector' which contains lots of types.
>
> class vector
> {
> typedef class
> {
> //...stuff required to make a vector of strings...
> } string;
>
> typedef class
> {
> //...stuff required to make a vector of ints...
> } int; // yeah, it's a reserved word, but just for the sake of argument...
>
> //...more classes for whatever types you need...
> }
>
> Given this, to create a vector of strings, you would write:
> vector::string myvec;
> Right?
Err, OK.
> It seems to me that templates can be seen as an automatic way to
> construct such a class!
Err, no. vector::string is just an ordinary class with a funny name.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Hyman Rosen <hyrosen@mail.com>
Date: Wed, 6 Oct 2004 23:17:58 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> The last line is perfectly legal.
"ComeauTest.c", line 11: error: expected an expression
return v[[i]a+a[j]] ;
^
What compiler is allowing this? It's definitely *not* legal!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Olsen <qg4h9ykc5m@yahoo.com>
Date: Wed, 6 Oct 2004 23:40:55 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> std::vector< int > v ;
> int a[ 5 ] ;
> int i, j ;
>
> v[[i]a+a[j]]
>
> The last line is perfectly legal.
No, it's not. Have you tried compiling it? It's a syntax error.
C++ standard, 5.2/1, the grammar for postfix expressions:
postfix-expression:
primary-expression
postfix-expression [ expression ]
...
Neither primary-expression nor any of the other forms of
postfix-expression can be empty. [ ] don't appear anywhere else in the
grammar for expressions. Therefore, an expression cannot begin with a
[
token.
--
David Olsen
qg4h9ykc5m@yahoo.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Emlyn Corrin <Emlyn.NOSPAM.Corrin@cern.NOSPAM.ch>
Date: Thu, 7 Oct 2004 15:58:33 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> Emlyn Corrin <Emlyn.NOSPAM.Corrin@cern.NOSPAM.ch> wrote in message
> news:<cjtm6v$pu$1@sunnews.cern.ch>...
> > kanze@gabi-soft.fr wrote:
> > > oldwolf@inspire.net.nz (Old Wolf) wrote in message
>
> > >> Would [[ ]] or ' ' be feasible?
> > >> vector[[int]] v;
> > >> vector 'int' v; // not very readable IMHO
>
> > > [[ ]] is still ambiguous. Something like:
> > > v[[i]a+a[j]]
> > > is a perfectly legal expression today.
>
> > Are you sure? Can you give an example of a piece of compilable code
> > containing that?
>
> std::vector< int > v ;
>
> int a[ 5 ] ;
> int i, j ;
>
> int
> f()
> {
>
> return v[[i]a+a[j]] ;
> }
>
> I'm not claiming that this is a "feature" of the language -- I would
> consider it more of a bug. But it's there.
test.cc: In function `int f()':
test.cc:11: parse error before `[' token
That doesn't compile. I can't see how two consecutive opening brackets could
ever be valid C++.
Are you sure you're not confusing it with something like:
char a[5];
int i;
return i[a];
--
Emlyn Corrin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: "Andrei Alexandrescu (See Website for Email)"
Date: Thu, 7 Oct 2004 15:58:33 +0000 (UTC) Raw View
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1097083117.662386@master.nyc.kbcfp.com...
>
> kanze@gabi-soft.fr wrote:
>> The last line is perfectly legal.
>
> "ComeauTest.c", line 11: error: expected an expression
> return v[[i]a+a[j]] ;
> ^
>
> What compiler is allowing this? It's definitely *not* legal!
He must have confused switching the position of the brackets with switching
what's inside the brackets. i[a] and a[i] are both allowed (with the same
semantics) where a is an array and i is an integral. But yah, [x]y is not.
Now the parser must disambiguate between ]] as a closing template or ]] as a
pair of closing brackets. That doesn't ask for semantic info, only pairing
['s with ]'s.
Then hey, you can't have a ]] inside a compile-time integral or a type...
:o)
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Jonathan Coxhead <jonathan@doves.demon.co.uk>
Date: Thu, 7 Oct 2004 15:58:34 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> Emlyn Corrin <Emlyn.NOSPAM.Corrin@cern.NOSPAM.ch> wrote in message
> news:<cjtm6v$pu$1@sunnews.cern.ch>...
> > kanze@gabi-soft.fr wrote:
> > > oldwolf@inspire.net.nz (Old Wolf) wrote in message
>
> > >> Would [[ ]] or ' ' be feasible?
> > >> vector[[int]] v;
> > >> vector 'int' v; // not very readable IMHO
>
> > > [[ ]] is still ambiguous. Something like:
> > > v[[i]a+a[j]]
> > > is a perfectly legal expression today.
>
> > Are you sure? Can you give an example of a piece of compilable code
> > containing that?
>
> std::vector< int > v ;
>
> int a[ 5 ] ;
> int i, j ;
>
> int
> f()
> {
>
> return v[[i]a+a[j]] ;
> }
>
> I'm not claiming that this is a "feature" of the language -- I would
> consider it more of a bug. But it's there.
Are you confusing i[a] (the same as a[i]) with [i]a (not C or C++ at all)? I
think so!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: White Wolf <wolof@freemail.hu>
Date: Sun, 10 Oct 2004 18:29:41 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> jtorjo@yahoo.com (John Torjo) wrote in message
> news:<c638aac5.0410041103.2d05f4ce@posting.google.com>...
>
>> > However I believe that in some significant number of countries the
>> > standard keyboard does not contain a '$' character. (Perhaps we
>> > could make it $ or the euro or yen symbol..)
>
>> you're kidding, right? Is there a (modern) keyboard that does not have
>> the '$' character?
>
> Of the five machines I regularly use, only one has a $ on the keyboard.
> And that's a Sparc, with a US keyboard.
>
> Why would a French or a German keyboard have a $ on it?
Perl? And about a few million other languages making use of $. :-)
I wonder what German keyboard you have. The one I used certainly had $ on
it. I have used so far Hungarian (3 different kinds), Russian, German, US
and Finnish/Swedish. All had $ on them.
Not that it matters for the C++ character set, but since loads of popular
languages as well as regular expressions do use $, it seems just right to
assume that a machine of a programmer has it.
--
WW aka Attila
:::
Do not waste today regretting yesterday.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Sun, 10 Oct 2004 18:31:36 +0000 (UTC) Raw View
Hyman Rosen <hyrosen@mail.com> wrote in message
news:<1097083117.662386@master.nyc.kbcfp.com>...
> kanze@gabi-soft.fr wrote:
> > The last line is perfectly legal.
> "ComeauTest.c", line 11: error: expected an expression
> return v[[i]a+a[j]] ;
> ^
> What compiler is allowing this? It's definitely *not* legal!
Sorry, you're right. I was confusing it with another obfuscation
trick. (It's obviously not the sort of thing that any reasonable person
would write, even if it were legal.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Stefan Heinzmann <stefan_heinzmann@yahoo.com>
Date: Sun, 10 Oct 2004 18:31:35 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> jtorjo@yahoo.com (John Torjo) wrote in message
> news:<c638aac5.0410041103.2d05f4ce@posting.google.com>...
>
>
>> > However I believe that in some significant number of countries the
>> > standard keyboard does not contain a '$' character. (Perhaps we
>> > could make it $ or the euro or yen symbol..)
>
>
>>you're kidding, right? Is there a (modern) keyboard that does not have
>>the '$' character?
>
>
> Of the five machines I regularly use, only one has a $ on the keyboard.
> And that's a Sparc, with a US keyboard.
>
> Why would a French or a German keyboard have a $ on it? (For that
> matter, they don't have a Euro or a Yen character either.)
Strange! I worked with a fair number of keyboards myself, and they all
had the $ key. Amongst them was a german mechanical typewriter from the
sixties. The computer keyboards I remember were german, swiss german,
spanish, british and US versions. You must be using fairly esoteric gear!
I dare say that not having a dollar sign on a typewriter would have been
considered an omission in Germany even before computers became widespread.
--
Cheers
Stefan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: laurie.cheers@btinternet.com (Laurie Cheers)
Date: Sun, 10 Oct 2004 18:31:36 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<uu0t8ggwv.fsf@boost-consulting.com>...
> laurie.cheers@btinternet.com (Laurie Cheers) writes:
>>>> it seems to me the second one can be expressed as A.(B.C::foo)
>
> We're referring to A<B<C>::foo> here. Let me try to explain why
> that's an unreasonable representation.
>
> struct X { int c; Y* foo; };
> struct Y { X b; } a;
>
> a.(b.c->foo)
>
> is an error, as is
>
> a.((b.c).foo)
>
> and
>
> a.((b.c)->foo)
Obviously - but, er, how is that an analogous situation? I'm not even sure
what operation you're trying to express here.
>> How about looking at it a different way : suppose, in C++ as it stands
>> now, you create a class 'vector' which contains lots of types.
>>
>> class vector
>> {
>> typedef class
>> {
>> //...stuff required to make a vector of strings...
>> } string;
>>
>> //...more classes for whatever types you need...
>> }
>
>> It seems to me that templates can be seen as an automatic way to
>> construct such a class!
>
> Err, no. vector::string is just an ordinary class with a funny name.
Yes. And I'm trying to look at vector<string> in exactly the same way. It's a
normal class with a funny name - the only difference between that and
vector::string is that the source code for it was compiler-generated instead
of hand-written.
Eh, never mind... I accept that this syntax doesn't generalise well for
multiple arguments, so it's a bit flawed...
--
Laurie Cheers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Sergiy Kanilo <skanilo@artannlabs.com>
Date: Sun, 10 Oct 2004 18:31:36 +0000 (UTC) Raw View
"Andrei Alexandrescu (See Website for Email)"
<SeeWebsiteForEmail@moderncppdesign.com> wrote in message
news:2sji7nF1n2mslU1@uni-berlin.de...
>
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1097083117.662386@master.nyc.kbcfp.com...
> >
> > kanze@gabi-soft.fr wrote:
> >> The last line is perfectly legal.
> >
> > "ComeauTest.c", line 11: error: expected an expression
> > return v[[i]a+a[j]] ;
> > ^
> >
> > What compiler is allowing this? It's definitely *not* legal!
>
> He must have confused switching the position of the brackets with
> switching
> what's inside the brackets. i[a] and a[i] are both allowed (with the same
> semantics) where a is an array and i is an integral. But yah, [x]y is not.
>
> Now the parser must disambiguate between ]] as a closing template or ]] as
> a
> pair of closing brackets. That doesn't ask for semantic info, only pairing
> ['s with ]'s.
>
> Then hey, you can't have a ]] inside a compile-time integral or a type...
> :o)
sizeof( v[i[a]+a[j]] )
Cheers,
Serge
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Martin Eisenberg <martin.eisenbergNOS@PAMudo.edu>
Date: Sun, 10 Oct 2004 18:31:36 +0000 (UTC) Raw View
James Kanze wrote:
> jtorjo@yahoo.com (John Torjo) wrote in message
> news:<c638aac5.0410041103.2d05f4ce@posting.google.com>...
>
>> > However I believe that in some significant number of
>> > countries the standard keyboard does not contain a '$'
>> > character. (Perhaps we could make it $ or the euro or yen
>> > symbol..)
>
>> you're kidding, right? Is there a (modern) keyboard that does
>> not have the '$' character?
>
> Of the five machines I regularly use, only one has a $ on the
> keyboard. And that's a Sparc, with a US keyboard.
>
> Why would a French or a German keyboard have a $ on it? (For
> that matter, they don't have a Euro or a Yen character either.)
My German keyboard has $ as Shift-4. Euro is AltGr-e if the OS and
the font support it. It's from Cherry (no affiliation, etc). Yen is
indeed missing, but AltGr-m gives mu in recompense.
Martin
--
Quidquid latine dictum sit, altum viditur.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: John Kewley <j.kewley@dl.ac.uk>
Date: Thu, 30 Sep 2004 16:36:06 +0000 (UTC) Raw View
Walter wrote:
>
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> news:c638aac5.0409162318.4cc59387@posting.google.com...
> > Lets see what we have now:
> >
> > // existing
> > map< std::string,list<vector<int> > > m;
> >
> > // possible
> > map<| std::string,list<|vector<|int|> |> |> m; // 1
> > map<% std::string,list<%vector<%int%> %> %> m; // 2
> > map<^ std::string,list<^vector<^int^> ^> ^> m; // 3
> >
> > map</ std::string,list</vector</int/> /> /> m; // 4
>
> There's D's method of using !( ):
>
> map!( std::string, list!( vector!( int ))) m;
This is preferable. The problem with the .< approach is that the .
can be hard to see, and its absence is easy to miss, so
map!< std::string,list!<vector!<int> > >
would be possible.
There is still the matter of thosy pesky double >> though!
JK
BTW I don't find < > too bad :-)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: laurie.cheers@btinternet.com (Laurie Cheers)
Date: Thu, 30 Sep 2004 16:36:06 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<uhdpzmusk.fsf@boost-consulting.com>...
> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
>
> > llewelly <llewelly.at@xmission.dot.com> writes:
> >
> > [...]
> >
> > | If you don't like using the shift key, I think [= ... =] is an
> > alternative. Or (% ... %). Let's see
> >
> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> >
> > No taker? %-p
>
> Wouldn't changing the opening delimiter be enough to remove the
> ambiguity?
>
> std::map.<std::string,list.<vector.<int> > > bhar_map;
Maybe I'm missing something, but I don't see why templates need a closing
delimiter in the first place.
What's wrong with using an infix operator to indicate them?
vector.int myvec;
(A really nice, clean syntax, IMHO.)
Obviously there are cases where you would need to pass a complex type to a
template, but such types can simply be put in brackets - just like you would
pass any other complex expression to an infix operator.
vector.(std::vector.(int*)) my2dvec;
Templates with multiple parameters can simply be handled using a ternary
version of the operator:
map.(std::string).(vector.int) mystringmap;
--
Laurie Cheers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Fri, 1 Oct 2004 16:28:10 +0000 (UTC) Raw View
laurie.cheers@btinternet.com (Laurie Cheers) writes:
> David Abrahams <dave@boost-consulting.com> wrote in message news:<uhdpzmusk.fsf@boost-consulting.com>...
> > Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> >
> > > llewelly <llewelly.at@xmission.dot.com> writes:
> > >
> > > [...]
> > >
> > > | If you don't like using the shift key, I think [= ... =] is an
> > > alternative. Or (% ... %). Let's see
> > >
> > > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> > >
> > > No taker? %-p
> >
> > Wouldn't changing the opening delimiter be enough to remove the
> > ambiguity?
> >
> > std::map.<std::string,list.<vector.<int> > > bhar_map;
>
> Maybe I'm missing something, but I don't see why templates need a closing
> delimiter in the first place.
> What's wrong with using an infix operator to indicate them?
>
> vector.int myvec;
>
> (A really nice, clean syntax, IMHO.)
It's very appealing in its cleanliness. However, I'm afraid some
structures would not be well-represented that way. How can you
distinguish:
A<
B<
C
>
>::foo
and
A<
B<
C
>::foo
>
??
(A.B.C)::foo
vs
A.(B.C)::foo
?
As I look at it, '.' seems to make a very poor "here is an argument"
operator for C++, especially when combined with parens for grouping,
because of the very close association C++ programmers have with parens
for passing arguments.
> Obviously there are cases where you would need to pass a complex
> type to a template, but such types can simply be put in brackets -
> just like you would pass any other complex expression to an infix
> operator.
>
> vector.(std::vector.(int*)) my2dvec;
I like that too, but only because it appears to use parens for
passing arguments.
> Templates with multiple parameters can simply be handled using a ternary
> version of the operator:
>
> map.(std::string).(vector.int) mystringmap;
That's a bit Haskellish for my taste; seems to go against the spirit
of C++ syntax. Plus it's not clear whether that's
map<std::string,vector<int> >
or
map<std::string<vector<int> > >
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: oldwolf@inspire.net.nz (Old Wolf)
Date: Fri, 1 Oct 2004 17:00:04 +0000 (UTC) Raw View
usenet_cpp@lehrerfamily.com (Joshua Lehrer) wrote:
> jtorjo@yahoo.com (John Torjo) wrote:
> > Now that I come think of it,
> > I like much better:
> >
> > <% %>.
> > Even <$ $> maybe...
If you are going to use '$' then why include the < > ?
vector $int$ v;
> I know that a '$' is not allowed as part of an identifier under strict
> ansi rules.
Only alphanumeric chars and '_'.
> However, there are legacy platforms (VMS) where some
> values and/or identifiers begin with a dollar sign. Thus, "<$OK"
> could either mean "is less than the value '$OK'" or it could be the
> beginning of a template declaration.
I don't think we need to pander to pre-standard implementations
(especially not pre-C89 ones!) I'd bet money that nobody has
ever written code like what you just suggested.
However I believe that in some significant number of countries
the standard keyboard does not contain a '$' character. (Perhaps
we could make it $ or the euro or yen symbol..)
> As long as we are looking to disambguiate, we might as well take this
> into consideration.
Would [[ ]] or ' ' be feasible?
vector[[int]] v;
vector 'int' v; // not very readable IMHO
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: laurie.cheers@btinternet.com (Laurie Cheers)
Date: Mon, 4 Oct 2004 20:03:39 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<uoejn4izv.fsf@boost-consulting.com>...
> laurie.cheers@btinternet.com (Laurie Cheers) writes:
> > Maybe I'm missing something, but I don't see why templates need a closing
> > delimiter in the first place.
> > What's wrong with using an infix operator to indicate them?
> >
> > vector.int myvec;
> >
> > (A really nice, clean syntax, IMHO.)
>
> It's very appealing in its cleanliness. However, I'm afraid some
> structures would not be well-represented that way. How can you
> distinguish:
>
> A<
> B<
> C
> >
> >::foo
>
> and
>
> A<
> B<
> C
> >::foo
> >
> ??
>
> (A.B.C)::foo
> vs
> A.(B.C)::foo
> ?
I'm not sure what the :: would mean in this context (how can a static member
of a type be, itself, a type?), but it seems to me the second one can be
expressed as
A.(B.C::foo)
Or if necessary,
A.((B.C)::foo)
I mean, these are just two infix operators. As with any other combination of
infix operators, if precedence doesn't give you the structure you want, you
can put in brackets to force the issue, right?
> As I look at it, '.' seems to make a very poor "here is an argument"
> operator for C++, especially when combined with parens for grouping,
> because of the very close association C++ programmers have with parens
> for passing arguments.
It's not ideal from that perspective, I admit. Maybe a slightly larger
(harder to overlook) symbol, then? Elsewhere in the thread people were
suggesting % and ^ as delimiters...
vector%int or vector^int?
(I was originally going to suggest 'of' as an operator - i.e. "vector of int" -
but I know there's a fear of breaking backwards compatibility with new reserved
words...)
> > Templates with multiple parameters can simply be handled using a ternary
> > version of the operator:
> >
> > map.(std::string).(vector.int) mystringmap;
>
> That's a bit Haskellish for my taste; seems to go against the spirit
> of C++ syntax. Plus it's not clear whether that's
>
> map<std::string,vector<int> >
>
> or
>
> map<std::string<vector<int> > >
True. I wasn't very happy with the ternary version, even as I wrote it...
Ah, well.
--
Laurie Cheers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Mon, 4 Oct 2004 20:03:39 +0000 (UTC) Raw View
oldwolf@inspire.net.nz (Old Wolf) wrote in message
news:<843a4f78.0409301432.364fc33f@posting.google.com>...
> usenet_cpp@lehrerfamily.com (Joshua Lehrer) wrote:
> > jtorjo@yahoo.com (John Torjo) wrote:
> > > Now that I come think of it,
> > > I like much better:
> > > <% %>.
> > > Even <$ $> maybe...
> If you are going to use '$' then why include the < > ?
> vector $int$ v;
> > I know that a '$' is not allowed as part of an identifier under
> > strict ansi rules.
> Only alphanumeric chars and '_'.
> > However, there are legacy platforms (VMS) where some values and/or
> > identifiers begin with a dollar sign. Thus, "<$OK" could either
> > mean "is less than the value '$OK'" or it could be the beginning of
> > a template declaration.
> I don't think we need to pander to pre-standard implementations
> (especially not pre-C89 ones!)
It is a common extension. They're supported by g++ 3.4.2, for example,
which isn't particularly ancient.
> I'd bet money that nobody has ever written code like what you just
> suggested.
You'd loose. I've seen code which uses dollar signs in identifiers. As
I said, it's a common extension.
> However I believe that in some significant number of countries the
> standard keyboard does not contain a '$' character. (Perhaps we could
> make it $ or the euro or yen symbol..)
That's true, of course. (But most of the code I've seen which used $
was in the Unix world, where US keyboards seem to be frequent, even in
France or Germany.)
> > As long as we are looking to disambguiate, we might as well take
> > this into consideration.
> Would [[ ]] or ' ' be feasible?
> vector[[int]] v;
> vector 'int' v; // not very readable IMHO
[[ ]] is still ambiguous. Something like:
v[[i]a+a[j]]
is a perfectly legal expression today.
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Tue, 5 Oct 2004 06:33:49 +0000 (UTC) Raw View
laurie.cheers@btinternet.com (Laurie Cheers) writes:
> David Abrahams <dave@boost-consulting.com> wrote in message news:<uoejn4izv.fsf@boost-consulting.com>...
>> laurie.cheers@btinternet.com (Laurie Cheers) writes:
>> > Maybe I'm missing something, but I don't see why templates need a closing
>> > delimiter in the first place.
>> > What's wrong with using an infix operator to indicate them?
>> >
>> > vector.int myvec;
>> >
>> > (A really nice, clean syntax, IMHO.)
>>
>> It's very appealing in its cleanliness. However, I'm afraid some
>> structures would not be well-represented that way. How can you
>> distinguish:
>>
>> A<
>> B<
>> C
>> >
>> >::foo
>>
>> and
>>
>> A<
>> B<
>> C
>> >::foo
>> >
>> ??
>>
>> (A.B.C)::foo
>> vs
>> A.(B.C)::foo
>> ?
>
> I'm not sure what the :: would mean in this context (how can a
> static member of a type be, itself, a type?)
Nobody said there were any static members here.
template <class T>
struct A { typedef int foo; };
template <class T>
struct B { typedef char foo; };
struct C {};
> , but it seems to me the
> second one can be expressed as A.(B.C::foo)
Not a chance. C has no foo member.
> Or if necessary,
> A.((B.C)::foo)
I don't think its reasonable to read that as foo being a member of
B<C> given the expectations set up by other uses of "." and parens in
C++.
> I mean, these are just two infix operators.
You mean "." and "::"?
> As with any other combination of infix operators, if precedence
> doesn't give you the structure you want, you can put in brackets to
> force the issue, right?
I guess, but this syntax goes heavily against the grain of existing
C++ syntax.
>> As I look at it, '.' seems to make a very poor "here is an
>> argument" operator for C++, especially when combined with parens
>> for grouping, because of the very close association C++ programmers
>> have with parens for passing arguments.
>
> It's not ideal from that perspective, I admit. Maybe a slightly larger
> (harder to overlook) symbol, then? Elsewhere in the thread people were
> suggesting % and ^ as delimiters...
>
> vector%int or vector^int?
Ick.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Terje =?UNKNOWN?Q?Sletteb=F8?= <tslettebo@hotmail.com>
Date: Tue, 5 Oct 2004 06:33:49 +0000 (UTC) Raw View
"Laurie Cheers" <laurie.cheers@btinternet.com> wrote in message
news:c26006e0.0410040106.3334f702@posting.google.com...
>
> David Abrahams <dave@boost-consulting.com> wrote in message
news:<uoejn4izv.fsf@boost-consulting.com>...
> >
> > It's very appealing in its cleanliness. However, I'm afraid some
> > structures would not be well-represented that way. How can you
> > distinguish:
> >
> > A<
> > B<
> > C
> > >
> > >::foo
> >
> > and
> >
> > A<
> > B<
> > C
> > >::foo
> > >
> > ??
> >
> > (A.B.C)::foo
> > vs
> > A.(B.C)::foo
> > ?
>
> I'm not sure what the :: would mean in this context (how can a static
member
> of a type be, itself, a type?)
It can be a nested class or typedef. In the case above, it could also be a
static integral constant.
> (I was originally going to suggest 'of' as an operator - i.e. "vector of
int" -
> but I know there's a fear of breaking backwards compatibility with new
reserved
> words...)
That's not the only issue: It wouldn't work well in other contexts than
something like "containers of x", such as type traits:
"is_integral of T" just doesn't make any sense, while "is_integral<T>" does.
IMO, I think it's important to have a syntax that conveys that we're talking
about _parameters_. Quite frankly, I think <> does just fine (and maybe
allow ">>").
Regards,
Terje
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: jtorjo@yahoo.com (John Torjo)
Date: Tue, 5 Oct 2004 06:33:49 +0000 (UTC) Raw View
>
> If you are going to use '$' then why include the < > ?
> vector $int$ v;
that's an interesting idea...
>
> However I believe that in some significant number of countries
> the standard keyboard does not contain a '$' character. (Perhaps
> we could make it $ or the euro or yen symbol..)
>
you're kidding, right? Is there a (modern) keyboard that does not have
the '$' character?
John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4 - true binding of your data to UI controls!
+ easily add validation rules (win32gui/examples/smart_dlg)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Emlyn Corrin <Emlyn.NOSPAM.Corrin@cern.NOSPAM.ch>
Date: Tue, 5 Oct 2004 21:14:00 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> oldwolf@inspire.net.nz (Old Wolf) wrote in message
>
>> Would [[ ]] or ' ' be feasible?
>> vector[[int]] v;
>> vector 'int' v; // not very readable IMHO
>
> [[ ]] is still ambiguous. Something like:
> v[[i]a+a[j]]
> is a perfectly legal expression today.
Are you sure? Can you give an example of a piece of compilable code
containing that?
--
Emlyn Corrin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Tue, 5 Oct 2004 21:24:07 +0000 (UTC) Raw View
jtorjo@yahoo.com (John Torjo) writes:
> >
> > If you are going to use '$' then why include the < > ?
> > vector $int$ v;
>
> that's an interesting idea...
>
>
> >
> > However I believe that in some significant number of countries
> > the standard keyboard does not contain a '$' character. (Perhaps
> > we could make it $ or the euro or yen symbol..)
> >
>
> you're kidding, right? Is there a (modern) keyboard that does not have
> the '$' character?
$ is not even part of the basic character set required by all C++
implementations.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Walter <walter@digitalmars.nospamm.com>
Date: Wed, 22 Sep 2004 23:09:18 +0000 (UTC) Raw View
"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409162318.4cc59387@posting.google.com...
> Lets see what we have now:
>
> // existing
> map< std::string,list<vector<int> > > m;
>
> // possible
> map<| std::string,list<|vector<|int|> |> |> m; // 1
> map<% std::string,list<%vector<%int%> %> %> m; // 2
> map<^ std::string,list<^vector<^int^> ^> ^> m; // 3
>
> map</ std::string,list</vector</int/> /> /> m; // 4
There's D's method of using !( ):
map!( std::string, list!( vector!( int ))) m;
It doesn't have any parsing problems in D, and it wouldn't in C++ either.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Wed, 22 Sep 2004 23:09:18 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote
| > David Abrahams <dave@boost-consulting.com> writes:
| > | Wouldn't changing the opening delimiter be enough to remove the
| > | ambiguity?
| > |
| > | std::map.<std::string,list.<vector.<int> > > bhar_map;
| >
| > sure, but it isn't "symmetric" :-) -- as most various suggestions you may
| > have seen in the thread. It looks like people appreciate symmetries.
| > This is syntax discussion, so like taste and colors...
|
| So add some periods to make it symmetric!
If you make it symmetric then you run into what you described below
| std::vector.<int>. vec;
| std::map.<std::string,list.<vector.<int>.>.>.bhar_map;
|
| Might be a problem with decimal points after >, though:
| // I want this to mean foo .< true >. f_true, but does it?
| foo.<1.5>.5>. f_true;
Back to square zero.
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Serhiy Storchaka <storchaka@ksf.kiev.ua>
Date: Wed, 22 Sep 2004 23:09:18 +0000 (UTC) Raw View
David Abrahams wrote:
> kanze@gabi-soft.fr writes:
> > David Abrahams <dave@boost-consulting.com> wrote in message
> > I don't think so:
> >
> > template< bool B > class T {} ;
> >
> > T.< 1 > 2 > tFalse ;
>
> There's no ambiguity here AFAICT. I assume you're asking whether the
> first or second ">" closes the template specialization? You can't
> put a template specialization next to an integer literal, so it's
> pretty clear to me that the second ">" has to be the one that closes
> the template.
T.< false > true > tFalse ;
;)
--
Serhiy Storchaka
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Wed, 22 Sep 2004 23:09:45 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message
news:<u7jqo39sg.fsf@boost-consulting.com>...
> kanze@gabi-soft.fr writes:
> > David Abrahams <dave@boost-consulting.com> wrote in message
> > news:<uhdpzmusk.fsf@boost-consulting.com>...
> >> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> >> > llewelly <llewelly.at@xmission.dot.com> writes:
> >> > [...]
> >> > | If you don't like using the shift key, I think [= ... =] is an
> >> > | alternative.
> >> > Or (% ... %). Let's see
> >> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> >> > No taker? %-p
> >> Wouldn't changing the opening delimiter be enough to remove the
> >> ambiguity?
> >> std::map.<std::string,list.<vector.<int> > > bhar_map;
> > I don't think so:
> > template< bool B > class T {} ;
> > T.< 1 > 2 > tFalse ;
> There's no ambiguity here AFAICT. I assume you're asking whether the
> first or second ">" closes the template specialization? You can't put
> a template specialization next to an integer literal, so it's pretty
> clear to me that the second ">" has to be the one that closes the
> template.
I'm not sure I understand what you are saying. If I have something
like:
template< int I > class T {} ;
I can certainly write:
T< 1 > tOne ;
Or, for that matter:
T< 1 > 2 ? 5 : 10 > tStrange ;
(Under the current rules, I'd need to put the expression in
parentheses. Part of the advantage of using different tokens, IMHO, is
that this would be clear without the parentheses.)
Offhand, I don't see how changing the opening < to .< changes anything
here.
> Note: I didn't claim the grammar would be LALR(1), though I think
> this case actually can be parsed with an LALR(1) grammar.
It's not a question of LALR. It's a question of having two distinct
tokens, one for greater than, and another for closing templates.
Although I think I get what you are getting at. The parser doesn't need
two distinct tokens, since it knows what it is parsing from the opening
token. Human readers do, however.
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: "Andrei Alexandrescu (See Website for Email)"
Date: Fri, 24 Sep 2004 14:55:41 +0000 (UTC) Raw View
"Walter" <walter@digitalmars.nospamm.com> wrote in message
news:5x14d.354$He1.292@attbi_s01...
> There's D's method of using !( ):
>
> map!( std::string, list!( vector!( int ))) m;
>
> It doesn't have any parsing problems in D, and it wouldn't in C++ either.
I love that.
By the way, the iterations in this thread over failing syntaxes are a mute
witness (ah I love the "mute witness" idiom... has such a melodrama scent
with it) that language design is damn hard and should be done with maximum
care. And when we think that syntax is the easiest part... the real killer
is semantics :o). Or "bah, it's just semantics" as another idiom goes. (That
one I never understood. How come, "just" semantics? Semantics is
everything!)
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Rob Williscroft <rtw@freenet.co.uk>
Date: Sat, 18 Sep 2004 14:20:48 +0000 (UTC) Raw View
Gabriel Dos Reis wrote in news:m3fz5hkd04.fsf@merlin.cs.tamu.edu in
comp.lang.c++.moderated:
>| Wouldn't changing the opening delimiter be enough to remove the
>| ambiguity?
>|
>| std::map.<std::string,list.<vector.<int> > > bhar_map;
>
> sure, but it isn't "symmetric" :-) -- as most various suggestions you
> may have seen in the thread. It looks like people appreciate
> symmetries. This is syntax discussion, so like taste and colors...
>
>
So object.member isn't symmetric, should we change it too:
object[ member ] :).
I also like std::map::< std::string, std::vector< int >>, perhaps
more than map.< ... >.
If we must have symetry, no more digraphs please:
template ( < int I, typename Tuple > )
typename element_type( < I > )::type get( Tuple const &t );
some_type a = get(< 0 >)( some_tuple );
Or maybe even:
a = get( < 0 >, some_tuple );
All ADL friendly of course.
Rob.
--
http://www.victim-prime.dsl.pipex.com/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Sat, 18 Sep 2004 14:20:48 +0000 (UTC) Raw View
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> David Abrahams <dave@boost-consulting.com> writes:
>
> | Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> |
> | > llewelly <llewelly.at@xmission.dot.com> writes:
> | >
> | >
> | > [...]
> | >
> | > | If you don't like using the shift key, I think [= ... =] is an alternative.
> | > Or (% ... %). Let's see
> | >
> | > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> | >
> | > No taker? %-p
> |
> | Wouldn't changing the opening delimiter be enough to remove the
> | ambiguity?
> |
> | std::map.<std::string,list.<vector.<int> > > bhar_map;
>
> sure, but it isn't "symmetric" :-) -- as most various suggestions you may
> have seen in the thread. It looks like people appreciate symmetries.
> This is syntax discussion, so like taste and colors...
Yes. And my taste runs to something that disturbs the existing look
of programs as little as possible. All the other options introduce so
much syntactic noise that I would hate to read templates in code. FWIW.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Martin Eisenberg <martin.eisenbergNOS@PAMudo.edu>
Date: Sat, 18 Sep 2004 14:20:48 +0000 (UTC) Raw View
Andrei Alexandrescu (See Website for Email) wrote:
> "John Torjo" <jtorjo@yahoo.com> wrote in message
>> (anything is better than typing '|' - which I actually need to
>> do with my left-most finger on the left hang ;))
>
> But this whole discussion is missing the point. The bottleneck
> in writing code is definitely not the speed with which the
> programmer types. The code should be readable to people and make
> sense to the compiler.
I think the discussion is about ergonomics. Speed is not necessarily
a goal there, although ergonomic design does often lead to swift
operation.
--
Quidquid latine dictum sit, altum viditur.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Eric Backus <eric_backus@alum.mit.edu>
Date: Sun, 19 Sep 2004 22:54:40 +0000 (UTC) Raw View
"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409162318.4cc59387@posting.google.com...
> Lets see what we have now:
>
> // existing
> map< std::string,list<vector<int> > > m;
>
> // possible
> map<| std::string,list<|vector<|int|> |> |> m; // 1
> map<% std::string,list<%vector<%int%> %> %> m; // 2
> map<^ std::string,list<^vector<^int^> ^> ^> m; // 3
>
> map</ std::string,list</vector</int/> /> /> m; // 4
>
> Unfortunately, the one I love most (4) has been proved to be
> impossible.
> So, I would vote for 3.
Well, from a purely human-readability point of view, none of those are all
that great, but I'd have to say that the existing syntax is by far the
cleanest and easiest to read. Given that computer parsing will just keep
getting faster, I'd argue that human readability should be a very important
factor in deciding what to do here.
--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-356-6010 Tel
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: "Daniel R. James" <daniel@calamity.org.uk>
Date: Sun, 19 Sep 2004 22:54:41 +0000 (UTC) Raw View
John Torjo wrote:
> David Abrahams <dave@boost-consulting.com> wrote in message news:<uhdpzmusk.fsf@boost-consulting.com>...
>>Wouldn't changing the opening delimiter be enough to remove the
>>ambiguity?
>>
>> std::map.<std::string,list.<vector.<int> > > bhar_map;
>
>
> That seems like a good ide.
> but I'm not sure "." would be a good opening delimiter:
>
> Expressions like:
> "1.<int(2)" are valid nowadays.
>
> Thus, the parsing would end up being context sensitive again - which
> sets us back to square one...
When the tokeniser encounters the point it would know that it was
reading a number, so it would find the tokens:
'1.' '<' 'int' '(' '2' ')'
Daniel
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Sun, 19 Sep 2004 23:03:09 +0000 (UTC) Raw View
jtorjo@yahoo.com (John Torjo) writes:
> David Abrahams <dave@boost-consulting.com> wrote in message news:<uhdpzmusk.fsf@boost-consulting.com>...
>> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
>>
>> > llewelly <llewelly.at@xmission.dot.com> writes:
>> >
>> >
>> > [...]
>> >
>> > | If you don't like using the shift key, I think [= ... =] is an alternative.
>> > Or (% ... %). Let's see
>> >
>> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
>> >
>> > No taker? %-p
>>
>> Wouldn't changing the opening delimiter be enough to remove the
>> ambiguity?
>>
>> std::map.<std::string,list.<vector.<int> > > bhar_map;
>
> That seems like a good ide.
> but I'm not sure "." would be a good opening delimiter:
>
> Expressions like:
> "1.<int(2)" are valid nowadays.
>
> Thus, the parsing would end up being context sensitive again - which
> sets us back to square one...
Somehow I don't think there's any danger of an identifier being
confused with a numeric literal.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Mon, 20 Sep 2004 14:48:52 +0000 (UTC) Raw View
Rob Williscroft <rtw@freenet.co.uk> writes:
| Gabriel Dos Reis wrote in news:m3fz5hkd04.fsf@merlin.cs.tamu.edu in
| comp.lang.c++.moderated:
|
| >| Wouldn't changing the opening delimiter be enough to remove the
| >| ambiguity?
| >|
| >| std::map.<std::string,list.<vector.<int> > > bhar_map;
| >
| > sure, but it isn't "symmetric" :-) -- as most various suggestions you
| > may have seen in the thread. It looks like people appreciate
| > symmetries. This is syntax discussion, so like taste and colors...
| >
| >
|
| So object.member isn't symmetric, should we change it too:
|
| object[ member ] :).
Good suggestion! :-)
Some languages like Aldor
http://www.aldor.org/
have taken it to the point where member selection is written just
object(member)
like function application and the member selection notation
f.m
is nothing but function application
f(m)
[...]
| Or maybe even:
|
| a = get( < 0 >, some_tuple );
|
| All ADL friendly of course.
:-)
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Mon, 20 Sep 2004 19:33:42 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message
news:<uhdpzmusk.fsf@boost-consulting.com>...
> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> > llewelly <llewelly.at@xmission.dot.com> writes:
> > [...]
> > | If you don't like using the shift key, I think [= ... =] is an
> > | alternative.
> > Or (% ... %). Let's see
> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> > No taker? %-p
> Wouldn't changing the opening delimiter be enough to remove the
> ambiguity?
> std::map.<std::string,list.<vector.<int> > > bhar_map;
I don't think so:
template< bool B > class T {} ;
T.< 1 > 2 > tFalse ;
--
James Kanze GABI Software http://www.gabi-soft.fr
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! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Tue, 21 Sep 2004 16:30:28 +0000 (UTC) Raw View
kanze@gabi-soft.fr writes:
> David Abrahams <dave@boost-consulting.com> wrote in message
> news:<uhdpzmusk.fsf@boost-consulting.com>...
>> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
>
>> > llewelly <llewelly.at@xmission.dot.com> writes:
>
>> > [...]
>
>> > | If you don't like using the shift key, I think [= ... =] is an
>> > | alternative.
>> > Or (% ... %). Let's see
>
>> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
>
>> > No taker? %-p
>
>> Wouldn't changing the opening delimiter be enough to remove the
>> ambiguity?
>
>> std::map.<std::string,list.<vector.<int> > > bhar_map;
>
> I don't think so:
>
> template< bool B > class T {} ;
>
> T.< 1 > 2 > tFalse ;
There's no ambiguity here AFAICT. I assume you're asking whether the
first or second ">" closes the template specialization? You can't
put a template specialization next to an integer literal, so it's
pretty clear to me that the second ">" has to be the one that closes
the template.
Note: I didn't claim the grammar would be LALR(1), though I think
this case actually can be parsed with an LALR(1) grammar.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Tue, 21 Sep 2004 16:30:28 +0000 (UTC) Raw View
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote
> David Abrahams <dave@boost-consulting.com> writes:
> | Wouldn't changing the opening delimiter be enough to remove the
> | ambiguity?
> |
> | std::map.<std::string,list.<vector.<int> > > bhar_map;
>
> sure, but it isn't "symmetric" :-) -- as most various suggestions you may
> have seen in the thread. It looks like people appreciate symmetries.
> This is syntax discussion, so like taste and colors...
So add some periods to make it symmetric!
std::vector.<int>. vec;
std::map.<std::string,list.<vector.<int>.>.>.bhar_map;
Might be a problem with decimal points after >, though:
// I want this to mean foo .< true >. f_true, but does it?
foo.<1.5>.5>. f_true;
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: "Andrei Alexandrescu (See Website for Email)"
Date: Tue, 21 Sep 2004 16:30:28 +0000 (UTC) Raw View
"Eric Backus" <eric_backus@alum.mit.edu> wrote in message
news:1095447210.171540@cswreg.cos.agilent.com...
> Well, from a purely human-readability point of view, none of those are all
> that great, but I'd have to say that the existing syntax is by far the
> cleanest and easiest to read. Given that computer parsing will just keep
> getting faster, I'd argue that human readability should be a very
> important
> factor in deciding what to do here.
I'd agree with that; however, it's not only about compilation speed, but
also about learning how to write and use templates properly (few C++
programmers know that "obj.template Foo<int>(bar)" is actually valid syntax
etc.) and how to bring human expectations in line with compiler
expectations.
Second, human readability has a lot to do with habit. We've been using the
<> syntax for quite a while now so any other syntax would have an uphill
battle to fight.
Again, we do need a good solution for parting with past mistakes and
embracing the right ways of doing things. I think that's the only way C++
can continue thriving.
One solution would be to allow for an alternate solid syntax that can be
used in places where otherwise ambiguity would arise; that way, if you want
vector<T>, no problem, but if you want "obj.template Foo<int>(bar)" you can
write "obj.Foo<|int|>(bar)" or whatever. If the new syntax is carefully
chosen, more and more programmers will prefer it and use it in lieu of the
old one.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: andy@servocomm.freeserve.co.uk (kwikius)
Date: Tue, 21 Sep 2004 16:30:28 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<uu0twwtgt.fsf@boost-consulting.com>...
> jtorjo@yahoo.com (John Torjo) writes:
>
> > David Abrahams <dave@boost-consulting.com> wrote in message news:<uhdpzmusk.fsf@boost-consulting.com>...
> >> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> >>
> >> > llewelly <llewelly.at@xmission.dot.com> writes:
> >> >
> >> >
> >> > [...]
> >> >
> >> > | If you don't like using the shift key, I think [= ... =] is an alternative.
> >> > Or (% ... %). Let's see
> >> >
> >> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> >> >
> >> > No taker? %-p
> >>
> >> Wouldn't changing the opening delimiter be enough to remove the
> >> ambiguity?
> >>
> >> std::map.<std::string,list.<vector.<int> > > bhar_map;
> >
> > That seems like a good ide.
> > but I'm not sure "." would be a good opening delimiter:
> >
> > Expressions like:
> > "1.<int(2)" are valid nowadays.
> >
> > Thus, the parsing would end up being context sensitive again - which
> > sets us back to square one...
>
> Somehow I don't think there's any danger of an identifier being
> confused with a numeric literal.
I personally like the opening delimiter only approach.( The closing
delimiter is unnecessary. No benefit to programmer or compiler.)
Referring to previous threads the (< xxx>) approach I looked at but is
too confusing to read IMO, getting confused with functions and so on.
Combining the opening delimiter with the template keyword appeals to
me
hence myFunc template::<2>(x);
Here template:: is used to mean "the following is a template scope
token".
could also be used to dismbiguate between template parameter names and
base class names. ie prefixing a name with template::T means this is a
template parameter name.
It is designed for use only where necessary, ie I am not proprosing to
change current use except where disambiguation is necessary.
regards
Andy Little
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Wed, 15 Sep 2004 14:34:17 +0000 (UTC) Raw View
llewelly <llewelly.at@xmission.dot.com> writes:
[...]
| If you don't like using the shift key, I think [= ... =] is an alternative.
Or (% ... %). Let's see
std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
No taker? %-p
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: jtorjo@yahoo.com (John Torjo)
Date: Wed, 15 Sep 2004 14:34:18 +0000 (UTC) Raw View
llewelly <llewelly.at@xmission.dot.com> wrote in message news:<86brgbvsuc.fsf@Zorthluthik.local.bar>...
> jtorjo@yahoo.com (John Torjo) writes:
>
> > Eric Backus <eric_backus@alum.mit.edu> wrote in message news:<1094582026.849711@cswreg.cos.agilent.com>...
> > > "John Torjo" <jtorjo@yahoo.com> wrote in message
> > > news:c638aac5.0409062202.5ef631b2@posting.google.com...
> > > > Since we're all used to <>, how about using </ and />
> > > > (or, somebody else suggested <| and |> - although I think </ and />
> > > > are much faster to type)
> > > >
> > > > I think it's not possible to have </ and /> in the current language,
> > > > so this wouldn't break anything.
> > >
> > > How about an explicit specialization:
> > >
> > > template</*intentionally_empty*/> int my_max<int>(int x1, int x2) {
> > > return (x1 > x2) ? x1 : x2; }
> > >
> > > Or, possibly some case of template deduction?:
> > >
> > > x = func</*intentionally_empty*/>(arg1, arg2);
> > >
> >
> > Man, you got me here.
> > Although probably noone wrote such a thing,
>
> I've written such things in examples explaining explicit
> specialization, and in examples explaining how to force the use
> of a function template over a non-template function. I don't
> think I've written such things in real code, but I think it's
> important to avoid breaking pedagogical examples as well.
>
> > you're right.
> >
> > Of course, the compiler can be smart and see if it encounters </* or
> > */> and treat /* as comments.
> >
> > Or, we can use <| and |>
> > Now, find a broken construct using <| |> !
> > (although, again, I'm pretty against this, since | is very complicated
> > to type - for me)
>
> All you need to do is find an easier to type char which can
> (currently) never follow < or precede > and you can suggest an
> alternative. I think '%' and '^' qualify; does anyone find
> <% ... %> or <^ ... ^> particularly appealing or particularly
> objectionable? (Unfortunately, I doubt either is any less
> difficult to type ...)
>
Now that I come think of it,
I like much better:
<% %>.
Even <$ $> maybe...
(anything is better than typing '|' - which I actually need to do with
my left-most finger on the left hang ;))
Best,
John
John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
+ easily add validation rules (win32gui/examples/smart_dlg)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: "Andrei Alexandrescu (See Website for Email)"
Date: Thu, 16 Sep 2004 15:14:39 +0000 (UTC) Raw View
"John Torjo" <jtorjo@yahoo.com> wrote in message
> Now that I come think of it,
> I like much better:
>
> <% %>.
> Even <$ $> maybe...
>
> (anything is better than typing '|' - which I actually need to do with
> my left-most finger on the left hang ;))
But this whole discussion is missing the point. The bottleneck in writing
code is definitely not the speed with which the programmer types. The code
should be readable to people and make sense to the compiler.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: usenet_cpp@lehrerfamily.com (Joshua Lehrer)
Date: Thu, 16 Sep 2004 15:14:39 +0000 (UTC) Raw View
jtorjo@yahoo.com (John Torjo) wrote in message news:<c638aac5.0409132242.7ac03619@posting.google.com>...
> Now that I come think of it,
> I like much better:
>
> <% %>.
> Even <$ $> maybe...
>
> (anything is better than typing '|' - which I actually need to do with
> my left-most finger on the left hang ;))
>
> Best,
> John
I know that a '$' is not allowed as part of an identifier under strict
ansi rules. However, there are legacy platforms (VMS) where some
values and/or identifiers begin with a dollar sign. Thus, "<$OK"
could either mean "is less than the value '$OK'" or it could be the
beginning of a template declaration.
As long as we are looking to disambguiate, we might as well take this
into consideration.
joshua lehrer
factset research systems
NYSE:FDS
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Thu, 16 Sep 2004 15:14:39 +0000 (UTC) Raw View
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
> llewelly <llewelly.at@xmission.dot.com> writes:
>
>
> [...]
>
> | If you don't like using the shift key, I think [= ... =] is an alternative.
> Or (% ... %). Let's see
>
> std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
>
> No taker? %-p
Wouldn't changing the opening delimiter be enough to remove the
ambiguity?
std::map.<std::string,list.<vector.<int> > > bhar_map;
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Fri, 17 Sep 2004 15:29:56 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| > llewelly <llewelly.at@xmission.dot.com> writes:
| >
| >
| > [...]
| >
| > | If you don't like using the shift key, I think [= ... =] is an alternative.
| > Or (% ... %). Let's see
| >
| > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
| >
| > No taker? %-p
|
| Wouldn't changing the opening delimiter be enough to remove the
| ambiguity?
|
| std::map.<std::string,list.<vector.<int> > > bhar_map;
sure, but it isn't "symmetric" :-) -- as most various suggestions you may
have seen in the thread. It looks like people appreciate symmetries.
This is syntax discussion, so like taste and colors...
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Thorsten Ottosen <nesotto@cs.auc.dk>
Date: Fri, 17 Sep 2004 15:29:56 +0000 (UTC) Raw View
"Andrei Alexandrescu (See Website for Email)"
<SeeWebsiteForEmail@moderncppdesign.com> wrote in message
news:2qrl1eF13bvm1U1@uni-berlin.de...
|
| "John Torjo" <jtorjo@yahoo.com> wrote in message
| > Now that I come think of it,
| > I like much better:
| >
| > <% %>.
| > Even <$ $> maybe...
| >
| > (anything is better than typing '|' - which I actually need to do with
| > my left-most finger on the left hang ;))
|
| But this whole discussion is missing the point. The bottleneck in writing
| code is definitely not the speed with which the programmer types.
True. It is the speed of the programmer's brain.
br
Thorsten
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Fri, 17 Sep 2004 17:29:34 +0000 (UTC) Raw View
"Andrei Alexandrescu (See Website for Email)"
<SeeWebsiteForEmail@moderncppdesign.com> wrote in message
news:<2qrl1eF13bvm1U1@uni-berlin.de>...
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> > Now that I come think of it,
> > I like much better:
> > <% %>.
> > Even <$ $> maybe...
> > (anything is better than typing '|' - which I actually need to do
> > with my left-most finger on the left hang ;))
> But this whole discussion is missing the point. The bottleneck in
> writing code is definitely not the speed with which the programmer
> types. The code should be readable to people and make sense to the
> compiler.
That depends on the code, and what you are doing. For some boilerpla=
te
code, the bottleneck is typing speed.
But I don't think that that was the point. Constantly extending the
little finger further than it was meant to be can result in carpal
tunnel syndrome, or something along those lines. (Of course, twistin=
g
the hand to simultaneously type AltGr and 6 is even worse.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, 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! ]
[ comp.std.c++ is moderated. To submit articles, try just posting wi=
th ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu =
]
[ --- Please see the FAQ before posting. --- =
]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html =
]
Author: jtorjo@yahoo.com (John Torjo)
Date: Fri, 17 Sep 2004 17:29:34 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<uhdpzmusk.fsf@boost-consulting.com>...
> Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
>
> > llewelly <llewelly.at@xmission.dot.com> writes:
> >
> >
> > [...]
> >
> > | If you don't like using the shift key, I think [= ... =] is an alternative.
> > Or (% ... %). Let's see
> >
> > std::map(%std::string,list(%vector(%int%)%)%) bhar_map;
> >
> > No taker? %-p
>
> Wouldn't changing the opening delimiter be enough to remove the
> ambiguity?
>
> std::map.<std::string,list.<vector.<int> > > bhar_map;
That seems like a good ide.
but I'm not sure "." would be a good opening delimiter:
Expressions like:
"1.<int(2)" are valid nowadays.
Thus, the parsing would end up being context sensitive again - which
sets us back to square one...
Best,
John
John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
+ easily add validation rules (win32gui/examples/smart_dlg)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: jtorjo@yahoo.com (John Torjo)
Date: Fri, 17 Sep 2004 17:30:52 +0000 (UTC) Raw View
"Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:<2qrl1eF13bvm1U1@uni-berlin.de>...
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> > Now that I come think of it,
> > I like much better:
> >
> > <% %>.
> > Even <$ $> maybe...
> >
> > (anything is better than typing '|' - which I actually need to do with
> > my left-most finger on the left hang ;))
>
> But this whole discussion is missing the point. The bottleneck in writing
> code is definitely not the speed with which the programmer types. The code
> should be readable to people and make sense to the compiler.
>
Shamefully agree...
Lets see what we have now:
// existing
map< std::string,list<vector<int> > > m;
// possible
map<| std::string,list<|vector<|int|> |> |> m; // 1
map<% std::string,list<%vector<%int%> %> %> m; // 2
map<^ std::string,list<^vector<^int^> ^> ^> m; // 3
map</ std::string,list</vector</int/> /> /> m; // 4
Unfortunately, the one I love most (4) has been proved to be
impossible.
So, I would vote for 3.
<side-note>
Even though 4. would be possible to implement by some
context-sensitive parsing - that would bring us back to square one -
what we have today.
</side-note>
Best,
John
John Torjo, Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4 - true binding of your data to UI controls!
+ easily add validation rules (win32gui/examples/smart_dlg)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly <llewelly.at@xmission.dot.com>
Date: Mon, 13 Sep 2004 22:47:09 +0000 (UTC) Raw View
jtorjo@yahoo.com (John Torjo) writes:
> Eric Backus <eric_backus@alum.mit.edu> wrote in message news:<1094582026.849711@cswreg.cos.agilent.com>...
> > "John Torjo" <jtorjo@yahoo.com> wrote in message
> > news:c638aac5.0409062202.5ef631b2@posting.google.com...
> > > Since we're all used to <>, how about using </ and />
> > > (or, somebody else suggested <| and |> - although I think </ and />
> > > are much faster to type)
> > >
> > > I think it's not possible to have </ and /> in the current language,
> > > so this wouldn't break anything.
> >
> > How about an explicit specialization:
> >
> > template</*intentionally_empty*/> int my_max<int>(int x1, int x2) {
> > return (x1 > x2) ? x1 : x2; }
> >
> > Or, possibly some case of template deduction?:
> >
> > x = func</*intentionally_empty*/>(arg1, arg2);
> >
>
> Man, you got me here.
> Although probably noone wrote such a thing,
I've written such things in examples explaining explicit
specialization, and in examples explaining how to force the use
of a function template over a non-template function. I don't
think I've written such things in real code, but I think it's
important to avoid breaking pedagogical examples as well.
> you're right.
>
> Of course, the compiler can be smart and see if it encounters </* or
> */> and treat /* as comments.
>
> Or, we can use <| and |>
> Now, find a broken construct using <| |> !
> (although, again, I'm pretty against this, since | is very complicated
> to type - for me)
All you need to do is find an easier to type char which can
(currently) never follow < or precede > and you can suggest an
alternative. I think '%' and '^' qualify; does anyone find
<% ... %> or <^ ... ^> particularly appealing or particularly
objectionable? (Unfortunately, I doubt either is any less
difficult to type ...)
If you don't like using the shift key, I think [= ... =] is an alternative.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly <llewelly.at@xmission.dot.com>
Date: Mon, 13 Sep 2004 22:50:58 +0000 (UTC) Raw View
Thorsten Ottosen <nesotto@cs.auc.dk> writes:
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> news:c638aac5.0409072109.5e8195f6@posting.google.com...
> |
> | Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message
> news:<chkira$peq$1@news1nwk.SFbay.Sun.COM>...
>
> | > Today we have more serious problems with template syntax than we did
> | > in 1992. I think that if explicit template arguments on function calls
> | > had been part of C++ in 1992, we would have changed the notation then.
> | >
> |
> | That's why I (and probably Andrei) think it's quite imperative to
> | change this.
> | We could still allow for the old syntax (with a warning), create some
> | automation tools (for updating files from old to new syntax) and allow
> | for a newer/cleaner/easier to parse solution.
>
> If the only reason is faster parsing speed, then I don't see why one should
> change anything. Time
> is working to our advantage...the next time I buy a lap-top it will be 4 times
> as fast;
[snip]
And you will in all likelyhood find that current software will take
about the same amount of time to build as software that was
current when you bought the older laptop.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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.jamesd.demon.co.uk/csc/faq.html ]