noicys@hotmail.com ("Ioannis Vranos") wrote in
news:1043116224.91905@athprx02:

> ""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
> news:v2os3tccqt9cf5@corp.supernews.com...
>>
>> So, drop the 'of', replace the parentheses with angle brackets...
>>
>> It makes less and less sense every day I read about it.  What is
>> the purpose of making a programming language constructs look more
>> like a natural language statements?  Are they easier to understand
>> that way?  I do not think so.  Why do we have the diameter symbol?
>> The sum symbol (sigma)?  The plus, etc.?  They mean the same thing
>> for people whose "normal" communication language is not necessarily
>> English.  Who will benefit from your proposal?  English-speaking
>> newbies.  What about those whose mother tongue is not English?  The
>> fewer keywords they need to learn the better.  Often they don't
>> know the meaning (or the translation) of the keyword outside the
>> context of a computer program.  That's not a bad thing.
>>
>> Is there any benefit of what you propose beyond making it simpler
>> for those who are just starting to learn C++?  Isn't your suggestion
>> similar to one about replacing curly braces with "begin" and "end"
>> (or "begin_compound_statement" and "end_compound_statement")?  What
>> about replacing the asterisk with "times" when it's a multiplication
>> and with "deref" when it's a dereference?
>
>
> I hate begin - end and i do not like Pascal. :) Anyway what i am
> saying is that if the template syntax does not get improved newcomers
> will always begin with
>
>
> int *p=new int[10];
>
> stuff instead of the standard containers. Failure to recognise this
> will never allow templates to take off.
>
>

Hello
I was a newbee once 4 years back and have taken off. Learn't c++ by self
reading only. My second project in corporate world was using STL as much
as we could in VC++6.0 compiler.

Have you spoken to enough newbees to make that assertion.

kanad

---
[ 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                       ]

After an email discussion i had with Terje Slettebo (and i am thanking him
for this) i realised that my syntax suggestion is broken. More specifically,
when the passed template arguments end is ambiguous.

Therefore, i formally withdraw my suggestion (not that it matters, but i
want to be typical :) ).



Keep coding,

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote in message
news:<YaxXQyYbMQO+Ewzz@robinton.demon.co.uk>...
> In article <9e3a34f7.0301290139.65acc951@posting.google.com>, Terje
> Sletteb  <"terjes."@chello.no> writes
> >Nevertheless, it may be better to allow ">>" for closing templates,
> >and making the above ambiguous. The ambiguity could be solved with
> >parenthesis, anyway:

> >test<function<(value >> 1)>> test;

> I like this idea. It makes the unusual (pathological) case the one
> that requires active resolution by the programmer. However I think we
> would need a rule that says that if '>>' can be a double closure (i.e.
> we are already at least two deep in template '<') it is a one. That
> leaves me a little less happy but only a little. I do not think this
> would have the same unfortunate repercussions that we have with
> declarations versus definitions.

I think this parallels the situation that we already have with >.  In
something like:

    template< bool i > T {} ;

    T< 1 > 2 > t ;

The first > is interpreted as closing the template parameter list, even
though this interpretation results in a syntax error, whereas
interpreting it as greater than wouldn't.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

In article <3E372391.B00D90EA@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Andrew Koenig wrote:
>>
>> The only reason I know that the committee didn't treat >> this way in
>> the standard is that we didn't think of it in time.
>>
>
>template<int i>
>class C {};
>
>vector<C<3>>1> >;
>
>This requires potentially infinite lookahead to determine whether the >>
>is a shift or a template terminator.

And this is one of the cases where theory and practice are vastly at
variance. It requires look ahead to the first semicolon. In practice
that would not be far.

BTW there is a difference between infinite and finite but unbounded.

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

After looking at Andrew's suggested grammer I think I've come up with
some standard C++ code that could detect this change.

How it works is left as an exercise.
-----------------------------------
#include <iostream>

enum { D,E,H };
template <typename a>
struct A {
  template <int d>
  struct D {
    enum { F };
  };
};
template <int b>
struct B {
  struct F {
    bool operator>(int) { return true; }
  };
};

char const* tester(int x) {
  return "Purposed style";
}

template <typename a>
char const* tester(A<a> const&) {
  return "Existing style";
}

int main() {
  A<B<5>>::D<E>::F>H;

  std::cout << "Template parameter parsing is: " << tester(H) <<
std::endl;
}
-----------------------------------
You can test it by replacing:
  A<B<5>>::D<E>::F>H;
With
  A<B<5> >::D<E>::F>H;

Andrew Koenig wrote:
> Hmmm, you're right.  But I can see how to solve this problem also.
> It's analogous to how the grammar allows , to be used both as an
> operator and as an argument separator.
>
... grammar omitted
>
> I've written the whole thing out to show the magnitude of the change:
> nontrivial but not overwlelming.  The basic idea is that a
> ta-assignment-expression is just like an assignment expression
> except that it cannot contain the > or >> symbols at top level
> (because I've removed them from the grammar, unless they are part
> of an additive-expression, in which case they would have to be
> parenthesized).
>
> This grammar change would also get rid of the verbal disambiguation
> rule in subclause 14.2, paragraph 5, that allows the compiler to
> reject T<3>4>.

---
[ 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                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:DNBhVWIUezN+EwYF@robinton.demon.co.uk...
>
> No they did that as the only acceptable way to avoid breaking vast
> amounts of existing source code. You never have to spell bool as _Bool
> because you just include bool.h, but equally well your existing legacy
> code will never be broken because it does not include bool.h and could
> never legitimately have used _Bool.


As you know in C99 size_t remains a typedef defined in stddef.h. However it
can be a typedef of an "exotic type" since it can be larger than the
provided built in types which is really unwise.

Well complex etc extensions could only be provided as typedefs of exotic
types, the same way as size_t is. So as they do in C99:

#include <stddef.h>
#include <stdio.h>

// ...

size_t s=7;

// ...

printf("%sz\n", s);


They could do:

#include <complex.h>


complex s=7*i;  // or something, i do not know how they use the type


All built in type extensions were not needed too. If they wanted larger
types than the provided ones (which are sufficient since in most cases one
type equals with the other e.g. int is the same with long, and it 64-bit
systems they could be separated) they could provide them *only* as typedefs
of exotic types, like they do with int64_t etc. In summary i consider the
C99 stanndard unwise and i believe C++ must break its relations with C99.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Terje Sletteb=F8" <"terjes."@chello.no> wrote in message
news:9e3a34f7.0301290328.4ffe6cd7@posting.google.com...
>
> I've read this whole thread, now, and you keep saying this, yet most
> people in this thread are disagreeing with you in this issue. This
> shows that what is readable is clearly very subjective. Thus "No
> question about that" is plain wrong. Maybe no question about it for
> you (although we'll get to that, as well, below here), but certainly a
> question for many others, and most answers regarding the question of
> the proposal being easier to read, both from experienced people, and
> testemonials from beginners, is "No, it makes it harder to read". That
> includes me.


Ok. I have realised that others disagree with me, that's why i really do =
not
expect it to be proposed, but i keep discussing it (why not?).



> Why should a word make it easier to read? Plain vector<int> says it
> all for me. I like the way C++ uses symbols, rather than a lot of
> words (like Pascal). You say you don't like Pascal, yet this is
> definitely Pascal-like.


Yes words are really stupid, but i think an "of" for templates would make
things easier for newcomers.




> If words, rather than symbols, were easier to read, then, as someone
> pointed out, something like "result assign 1 plus 2" should be easier
> to read than "value=3D1+2", no? If no, then what makes templates
> different in this respect? Templates nicely mirrors function calls,
> and uses the idiom of passing parameters to something:
>
> function<A,B>
> function(A,B)
>
> With your proposal, this is:
>
> function of A,B
> function(A,B)
>
> even though the template and the function might do the same thing!


They differ with the current syntax too (i did not get what you mean).




> "Express coordinate ideas in similar form" - Strunk & White, "The
> Elements of Style".
>
> Your proposal breaks with this symmetry and intuitiveness, and would
> likely make the language _harder_ to learn and use, not easier.


Ok. You may be right, i do not know. But i find it simpler. But i 'll not
keep insisting on my suggested syntax anymore.



> I think the fundamental problem in your proposal is that you think of
> templates only in terms of containers of T. Templates are much more
> than this. They are about being able to pass compile-time arguments to
> entities, just like you can pass run-time arguments to entities.
>
> Using "of" even breaks down at the level of containers of T, and it
> gets progressively worse, for more complex use, which is quite
> mainstream. This has been said again and again, but you don't seem to
> take notice of it.
>
> Let me show you some examples. Let's take Boost's type traits
> (http://www.boost.org/libs/type_traits/index.htm):
>
> is_void of int.
>
> Huh? "Still confused? You won't be after this episode..."
>
> The above doesn't ask if something is a void of int (which is
> meaningless), but it means is_void<int> (is int void), and the answer
> is no (false). This is an example of a compile-time function, and it's
> analoguous to run-time functions: sqrt<value>, sqrt(value).


The is_void stuff is a name given by the implementors of the facility. Th=
at
name could change, it doesn't mean anything for of.


>
> But it gets worse:
>
> add_pointer of int.
>
> Does this mean to add a pointer of int? It looks that way. Given that
> the proposal is meant to make it intuitively easier to understand, it
> seems your proposal has the opposite effect of the intended, because
> what the above really means is add_pointer<int>, which creates the
> type int *.


I am not confused by the meaning, but anyway.





> Authors of metaprogramming libraries would "love" your proposal. This
> point was brought up earlier, several times, but you seemed to miss
> it. How about this (using Boost.MPL):
>
> if_ of less (of A,B), C, D)


if_ of less of (A,B), C,D

or

if_ of (less of (A,B), C,D)


>
> Sorry, but this is plain rubbish. The above is your version of this:
>
> if_<less<A,B>,C,D>
>
> which means if(A<B) C else D;
>
> In short, as have been said many times in this thread, "of" is often
> not appropriate for templates.


OK, it may be this case. I 'll not discuss the new syntax issue anymore.



> Your argument is that it would make it easier to learn, and also
> perhaps easier for experienced ones. Yet, the feedback from people in
> this thread, both experienced people, and testemonials from
> experienced C++ educators, says that neither experienced nor beginners
> find the new syntax easier to use or learn, rather the contrary.
>
> As has been pointed out, the lack of knowledge of templates and STL is
> due to education, and some insisting of teaching the C-first way (and
> perhaps never getting to STL), rather than the syntax.


OK. Thanks for your comments. Since most people apprently disagree i 'll
leave this issue.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

> > It is also ambiguous: Does it mean
> >
> >         map <basic_string<char>, basic_string<char> > m;
> >
>
> It means the above. It could also be written:
>
>
> map of (basic_string of char, basic_string of char) m;
>
>
> In reality iy would be written:
>
> map of string,string m;

Would it really? By that criterion

map <basic_string<char>, basic_string<char> > m;
map <basic_string<wchar_t>, basic_string<wchar_t> > m;

would both be written

map of string,string m;

by your last statement which is ambiguity again.

> The only difference with the current style is that the  <> pairs are
> replaced with "of". This is simple but it is a lot nicer and far more
> comprehensible:

Just assertion. Please state in _OBJECTIVE_ terms how it is "nicer" or
"comprehensible" or "easier".

> vector of map of int,float vm;
>
> or vector of (map of int,float) m;
>
> Parenthesis can be ignored by the compiler, nor they can change the
> precedence.

Oh for pities sake!!! C++ compilers don't ignore parentheses in other part
of the language, in fact if you have the syntax wrong, compilers issue a
diagnostic. This policy on your part on the hoof.

1) Why should compilers ignore parentheses for your notation?
2) If they can be ignored, then the last statement could be written

vector of map of int,float m;

3) If parentheses are necessary to prevent ambiguity in your syntax, under
what circumstances should the compiler not ignore them?

Stephen Howe


---
[ 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                       ]

Ioannis Vranos wrote:
>
> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> news:wNytluIYjzN+Ew$X@robinton.demon.co.uk...
> >
> > Do you have any idea about what syntax is? Names such as _Complex are
> > ugly but they do not get near to breaking syntax.
>
> Imagine a new C99 user to get confused between int x; and _Complex y;
> syntax. He will not be reembering when to type _Camel x; and when to type
> nocamel y;
>
> It's a mess.

OT, but _Complex itself doesn't constitute a type.
"There are three complex types, designated as float _Complex,
double _Complex, and long double _Complex." (C99 6.2.5/11)

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

Pete> template<int i>
Pete> class C {};

Pete> vector<C<3>>1> >;

Pete> This requires potentially infinite lookahead to determine whether the >>
Pete> is a shift or a template terminator.

Yes it does, as does

        vector<C<3>(42)> v;

today.  We resolve this problem by using the disambiguation rule in
subclause 14.2, paragraph 5, which says that a > that can be paired
with a < that is an opening template-argument bracket is so paired
rather than treating it as a relational operator.

We could extend that rule to say how to interpret >> as well.
Alternatively, we could rewrite the grammar along the lines of my
(second) suggestion in this newsgroup, which would make the
disambiguation rule unnecessary for either case by absorbing it into
the grammar.


--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                       ]

In article <3E394001.E7EDCD2C@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Francis Glassborow wrote:
>>
>> And I think that neatly answers Pete Becker's response to one of my
>> posts. If rewriting the grammar can solve the problem, compiler
>> technology can certainly manage it.
>>
>
>Actually, I said that compiler technology is irrelevant. Grammar changes
>are also irrelevant. The question simply is: what do we think the
>character sequence '>>' should mean? We deliberately decided that it
>meant only shift right, just as it does in C. This was not because we
>didn't think it was possible to change the grammar to give it an
>additional meaning, nor was it because we didn't think that it was
>possible for compilers to implement such a change. We decided that it
>wasn't desirable.

That is not the way I remember the decision. Had the current ideas been
on the table then I would definitely have wanted them instead of what we
have now.

I will go one step further and say that in this case I would want the
change even at the cost of noisy breakage of some existing code (I would
be interested to know of any real cases where the right-shift operator
is used in an expression that produces an argument for a template
parameter)


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in
news:1043778213.540779@athprx02:
>
> vector of int::iterator p;
>
> or
>
> vector of (int)::iterator p;
>
> or
>
> (vector of int)::iterator p;
>
>
> But personally i would not use the parenthesis for such simple case.
>
To my mind, the absolute killer argument against this proposal is that it
assumes that templates are only ever used for collections. Indeed the whole
point of the proposal appears to be that 'foo of bar' reads "better"
because we *say* "vector of int".
Since being infected by the Alexandrescu virus, I would say that
collections are now one of my less common uses of templates. For instance
just before taking this break to read csc++. I wrote the line:
     CTAssert< implements< serializable, T > >;

Which I happen to think reads rather nicely, whereas with your syntax it
would read:
     CTAssert of implements of serializable,T

Which is plainly nonsense. Don't even suggest trying to improve it by
replacing "implements" by "implementation", because while that would make
it read slightly more fluently:
     CTAssert of implementation of serializable,T

It would also make it a _lie_, I don't care what T is an implementation of,
merely that it implements serializable. [Note it doesn't derive from
serializable, just implements it].

Dan "abstract_factory *for* critical_postings" Smart
--
Dan Smart. C++ Programming and Mentoring.
cppdan@dansmart.com
ADDvantaged

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043815309.188076@athprx02>...
> "Bob Bell" <belvis@pacbell.net> wrote in message
> news:c87c1cfb.0301281238.5875e6da@posting.google.com...
> > noicys@hotmail.com ("Ioannis Vranos") wrote in message
>  news:<1043727222.367166@athprx02>...
> > > I am sorry but this excuse that a certain keyword may be used as an
> > > identifier in old code cannot be serious.
> >
> > Why not? How would you address the problem? If you know how to
> > introduce a keyword without breaking old code, please let us know. I'm
> > sure the standard committe would be very interested.
> >
> > As it stands, introducing a keyword like "of" has the potential of
> > creating many (tens? hundreds?) of man-years of effort just to get
> > existing code to compile. Why do you think this is not a serious
> > problem?
>
>
> As i said a special command could be used, a #pragma, a compiler switch,
> something.

But the old code was still broken. Just because you provide a method
to deal with the broken code doesn't mean you didn't break the code in
the first place.

Again, why do you think this is not a serious problem?

Bob

---
[ 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                       ]

Daphne> After looking at Andrew's suggested grammer I think I've come up with
Daphne> some standard C++ code that could detect this change.

...

Daphne> You can test it by replacing:
Daphne>   A<B<5>>::D<E>::F>H;
Daphne> With
Daphne>   A<B<5> >::D<E>::F>H;

Ingenious -- but anyone who writes code like this instead of writing

        A<B<(5>>::D<E>::F)>H;

deserves whatever the compiler does :-)

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                       ]

"Dan Smart" <cppdan@dansmart.com> wrote in message
news:Xns9313994C4CD38Me@167.206.3.3...
>
> To my mind, the absolute killer argument against this proposal is that it
> assumes that templates are only ever used for collections. Indeed the
whole
> point of the proposal appears to be that 'foo of bar' reads "better"
> because we *say* "vector of int".
> Since being infected by the Alexandrescu virus, I would say that
> collections are now one of my less common uses of templates. For instance
> just before taking this break to read csc++. I wrote the line:
>     CTAssert< implements< serializable, T > >;
>
> Which I happen to think reads rather nicely, whereas with your syntax it
> would read:
>     CTAssert of implements of serializable,T
>
> Which is plainly nonsense. Don't even suggest trying to improve it by
> replacing "implements" by "implementation", because while that would make
> it read slightly more fluently:
>     CTAssert of implementation of serializable,T
>
> It would also make it a _lie_, I don't care what T is an implementation
of,
> merely that it implements serializable. [Note it doesn't derive from
> serializable, just implements it].
>
> Dan "abstract_factory *for* critical_postings" Smart


I think that


CTAssert< implements< serializable, T > >


CTAssert of implementation of serializable, T


can't have different "meaning".


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0301301359.29b36133@posting.google.com...
>
> But the old code was still broken. Just because you provide a method
> to deal with the broken code doesn't mean you didn't break the code in
> the first place.
>
> Again, why do you think this is not a serious problem?


Because it can be bypassed. As i said no new keyword/feature can be
introduced with this logic, because someone, somewhere may use that keyword.
And i do not want to hear about _Camel solutions. :)



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Ioannis Vranos wrote:
> ""Stephen Howe"" <NOSPAMsjhowe@dial.pipex.com> wrote in message
> news:3e35cc04$0$246$cc9e4d1f@news.dial.pipex.com...
...
> I am sorry but this excuse that a certain keyword may be used as an
> identifier in old code cannot be serious. With this excuse nothing new can
> be introduced to the language since its keyword(s) may be used in old code.
> Even if we only consider new standard library facilities.

Any new keyword that is selected from the set of names that is currently
reserved to the implementation in the relevant contexts can't break any
strictly conforming code. If well chosen, it's also unlikely to break
any real code.

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1044084684.508170@athprx02>...
> "Bob Bell" <belvis@pacbell.net> wrote in message
> news:c87c1cfb.0301301359.29b36133@posting.google.com...
> >
> > But the old code was still broken. Just because you provide a method
> > to deal with the broken code doesn't mean you didn't break the code in
> > the first place.
> >
> > Again, why do you think this is not a serious problem?
>
>
> Because it can be bypassed.

(With a #define, a #pragma, or a compiler switch.)

Let me be clearer (and this will be the last time I post because I'm
getting tired of banging my head against this wall):

Why do you think the effort required to get previously working code to
work with your proposed change is not serious enough to be worth
considering?

It is self-evident to me that any proposal that requires many
thousands of programmers to "bypass" problems that didn't exist before
the proposal should have a _very_ strong justification.

> As i said no new keyword/feature can be
> introduced with this logic, because someone, somewhere may use that keyword.

No one has claimed this except you.

Bob

---
[ 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                       ]

""Stephen Howe"" <NOSPAMsjhowe@dial.pipex.com> wrote in message
news:3e386cb8$0$237$cc9e4d1f@news.dial.pipex.com...
> > >
> >
> > It means the above. It could also be written:
> >
> >
> > map of (basic_string of char, basic_string of char) m;
> >
> >
> > In reality iy would be written:
> >
> > map of string,string m;
>
> Would it really? By that criterion
>
> map <basic_string<char>, basic_string<char> > m;
> map <basic_string<wchar_t>, basic_string<wchar_t> > m;
>
> would both be written
>
> map of string,string m;
>
> by your last statement which is ambiguity again.


No.  string is typedef basic_string<char> (or typedef basic_string of char)
with the proposed syntax (however i think this is an answer to a very old
message of mine in the thread).



>
> > The only difference with the current style is that the  <> pairs are
> > replaced with "of". This is simple but it is a lot nicer and far more
> > comprehensible:
>
> Just assertion. Please state in _OBJECTIVE_ terms how it is "nicer" or
> "comprehensible" or "easier".
>
> > vector of map of int,float vm;
> >
> > or vector of (map of int,float) m;
> >
> > Parenthesis can be ignored by the compiler, nor they can change the
> > precedence.


The above has changed. Please check
http://users.forthnet.gr/ath/ivr/docs/templates.htm




--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

On Wed, 29 Jan 2003 18:54:32 +0000 (UTC), sa_schreuder@wanadoo.nl
(Sjoerd Schreuder) wrote:
>
>The root of the problem is that '<' and '>' are not always paired.
>So when the parser sees a '>', it might not be paired to a previous '<'.
>The other brackets, {} () [], are always paired and the closing bracket
>is always paired to the nearest open bracket.
>
>...
>So let's use [] as brackets for templates in stead of <>!
>No infinite lookahead, no double ']]' problem! Just
>  vector[C[3>>1]];

At the November 1992 meeting of the C++ Committee in Boston, we
seriously discussed alternative syntax for templates, because of the
>> problem, the possible confusion with greater-than or less-than, and
other reasons.

Using square brackets [ ] was discussed, but it turns out to have some
syntactic ambiguities. Curly braces { } do not introduce any problems.
New 2-character tokens like /( /) would also work.

In the end, the argument that carried the day was that too much code
and too many books existed at the time using the < > notation, and it
would be too painful to change. In addition, similar syntactic
problems exist elsewhere, such as
 x = y/*divide by z*//z;
versus
 x = y /*divide by z*/ / z;
Not that syntactic ambiguity is good, but there's a difference between
being the only ambiguity and being one of several.

In retrospect, with few compilers implementing templates in 1992,
maybe the decision wasn't such a good one.

In addition, we did not at that time have the foo<T>() notation for
function calls. The angle brackets < > create genuine parsing
problems, since you don't know how to look up associated names unless
you know whether they are template delimiters, and you don't always
know whether they are template delimiters until you look up the
associated names.  That is, given
 x < y > ( z )
the rules for looking up the name x depends on whether x is a template
name, and whether the < and > are template delimiters depends on
looking up x.

Had that function-call syntax been contemplated, we might have changed
the template syntax to use something other than angle brackets.

---
[ 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                       ]

> > Again, why do you think this is not a serious problem?
>
> Because it can be bypassed. As i said no new keyword/feature can be
> introduced with this logic, because someone, somewhere may use that
keyword.
> And i do not want to hear about _Camel solutions. :)

Yes, but a new keyword in C++ is only introduced if there is a serious
_MAJOR_ deficiency. "explicit" is an example of that due to 1 parameter
constructors being automatically used as implicit conversion operators.

But with your proposal that is not the case. Existing template syntax works
fine both for new C++ programmers and experienced C++ programmers.

In the light of that, _WHY_ should 1000's of working programs, refuse to
compile because of the addition of the keyword "of", just because you don't
like the existing C++ template syntax, a syntax that works perfectly well?
What justification is there for this?

Stephen Howe



---
[ 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                       ]

> Then what about a compiler switch /use_old_syntax_only.

Sorry this does not fly for me. You simply can't expect anyone to take your
proposal seriously if on this part of the thread you are reduced down to
pre-processor and compiler switch solutions to make your original proposal
work. The fact that you are suggesting these possibilities are evidence to
me that not enough thought was placed in the original proposal.

The standard does not depend on "compiler switch solutions" and the general
trend of C++ as a language is to minimise and eliminate preprocessor usuage
(#define replaced with proper constants and inline functions with proper
type checking).

If you want to put up a proposal, you could not do better than consider some
of the points that Bjane Stroustrup raises in Design and Evolution of C++.

Have a look at section 6.4.1 "Criteria for Extensions".

Bjarne Stroustrup then gives several examples that are good candidates for
possible extensions and then goes into the flaws of them. It is worth
reading.

Cheers

Stephen Howe





---
[ 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                       ]

> Far more obvious what a certain expression does. It makes templates more
> easy to use.

I am not convinced. Objectively, what you have right now is a mixture of
English-like syntax with keywords like "of" and at the same time parenthesis
and commas which is definitely not English-like. The fact that is neither
one thing nor the other does not convince me that it is "easy to use". Why
should newbie C++ programmers immediately grasp what the parenthesis and
commas mean?


> > 2. How worth is it? Enough to break current codes?
>
> No current code is broken. Both syntaxes remain valid. However the new
> syntax is far more comprehensible.

That is just a subjective claim. There is no evidence that that is true. If
you sat 100 C programmers who have never used C++ and asked them what they
thought various C++ decarations were in noraml tempate syntax and the
equivalent in your notation it would be interesting to score how close they
got it right.

> Fixed. The expression is evaluated linearly from left to right. If it
> doesn't suit you use parenthesis:
>
>
> type1 of type2 of type3,type4 s;
>
> equivallent to:
>
> type1<type2<type3,type4> > s;
>
>
>
> type1 of (type2 of type3),type4 s;
>
> equivallent to:
>
> type1<type2<type3 >, type4> s;

But notice you have had to "fix" it. The people in this newsgroup are C++
experts and even they pointed out flaws. If that is the case, how can you
claim that your notation is  "far more comprehensible"? The fact that you
have to fix it several times strike a blow against comprehensibilty.

Stephen Howe


---
[ 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                       ]

""Stephen Howe"" <NOSPAMsjhowe@dial.pipex.com> wrote in message
news:3e35cc04$0$246$cc9e4d1f@news.dial.pipex.com...
> > Then what about a compiler switch /use_old_syntax_only.
>
> Sorry this does not fly for me. You simply can't expect anyone to take
your
> proposal seriously if on this part of the thread you are reduced down to
> pre-processor and compiler switch solutions to make your original proposal
> work. The fact that you are suggesting these possibilities are evidence to
> me that not enough thought was placed in the original proposal.
>
> The standard does not depend on "compiler switch solutions" and the
general
> trend of C++ as a language is to minimise and eliminate preprocessor
usuage
> (#define replaced with proper constants and inline functions with proper
> type checking).


I am sorry but this excuse that a certain keyword may be used as an
identifier in old code cannot be serious. With this excuse nothing new can
be introduced to the language since its keyword(s) may be used in old code.
Even if we only consider new standard library facilities.



>
> If you want to put up a proposal, you could not do better than consider
some
> of the points that Bjane Stroustrup raises in Design and Evolution of C++.
>
> Have a look at section 6.4.1 "Criteria for Extensions".
>
> Bjarne Stroustrup then gives several examples that are good candidates for
> possible extensions and then goes into the flaws of them. It is worth
> reading.


I have no doubt for this. Perhaps i 'll do it after i finish TC++PL.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

In article <c87c1cfb.0301201605.65b647b9@posting.google.com>, Bob Bell
<belvis@pacbell.net> writes
>The beginner will learn that to define template arguments he can use
>the characters "<" and ">". He must be careful not to put two ">"
>characters adjacent to each other unless he means the right shift
>operator. Nothing much to learn really.

And the best answer to that wart is to remove it from the language.
Modern compiler technology can handle the problem (which is the right
way, make the compiler do the confusing stuff). The 'of' proposal does
not solve the problem, allowing >> to mean close two templates does (of
course if we had chosen a better template syntax, we would not have that
problem)




--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

In article <Xw%W9.302685$FT6.52081594@news4.srv.hcvlny.cv.net>, Hillel
Y. Sims <usenet@phatbasset.com> writes
>""Ioannis Vranos"" <noicys@h01tmail.com> wrote in message
>news:1042928311.358639@athprx02...
>>
>> Benefits: I believe that the adoption of this new syntax would have the
>> benefit that standard containers would become very comprehensible for
>> newcomers (and not only) and would be prefered (and be taught) instead of
>> the built in arrays etc. And except of the STL facilities, people would be
>> able to create templates and understand them more easily.
>>
>
>It seems hardly believable to me that the <> syntax (including the '> >'
>quirk) is a major factor that causes new C++ programmers difficulties with
>using standard containers. Will it make it easier for anyone to understand
>how to work with std::map and its "value_type of const K, V" and "pair of
>iterator, bool"? Will it make it easier for anyone to understand why they
>cannot write "vector of auto_ptr of T*", or why/when it is necessary to use
>back_insert_iterator when a "vector of T" is the target destination of
>std::copy()?


OK, I have had a chance to discuss this with a couple of genuine
newcomers. Their reaction is that:

vector<int>

looks like a name with a couple of special purpose characters. They have
no problem with that. Types are entities in C++ and have names, some
names use special characters such as std::cout. Spelling a type's name
as std::vector<int> is fine with them. However they are absolutely
adamant that 'std::vector of int' looks nothing like the name of a type.

I think they have hit the nail on the head. Names should look like
names. How we vocalise them is a quite different issue.

Now exactly how, using the 'of' syntax, are we supposed to write:

vector<int>::iterator

?
The 'of' syntax has the wrong sense even in simple cases and does not
extend comfortably.

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

Ioannis Vranos wrote:
>
> I am sorry but this excuse that a certain keyword may be used as an
> identifier in old code cannot be serious. With this excuse nothing new can
> be introduced to the language since its keyword(s) may be used in old code.

No, it doesn't mean that at all. It means that new keywords should only
be introduced when there is no reasonable alternative way of providing
an important feature.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

Francis Glassborow wrote:
>
> And the best answer to that wart is to remove it from the language.
> Modern compiler technology can handle the problem (which is the right
> way, make the compiler do the confusing stuff).

It's not a matter of modern compiler technology, but of changing the
meaning of >>. The reason that we rejected >> as a terminator for two
templates was that there were certain expressions that would become
ambiguous. Another possibility would be to decide that >> in a template
argument list always means terminate two templates, and that may be a
reasonable approach. But that, too, will introduce confusion in some
cases.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

On Tue, 28 Jan 2003 13:08:37 +0000 (UTC), noicys@hotmail.com ("Ioannis
Vranos") wrote:

>""Stephen Howe"" <NOSPAMsjhowe@dial.pipex.com> wrote in message
>news:3e35cc04$0$246$cc9e4d1f@news.dial.pipex.com...
>> > Then what about a compiler switch /use_old_syntax_only.
>>
>> Sorry this does not fly for me. You simply can't expect anyone to take
>your
>> proposal seriously if on this part of the thread you are reduced down to
>> pre-processor and compiler switch solutions to make your original proposal
>> work. The fact that you are suggesting these possibilities are evidence to
>> me that not enough thought was placed in the original proposal.
>>
>> The standard does not depend on "compiler switch solutions" and the
>general
>> trend of C++ as a language is to minimise and eliminate preprocessor
>usuage
>> (#define replaced with proper constants and inline functions with proper
>> type checking).
>
>
>I am sorry but this excuse that a certain keyword may be used as an
>identifier in old code cannot be serious. With this excuse nothing new can
>be introduced to the language since its keyword(s) may be used in old code.
>Even if we only consider new standard library facilities.

Why do you think namespaces were invented? To prevent the problem with
libraries. However, with keywords the problem is far worse, since you
have no std namespace insulation. Adding a new keyword to any language
is a *major* undertaking. Why do you think that the C99 boolean
keyword is _Bool rather than bool?

We could use _Of instead of of, and have a standard header that looked
like this:

#define of _Of

But _Of is even uglier that the current <> syntax, which I don't
actually mind personally, except for the ambiguity with operator< that
I think is the primary cause of the annoying "typename" and "template"
usage.

Tom

---
[ 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                       ]

""Stephen Howe"" <NOSPAMsjhowe@dial.pipex.com> wrote in message
news:3e35fc7a$0$223$cc9e4d1f@news.dial.pipex.com...
> > Far more obvious what a certain expression does. It makes templates more
> > easy to use.
>
>
> > Fixed. The expression is evaluated linearly from left to right. If it
> > doesn't suit you use parenthesis:
> >
> >
> > type1 of type2 of type3,type4 s;
> >
> > equivallent to:
> >
> > type1<type2<type3,type4> > s;
> >
> >
> >
> > type1 of (type2 of type3),type4 s;
> >
> > equivallent to:
> >
> > type1<type2<type3 >, type4> s;
>
> But notice you have had to "fix" it. The people in this newsgroup are C++


By fix i meant that i changed the importance of parenthesis after that
notice. This has happened some time ago, the final suggestion as it has
evolved can be seen at:

http://users.forthnet.gr/ath/ivr/docs/templates.htm

or

http://www.noicys.cjb.net/docs/templates.htm



> experts and even they pointed out flaws.


Naturally. I had not thought every minor detail from the beginning. However
currently the suggestion is mature.


> If that is the case, how can you
> claim that your notation is  "far more comprehensible"? The fact that you
> have to fix it several times strike a blow against comprehensibilty.


? My suggestion was not a thought of months, but of some hours. After those
remarks it has evolved ("fixed" if you like). As it currently is, i have
strong confidence that it is more comprehensible than the current template
syntax.




--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:MZ2ig7AIalN+Ew5C@robinton.demon.co.uk...
>
> Now exactly how, using the 'of' syntax, are we supposed to write:
>
> vector<int>::iterator
>
> ?
> The 'of' syntax has the wrong sense even in simple cases and does not
> extend comfortably.


vector of int::iterator p;

or

vector of (int)::iterator p;

or

(vector of int)::iterator p;


But personally i would not use the parenthesis for such simple case.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

> I am sorry but this excuse that a certain keyword may be used as an
> identifier in old code cannot be serious. With this excuse nothing new can
> be introduced to the language since its keyword(s) may be used in old
code.
> Even if we only consider new standard library facilities.

I did not mention anything about keywords. As a whole I concur with you on
the point of adding keywords. But if C++ is to gain one extra keyword, the
pain involved for all those that have that keyword as an identifier in their
files better be worth it. And that means it should be overwhelming
"must-have" feature to add to C++. It would have to be something that C++
overwhelmingly lacks. It would have to be something that complements
existing C++  features, not is in opposition to them. I don't think
realistically it falls into that category.

Some other points about your proposal:

(i) All existing compilers will get bigger. They will get bigger because
they now have to deal with this alternative syntax.

(ii) Strictly speaking it is not necessary. You have claimed that these are
harder to understand

vector <char>     v1;
vector <int>        v2;
vector <string>    v3;
vector <double>  v4;
vector <myclass> v5;

than your syntax but I am not convinced. I also deal with newbie C++
programmers fairly regularly and I have yet to see a question on this syntax
by them.

(iii) There is more to creating a syntax than meets the eye. Mathematically
it has to be
- complete (i.e. it is possible to declare/define whatever object type in
that syntax)
- unambiguous (i.e. it is unmistakeable as what is meant in that syntax)

For instance, without precedence and associativity, it is ambiguous as to
whether in infix notation

2 - 3 /  4

means  (2 - 3) / 4 or 2 - (3 / 4). Switch to prefix or postfix notation and
the ambiguity goes. Already in this thread, others have pointed out
expressions that are ambiguous and so you introduced parenthesis. It is far
from clear that your syntax is complete and unambiguous. Have you shown that
that is so?

(iv) It goes against the style of C++ declarations and definitions and is
limited in use. There is a certain style that has it is roots in C for C++.
Apart from the angle brackets containing the type, templates seem to me to
extend that style. The English-like syntax breaks that. I don't find that
clearer but confusing. You are saying that you would apply it to templates
but not any other declarations/definitions types in C++? Not arrays? Not
functions? So that means from a newbie C++ programmer, they get used to
declaring/defining simple types (int, char, simple classes) using C++ and
suddenly when they are introduced to templates they have to switch to a
different style of syntax with the keyword "of" ? That is not clearer.

The style issue is equivalent, to me, to owning a house done in Tudor style
and someone is proposing an extension in Georgian style, completely out of
keeping with the original house.

Cheers

Stephen Howe


---
[ 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                       ]

"tom_usenet" <tom_usenet@hotmail.com> wrote in message
news:3e36bdfc.18906812@news.easynet.co.uk...
>
> Adding a new keyword to any language
> is a *major* undertaking. Why do you think that the C99 boolean
> keyword is _Bool rather than bool?


Because they took a really stupid decision. I have seen no other language
revision where new keywords were introduced as _Camel syntax.


>
> We could use _Of instead of of, and have a standard header that looked
> like this:
>
> #define of _Of
>
> But _Of is even uglier that the current <> syntax, which I don't
> actually mind personally, except for the ambiguity with operator< that
> I think is the primary cause of the annoying "typename" and "template"
> usage.


C99 should have used bool as a built in type instead of _Bool, and with the
same conversion rules that bool has in C++. Else it would have been better
to avoid introducing it. Not to mention the other stupid things like size_t
can be a typedef of some other exotic type larger than the provided built in
ones. And there are a lot of others to criticise but we would escape from
the spirit of this thread. :)


The last thing i expecting is to see new _B00l*.* in C++0x like built in
_Complex type. Any new keyword must be introduced in the "physical C++
notation" that is without any _Camel else it would severely break the
language syntax.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:MZ2ig7AIalN+Ew5C@robinton.demon.co.uk...
> [...]
> I think they have hit the nail on the head. Names should look like
> names. How we vocalise them is a quite different issue.
>
> Now exactly how, using the 'of' syntax, are we supposed to write:
>
> vector<int>::iterator
>
> ?
> The 'of' syntax has the wrong sense even in simple cases and does
> not extend comfortably.

Not to mention that it totally goes against the grain of C++ style.  I
would expect to see 'of' in Ada or Pascal, where they spell '{' as
'begin' and '}' as 'end'.  In C++, we use symbols as delimiters, not
words.  I think a better proposal would be to add color to the
language, and say that yellow >> is the shift operator, and gray >>
is the end of two nested template parameter lists. ;>

Dave


---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043727222.367166@athprx02>...
> I am sorry but this excuse that a certain keyword may be used as an
> identifier in old code cannot be serious.

Why not? How would you address the problem? If you know how to
introduce a keyword without breaking old code, please let us know. I'm
sure the standard committe would be very interested.

As it stands, introducing a keyword like "of" has the potential of
creating many (tens? hundreds?) of man-years of effort just to get
existing code to compile. Why do you think this is not a serious
problem?


Bob Bell

---
[ 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                       ]

David> Not to mention that it totally goes against the grain of C++
David> style.  I would expect to see 'of' in Ada or Pascal, where they
David> spell '{' as 'begin' and '}' as 'end'.  In C++, we use symbols
David> as delimiters, not words.  I think a better proposal would be
David> to add color to the language, and say that yellow >> is the
David> shift operator, and gray >> is the end of two nested template
David> parameter lists. ;>

Not necessary.  It's actually quite easy to redefine the C++ grammar,
in a way that is almost completely transparent to users, so as to
resolve the problem of treating >> as one operator or two.

The basic idea is to abolish the >> token altogether, so where the
grammar says

        shift-expression:
             additive-expression
         shift-expression << additive-expression
                shift-expression >> additive-expression

we would change it to say

        shift-expression:
             additive-expression
         shift-expression << additive-expression
                shift-expression > > additive-expression

For symmetry, we might also abolish the << token, but it's not necessary
to do so as two < tokens can never occur consecutively.

Anyway, this change would make it possible to write types such as
vector<list<int>> without difficulty.  The only user-visible change
is that some programs that are presently invalid would become valid,
such as those containing

        int x = 3 < < 4;

or

        int x = 3 </**/<4;

The only reason I know that the committee didn't treat >> this way in
the standard is that we didn't think of it in time.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                       ]

In article <yu9965s8ub1w.fsf@europa.research.att.com>, Andrew Koenig
<ark@research.att.com> writes
>Not necessary.  It's actually quite easy to redefine the C++ grammar,
>in a way that is almost completely transparent to users, so as to
>resolve the problem of treating >> as one operator or two.
>
>The basic idea is to abolish the >> token altogether, so where the
>grammar says
>
>        shift-expression:
>               additive-expression
>               shift-expression << additive-expression
>                shift-expression >> additive-expression
>
>we would change it to say
>
>        shift-expression:
>               additive-expression
>               shift-expression << additive-expression
>                shift-expression > > additive-expression
>
>For symmetry, we might also abolish the << token, but it's not necessary
>to do so as two < tokens can never occur consecutively.
>
>Anyway, this change would make it possible to write types such as
>vector<list<int>> without difficulty.  The only user-visible change
>is that some programs that are presently invalid would become valid,
>such as those containing
>
>        int x = 3 < < 4;
>
>or
>
>        int x = 3 </**/<4;
>
>The only reason I know that the committee didn't treat >> this way in
>the standard is that we didn't think of it in time.

And I think that neatly answers Pete Becker's response to one of my
posts. If rewriting the grammar can solve the problem, compiler
technology can certainly manage it.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

In article <1043783819.871413@athprx02>, Ioannis Vranos
<noicys@hotmail.com> writes
>C99 should have used bool as a built in type instead of _Bool, and with the
>same conversion rules that bool has in C++. Else it would have been better
>to avoid introducing it. Not to mention the other stupid things like size_t
>can be a typedef of some other exotic type larger than the provided built in
>ones. And there are a lot of others to criticise but we would escape from
>the spirit of this thread. :)

I think that posts like this just demonstrate that you have not the
vaguest idea of the work that goes into a Standard and the forces that
drive it.


>
>
>The last thing i expecting is to see new _B00l*.* in C++0x like built in
>_Complex type. Any new keyword must be introduced in the "physical C++
>notation" that is without any _Camel else it would severely break the
>language syntax.

Do you have any idea about what syntax is? Names such as _Complex are
ugly but they do not get near to breaking syntax.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0301281238.5875e6da@posting.google.com...
> noicys@hotmail.com ("Ioannis Vranos") wrote in message
news:<1043727222.367166@athprx02>...
> > I am sorry but this excuse that a certain keyword may be used as an
> > identifier in old code cannot be serious.
>
> Why not? How would you address the problem? If you know how to
> introduce a keyword without breaking old code, please let us know. I'm
> sure the standard committe would be very interested.
>
> As it stands, introducing a keyword like "of" has the potential of
> creating many (tens? hundreds?) of man-years of effort just to get
> existing code to compile. Why do you think this is not a serious
> problem?


As i said a special command could be used, a #pragma, a compiler switch,
something.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Andrew Koenig wrote:
>
> The only reason I know that the committee didn't treat >> this way in
> the standard is that we didn't think of it in time.
>

template<int i>
class C {};

vector<C<3>>1> >;

This requires potentially infinite lookahead to determine whether the >>
is a shift or a template terminator.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

In article <1043783819.871413@athprx02>, Ioannis Vranos
<noicys@hotmail.com> writes
>"tom_usenet" <tom_usenet@hotmail.com> wrote in message
>news:3e36bdfc.18906812@news.easynet.co.uk...
>>
>> Adding a new keyword to any language
>> is a *major* undertaking. Why do you think that the C99 boolean
>> keyword is _Bool rather than bool?
>
>
>Because they took a really stupid decision. I have seen no other language
>revision where new keywords were introduced as _Camel syntax.


No they did that as the only acceptable way to avoid breaking vast
amounts of existing source code. You never have to spell bool as _Bool
because you just include bool.h, but equally well your existing legacy
code will never be broken because it does not include bool.h and could
never legitimately have used _Bool.

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

""Stephen Howe"" <SPAMstephen.howeGUARD@tnsofres.com> wrote in message
news:3e36e023$0$232$ed9e5944@reading.news.pipex.net...
>
> Some other points about your proposal:
>
> (i) All existing compilers will get bigger. They will get bigger because
> they now have to deal with this alternative syntax.

That's not an excuse. And the syntax evaluation rules do not differ
radically from the existing one.



> (ii) Strictly speaking it is not necessary. You have claimed that these
are
> harder to understand
>
> vector <char>     v1;
> vector <int>        v2;
> vector <string>    v3;
> vector <double>  v4;
> vector <myclass> v5;
>
> than your syntax but I am not convinced. I also deal with newbie C++
> programmers fairly regularly and I have yet to see a question on this
syntax
> by them.


As a rule, students do not tend to ask questions (especially on syntax). :)



> (iii) There is more to creating a syntax than meets the eye.
Mathematically
> it has to be
> - complete (i.e. it is possible to declare/define whatever object type in
> that syntax)
> - unambiguous (i.e. it is unmistakeable as what is meant in that syntax)
>
> For instance, without precedence and associativity, it is ambiguous as to
> whether in infix notation
>
> 2 - 3 /  4
>
> means  (2 - 3) / 4 or 2 - (3 / 4). Switch to prefix or postfix notation
and
> the ambiguity goes. Already in this thread, others have pointed out
> expressions that are ambiguous and so you introduced parenthesis. It is
far
> from clear that your syntax is complete and unambiguous. Have you shown
that
> that is so?


Without any parenthesis the expression is evaluated linearly from left to
right:


vector of vector of int s;

is equivallent to

vector of (vector of int) s;


type1 of type2 of type3,type4,type5 s;

is equivalent to

type1 of type 2 of (type3,type4,type5) s;



type1 of type2 of (type3,type4),type5 s;


is different and the parenthesis is needed so as to express that.

The equivalent of the above to the existing syntax is:

type1<type2<type3,type4>,type5> s;



>
> (iv) It goes against the style of C++ declarations and definitions and is
> limited in use. There is a certain style that has it is roots in C for
C++.


What roots has the combination <>?



> Apart from the angle brackets containing the type, templates seem to me to
> extend that style. The English-like syntax breaks that. I don't find that
> clearer but confusing. You are saying that you would apply it to templates
> but not any other declarations/definitions types in C++? Not arrays? Not
> functions? So that means from a newbie C++ programmer, they get used to
> declaring/defining simple types (int, char, simple classes) using C++ and
> suddenly when they are introduced to templates they have to switch to a
> different style of syntax with the keyword "of" ? That is not clearer.



They do it already. Simply they will do it to a simpler syntax. Different
paradigms are different things and have no roots to C. For example when i
was reading my first C++ book the O.O. public: etc keywords were too alien
for me, together with the const for member function, etc. The same applied
for modular programming (namespaces). The same especially applied for
templates, i viewed them as a completely different laguage inside the
language and that is natural, because essentially it is (a different
paradigm, the generic programming paradigm).


>
> The style issue is equivalent, to me, to owning a house done in Tudor
style
> and someone is proposing an extension in Georgian style, completely out of
> keeping with the original house.

C++ is a mixture of styles, each one for a different paradigm, and it could
not be differently.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

ark@research.att.com (Andrew Koenig) wrote in message news:<yu9965s8ub1w.fsf@europa.research.att.com>...
> The basic idea is to abolish the >> token altogether, so where the
> grammar says
>
>         shift-expression:
>              additive-expression
>          shift-expression << additive-expression
>                 shift-expression >> additive-expression
>
> we would change it to say
>
>         shift-expression:
>              additive-expression
>          shift-expression << additive-expression
>                 shift-expression > > additive-expression

Hi. I'm not a parsing expert, but a problem that has the standard
grammar is that (I think) there is no clear differentiation between
lexemes and parsing units. In a parser context, you can define both
tokens ( >> and > ) separately, and differentiate them during parsing,
in a parser-aided tokenizing.
Or, you can only have '>' as token, and treat >> as '>' '>' and
discover it (putting it in context) during the parsing, validating
things as you mention
(x > > 4). What I'm saying is that perhaps instead of changing the
standard, it should include a well-defined metagrammar and grammar
rules described in that way (separating tokenizing from parsing from
tree-walking).
I guess this is impractical right now, but would also like to know
your opinion about this.

Thanks, and sorry if saying nonsenses.

 Daniel.

---
[ 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                       ]

petebecker@acm.org (Pete Becker) writes:

> Andrew Koenig wrote:
>>
>> The only reason I know that the committee didn't treat >> this way in
>> the standard is that we didn't think of it in time.
>>
>
> template<int i>
> class C {};
>
> vector<C<3>>1> >;
>
> This requires potentially infinite lookahead to determine whether the >>
> is a shift or a template terminator.

I'm not sure that's a change: I'm pretty sure I heard Steve Clamage
commiserating with someone in Toronto about how the C++ language
grammar already requires potentially infinite lookahead.  Steve, can
you confirm/deny this?

--
                       David Abrahams
   dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

---
[ 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                       ]

David Abrahams wrote:
> the C++ language grammar already requires infinite lookahead

Correct.

struct a { a(...) { } };

a anA(a(), a(), a(), a(), a(), 7);
a frA(a(), a(), a(), a(), a(), a());

The first declaration declares an 'a' object initialized
with a bunch of integers. The second declares a function
which returns an 'a' and takes a bunch of function pointer
parameters.

---
[ 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                       ]

Pete> template<int i>
Pete> class C {};

Pete> vector<C<3>>1> >;

Pete> This requires potentially infinite lookahead to determine whether the >>
Pete> is a shift or a template terminator.

Hmmm, you're right.  But I can see how to solve this problem also.
It's analogous to how the grammar allows , to be used both as an
operator and as an argument separator.

Where the grammar says

        template-argument:
                assignment-expression
         type-id
                id-expression

replace "assignment-expression" by "ta-assignment-expression"
("ta" stands for "template argument").

Then define ta-assignment-expression as follows:

 ta-assignment-expression:
  ta-conditional-expression
  ta-logical-or-expression assignment-operator ta-assignment-expression
  throw-expression

 ta-conditional-expression:
  ta-logical-or-expression
  ta-logical-or-expression ? expression : ta-assignment-expression

 ta-logical-or-expression:
  ta-logical-and-expression
  ta-logical-or-expression || ta-logical-and-expression

        ta-logical-and-expression:
                ta-inclusive-or-expression
                ta-logical-and-expression && ta-inclusive-or-expression

 ta-inclusive-or-expression:
  ta-exclusive-or-expression
  ta-inclusive-or-expression | ta-exclusive-or-expression

 ta-exclusive-or-expression:
  ta-and-expression
  ta-exclusive-or-expression ^ ta-and-expression

 ta-and-expression:
  ta-equality-expression
  ta-and-expression & ta-equality-expression

 ta-equality-expression:
  ta-relational-expression
  ta-equality-expression == ta-relational-expression
  ta-equality-expression != ta-relational-expression

 ta-relational-expression:
  ta-shift-expression
  ta-relational-expression < ta-shift-expression
  ta-relational-expression <= ta-shift-expression
  ta-relational-expression >= ta-shift-expression

 ta-shift-expression:
  additive-expression
  ta-shift-expression << additive-expression

I've written the whole thing out to show the magnitude of the change:
nontrivial but not overwlelming.  The basic idea is that a
ta-assignment-expression is just like an assignment expression
except that it cannot contain the > or >> symbols at top level
(because I've removed them from the grammar, unless they are part
of an additive-expression, in which case they would have to be
parenthesized).

This grammar change would also get rid of the verbal disambiguation
rule in subclause 14.2, paragraph 5, that allows the compiler to
reject T<3>4>.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark


---
[ 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                       ]

On Wed, 29 Jan 2003, David Abrahams wrote:

> petebecker@acm.org (Pete Becker) writes:
>
> > Andrew Koenig wrote:
> >>
> >> The only reason I know that the committee didn't treat >> this way in
> >> the standard is that we didn't think of it in time.
> >>
> >
> > template<int i>
> > class C {};
> >
> > vector<C<3>>1> >;
> >
> > This requires potentially infinite lookahead to determine whether the >>
> > is a shift or a template terminator.
>
> I'm not sure that's a change: I'm pretty sure I heard Steve Clamage
> commiserating with someone in Toronto about how the C++ language
> grammar already requires potentially infinite lookahead.  Steve, can
> you confirm/deny this?

Yeah. To resolve the expression/declaration ambiguity, you
might need to scan to a semicolon or left brace before you
know what you have. Then you can parse the token sequence.

That is, you have to keep looking ahead for something that
cannot be part of a declaration before you can decide that
you have an expression. If you don't find such a discriminator,
the construct is ambiguous, and you treat it as a declaration.

Of course, just because some properties of the language
need arbitrary lookahead doesn't mean it's a good idea
to require it elsewhere. :-)

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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                       ]

In article <1043815196.32873@athprx02>, Ioannis Vranos
<noicys@hotmail.com> writes
>""Stephen Howe"" <SPAMstephen.howeGUARD@tnsofres.com> wrote in message
>news:3e36e023$0$232$ed9e5944@reading.news.pipex.net...
>>
>> Some other points about your proposal:
>>
>> (i) All existing compilers will get bigger. They will get bigger because
>> they now have to deal with this alternative syntax.
>
>That's not an excuse. And the syntax evaluation rules do not differ
>radically from the existing one.

This entire thread is becoming extremely sterile and clearly is
pointless because there is no conceivable way that WG21 is going to
countenance making the change you are proposing. Even if I thought it
had been carefully thought out by a group of people who had a solid
understanding of the problems I would not waste committee time on
something that would take so much time with so little potential benefit.
Actually my experience (considerable) with novices is that it would
actually be much worse than what we currently have.

I do not intend to make any further postings to this thread, and you can
take my continued silence as violent disagreement of your proposal.



--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

Pete Becker wrote:
>
> Andrew Koenig wrote:
> >
> > The only reason I know that the committee didn't treat >> this way in
> > the standard is that we didn't think of it in time.
>
> template<int i>
> class C {};
>
> vector<C<3>>1> >;
>
> This requires potentially infinite lookahead to determine whether the >>
> is a shift or a template terminator.

The root of the problem is that '<' and '>' are not always paired.
So when the parser sees a '>', it might not be paired to a previous '<'.
The other brackets, {} () [], are always paired and the closing bracket
is always paired to the nearest open bracket.

>From a high level view, a template is just a mapping of a type, e.g. int,
to another type, e.g. vector of ints. So why don't we re-use the brackets
used for indexing a map?

So let's use [] as brackets for templates in stead of <>!
No infinite lookahead, no double ']]' problem! Just
  vector[C[3>>1]];
I cannot see any code breaking from this change, but maybe there is some.

But there is no way we can remove the template<> syntax.
And nobody likes both styles to be valid at the same time. So I guess
the template[] syntax will never see the light. :-(

Sjoerd Schreuder

---
[ 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                       ]

Francis Glassborow wrote:

> Now exactly how, using the 'of' syntax, are we supposed to write:
>
> vector<int>::iterator
>
> ?

iterator of vector of int  ?
iterator from vector of int  ?

;o)

Yes, a new proposal: introduce `from' instead of ugly `::'

vector of int from std

of

vector from std of int

f.

---
[ 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                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:wNytluIYjzN+Ew$X@robinton.demon.co.uk...
>
> Do you have any idea about what syntax is? Names such as _Complex are
> ugly but they do not get near to breaking syntax.

Imagine a new C99 user to get confused between int x; and _Complex y;
syntax. He will not be reembering when to type _Camel x; and when to type
nocamel y;


It's a mess.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

ark@research.att.com (Andrew Koenig) wrote in message news:<yu9965s8ub1w.fsf@europa.research.att.com>...
> David> Not to mention that it totally goes against the grain of C++
> David> style.  I would expect to see 'of' in Ada or Pascal, where they
> David> spell '{' as 'begin' and '}' as 'end'.  In C++, we use symbols
> David> as delimiters, not words.  I think a better proposal would be
> David> to add color to the language, and say that yellow >> is the
> David> shift operator, and gray >> is the end of two nested template
> David> parameter lists. ;>
>
> Not necessary.  It's actually quite easy to redefine the C++ grammar,
> in a way that is almost completely transparent to users, so as to
> resolve the problem of treating >> as one operator or two.
>
> The basic idea is to abolish the >> token altogether, so where the
> grammar says
>
>         shift-expression:
>              additive-expression
>          shift-expression << additive-expression
>                 shift-expression >> additive-expression
>
> we would change it to say
>
>         shift-expression:
>              additive-expression
>          shift-expression << additive-expression
>                 shift-expression > > additive-expression
>
> For symmetry, we might also abolish the << token, but it's not necessary
> to do so as two < tokens can never occur consecutively.
>
> Anyway, this change would make it possible to write types such as
> vector<list<int>> without difficulty.  The only user-visible change
> is that some programs that are presently invalid would become valid

What about:

template<template<int i> class TTP>
struct test;

test<function<value >> 1>> test;

?

Should this mean (using the current language):

test<function<value >> 1> > test;

or

test<function<value> > 1 >> test; // Syntax error

An example like this is given in Josuttis/Vandevoorde.

Nevertheless, it may be better to allow ">>" for closing templates,
and making the above ambiguous. The ambiguity could be solved with
parenthesis, anyway:

test<function<(value >> 1)>> test;


Regards,

Terje

tslettebo at chello dot no

---
[ 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                       ]

ark@research.att.com (Andrew Koenig) wrote in message
news:<yu9965s8ub1w.fsf@europa.research.att.com>...
> David> Not to mention that it totally goes against the grain of C++
> David> style.  I would expect to see 'of' in Ada or Pascal, where they
> David> spell '{' as 'begin' and '}' as 'end'.  In C++, we use symbols
> David> as delimiters, not words.  I think a better proposal would be
> David> to add color to the language, and say that yellow >> is the
> David> shift operator, and gray >> is the end of two nested template
> David> parameter lists. ;>

> Not necessary.  It's actually quite easy to redefine the C++ grammar,
> in a way that is almost completely transparent to users, so as to
> resolve the problem of treating >> as one operator or two.

> The basic idea is to abolish the >> token altogether, so where the
> grammar says

>         shift-expression:
>              additive-expression
>          shift-expression << additive-expression
>                 shift-expression >> additive-expression

> we would change it to say

>         shift-expression:
>              additive-expression
>          shift-expression << additive-expression
>                 shift-expression > > additive-expression

> For symmetry, we might also abolish the << token, but it's not
> necessary to do so as two < tokens can never occur consecutively.

I like the symmetry.  Would it be reasonable to do this for all
multi-character special tokens?

> Anyway, this change would make it possible to write types such as
> vector<list<int>> without difficulty.  The only user-visible change
> is that some programs that are presently invalid would become valid,

What about programs which currently use << as the shift operator in a
template parameter, i.e.:

    template< int b >
    struct Int { } ;

    std::vector< Int< 10 >> 2 > > v ;

?

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043065186.560526@athprx02>...
> Consider this:
>
> vector<vector<int> >s(50, vector<int>(10));
>
> vector of (vector of int) s(50, vector of int(10));
>
> The new syntax is far easier to understand. No question on that. :)

I've read this whole thread, now, and you keep saying this, yet most
people in this thread are disagreeing with you in this issue. This
shows that what is readable is clearly very subjective. Thus "No
question about that" is plain wrong. Maybe no question about it for
you (although we'll get to that, as well, below here), but certainly a
question for many others, and most answers regarding the question of
the proposal being easier to read, both from experienced people, and
testemonials from beginners, is "No, it makes it harder to read". That
includes me.

Why should a word make it easier to read? Plain vector<int> says it
all for me. I like the way C++ uses symbols, rather than a lot of
words (like Pascal). You say you don't like Pascal, yet this is
definitely Pascal-like.

If words, rather than symbols, were easier to read, then, as someone
pointed out, something like "result assign 1 plus 2" should be easier
to read than "value=1+2", no? If no, then what makes templates
different in this respect? Templates nicely mirrors function calls,
and uses the idiom of passing parameters to something:

function<A,B>
function(A,B)

With your proposal, this is:

function of A,B
function(A,B)

even though the template and the function might do the same thing!

"Express coordinate ideas in similar form" - Strunk & White, "The
Elements of Style".

Your proposal breaks with this symmetry and intuitiveness, and would
likely make the language _harder_ to learn and use, not easier.

I think the fundamental problem in your proposal is that you think of
templates only in terms of containers of T. Templates are much more
than this. They are about being able to pass compile-time arguments to
entities, just like you can pass run-time arguments to entities.

Using "of" even breaks down at the level of containers of T, and it
gets progressively worse, for more complex use, which is quite
mainstream. This has been said again and again, but you don't seem to
take notice of it.

Let me show you some examples. Let's take Boost's type traits
(http://www.boost.org/libs/type_traits/index.htm):

is_void of int.

Huh? "Still confused? You won't be after this episode..."

The above doesn't ask if something is a void of int (which is
meaningless), but it means is_void<int> (is int void), and the answer
is no (false). This is an example of a compile-time function, and it's
analoguous to run-time functions: sqrt<value>, sqrt(value).

But it gets worse:

add_pointer of int.

Does this mean to add a pointer of int? It looks that way. Given that
the proposal is meant to make it intuitively easier to understand, it
seems your proposal has the opposite effect of the intended, because
what the above really means is add_pointer<int>, which creates the
type int *.

Authors of metaprogramming libraries would "love" your proposal. This
point was brought up earlier, several times, but you seemed to miss
it. How about this (using Boost.MPL):

if_ of less (of A,B), C, D)

Sorry, but this is plain rubbish. The above is your version of this:

if_<less<A,B>,C,D>

which means if(A<B) C else D;

In short, as have been said many times in this thread, "of" is often
not appropriate for templates.

Your argument is that it would make it easier to learn, and also
perhaps easier for experienced ones. Yet, the feedback from people in
this thread, both experienced people, and testemonials from
experienced C++ educators, says that neither experienced nor beginners
find the new syntax easier to use or learn, rather the contrary.

As has been pointed out, the lack of knowledge of templates and STL is
due to education, and some insisting of teaching the C-first way (and
perhaps never getting to STL), rather than the syntax.


Regards,

Terje

tslettebo at chello no

---
[ 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                       ]

Terje> Nevertheless, it may be better to allow ">>" for closing templates,
Terje> and making the above ambiguous. The ambiguity could be solved with
Terje> parenthesis, anyway:

Terje> test<function<(value >> 1)>> test;

I agree, and that's what my revised suggestion (already on its way to
a server near you) does.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                       ]

"Kresimir Fresl" <fresl@grad.hr> wrote in message
news:3E3781C2.1040100@grad.hr...
>
> Yes, a new proposal: introduce `from' instead of ugly `::'
>
> vector of int from std

Why stop there?  It's imperative that we are able to write

  iterator from map of string and key using less for string called i;

instead of the ugly, beginner confusing, current syntax of

  map<string,key,less<string> >::iterator i;

Ken


---
[ 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                       ]

""Ken Alverson"" <Ken@Alverson.net> wrote in message
news:b19iem$d7v$1@eeyore.INS.cwru.edu...
> [...]
> Why stop there?  It's imperative that we are able to write
>
>   iterator from map of string and key using less for string called i;
>
> instead of the ugly, beginner confusing, current syntax of
>
>   map<string,key,less<string> >::iterator i;

We especially need to eliminate that ubiquitous semicolon.  I propose
calling it 'semicolon', 'eos', 'end_of_statement', or 'end_of_statement
from std'.  With some work, we can eliminate all symbols from the
grammar.  Even newlines should be replaced with 'newline' or
'end_of_line from std'.  Eventually, 'Hello, world' could look like
this:

preprocessor include iostream newline int main argument_list_begin
argument_list_end newline begin cout from std stream_insert
quote Hello comma world quote stream_insert endl from std
semicolon newline end

Now that's prose even a COBOL programmer could read. ;>  I
mean, there's no arguing that this version is easier to read.  It's
obvious to anyone.  Heck, this would make C++ accessible to
English majors, but we would have to change the name to 'C plus
plus'.

Dave


---
[ 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                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:JZsjAFRuABO+Ewhq@robinton.demon.co.uk...
>
> I do not intend to make any further postings to this thread, and you can
> take my continued silence as violent disagreement of your proposal.


Ok, no problem with that. We just discuss here. :) For the record i do not
believe that anyone will suggest that syntax too, i am just discussing.
However you can discuss about C++/C99 compatibility. :)



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Francis Glassborow wrote:
>
> And I think that neatly answers Pete Becker's response to one of my
> posts. If rewriting the grammar can solve the problem, compiler
> technology can certainly manage it.
>

Actually, I said that compiler technology is irrelevant. Grammar changes
are also irrelevant. The question simply is: what do we think the
character sequence '>>' should mean? We deliberately decided that it
meant only shift right, just as it does in C. This was not because we
didn't think it was possible to change the grammar to give it an
additional meaning, nor was it because we didn't think that it was
possible for compilers to implement such a change. We decided that it
wasn't desirable.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

David Abrahams wrote:
>
> petebecker@acm.org (Pete Becker) writes:
>
> > Andrew Koenig wrote:
> >>
> >> The only reason I know that the committee didn't treat >> this way in
> >> the standard is that we didn't think of it in time.
> >>
> >
> > template<int i>
> > class C {};
> >
> > vector<C<3>>1> >;
> >
> > This requires potentially infinite lookahead to determine whether the >>
> > is a shift or a template terminator.
>
> I'm not sure that's a change:

I'm not sure why this matters. What I said is that one of the reasons we
rejected this was that it required unbounded lookahead. That's simply a
true statement.

> I'm pretty sure I heard Steve Clamage
> commiserating with someone in Toronto about how the C++ language
> grammar already requires potentially infinite lookahead.

It does.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

In article <9e3a34f7.0301290139.65acc951@posting.google.com>, Terje=20
Sletteb=F8 <"terjes."@chello.no> writes
>Nevertheless, it may be better to allow ">>" for closing templates,
>and making the above ambiguous. The ambiguity could be solved with
>parenthesis, anyway:
>
>test<function<(value >> 1)>> test;

I like this idea. It makes the unusual (pathological) case the one that=20
requires active resolution by the programmer. However I think we would=20
need a rule that says that if '>>' can be a double closure (i.e. we are=20
already at least two deep in template '<') it is a one. That leaves me a=20
little less happy but only a little. I do not think this would have the=20
same unfortunate repercussions that we have with declarations versus=20
definitions.



--=20
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

Pete> Actually, I said that compiler technology is irrelevant. Grammar
Pete> changes are also irrelevant. The question simply is: what do we
Pete> think the character sequence '>>' should mean? We deliberately
Pete> decided that it meant only shift right, just as it does in
Pete> C. This was not because we didn't think it was possible to
Pete> change the grammar to give it an additional meaning, nor was it
Pete> because we didn't think that it was possible for compilers to
Pete> implement such a change. We decided that it wasn't desirable.

Correct.  Moreover, since we made that decision, evidence has surfaced
that it causes much more trouble for users than we had anticipated--so
much more that a number of people have concluded that the committee's
original decision was a bad idea and would like to change it as part
of the next revision of the standard.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                       ]

Herb Sutter schrieb:

> On Mon, 20 Jan 2003 20:50:13 +0000 (UTC), noicys@hotmail.com ("Ioannis
> Vranos") wrote:
>
> >"Herb Sutter" <hsutter@gotw.ca> wrote in message
> >news:lngo2vgej3p8uql53ajd3fcgguucek6jv2@4ax.com...
> >> On Mon, 20 Jan 2003 06:05:09 +0000 (UTC), noicys@h01tmail.com ("Ioannis
> >> Vranos") wrote:
> >> >Both the old syntax and the new one would be valid. I am talking about the
> >> >"of" thing being used for something else. For such code a special switch
> >> >could be invented. But this is a minor technicalities.
> >>
> >> On the contrary, this is a major technical design issue.
> >>
> >> Adding any new keyword, and especially an English word like "of", has not
> >> only potential conflicts, but in this case known conflicts (e.g., I'm pretty
> >> sure I use "of" as a variable name in my own books and code). Defining the
> >> semantics of how to manage such new reserved words in a backward-compatible
> >> way (i.e., designing a general solution that can be used for all new
> >> keywords we might propose in C++0x, not a special-purpose switch for "of")
> >> is a major technical design issue. If you know of a good solution, I would
> >> be very interested in learning more about it.
> >
> >Yes, a quick one is a #define in the old source code files:
> >
> >#define of OF
> >// ...
> >#undef of
>
> I don't think that this is close to being a general solution. For one thing,
> it doesn't work. Just a few examples off the top of my head:

It could easily (??) be solved at implementation level:

a) implementations have a functionality taking a source file intended to be
compiled for this compilation as input, and produce as output a source file
containing some standard-defined encoding about the functionality (major issue:
what C++-version is used; minor issue: what are missing features, that are in this
C++-version, but not implemented yet) the implementation provides.

b) Whenever implementation is changed (either new version, or implementation is
switched), give it the files modified above as input. The implementation than
"updates" the files.
E.g. it tells the user that 'of' would be now a keyword; all identifiers having
this name are to be changed. The user then can give a single word, replacing all
'of' - identifiers with this one, or can give explicitly a new identifier for each
'of' - usage.


That way other changes to the language can be easily get into source-code too; e.g.
this "source updating tool" could replace all C-style casts by the appropriate
C++-style casts, replace the <iostream.h> header by <iostream>, <ostream>,
<istream> and whatever else was contained in old <iostream.h> and so on.

Quite useful, even in cases the languages undergoes only minor/minimal changes, not
introducing new keywords (which is probably a major change).


best regards,

Thomas

---
[ 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                       ]

Francis Glassborow schrieb:

> In article
> <Pine.LNX.4.44L-027.0301201511190.11865-100000@unix48.andrew.cmu.edu>,
> Arthur J. O'Dwyer <ajo@andrew.cmu.edu> writes
> >Or he can learn to always enclose template arguments in angle brackets,
> >just as he always encloses function arguments in round brackets.  And
> >he can separate the elements of an argument list with commas.  Which is
> >easier?
>
> I have this great idea to replace function call syntax with:
>
> foo of a and b and c;

No, because that would be then ambigous with a an instance of template-class
foo, instantiated with a new unnamed type deriving mulipe from a, b and c.
:-)

>
> IOWs just learn that the <> syntax provides arguments to template
> parameters that have been declared with <> syntax. Yes, the use of < and
>  > was not the brightest syntactical decision ever made, but that is not
> because of reading problems but because of parsing ones. That is the
> fundamental language issue and cosmetic solutions are a waste of time.

Cosmetic may be useful if a vast majority of people tend to get it wrong,
because a given syntax / name is confusing.

Example:
The wonderful this-is-a-function-declaration-but-I-wanted-a-constructor-call.

I have declared a function inside a function body various times. :-), yet I
haven't come up with an example yet this was useful :-)

Then the discussion what is confusing for whom starts, how much backward
compatibility it breaks, and as in most cases we end up changing nothing.

best regards,

Thomas

---
[ 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                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0301211841.25d7d125@posting.google.com...
> noicys@hotmail.com ("Ioannis Vranos") wrote in message
news:<1043183536.329958@athprx02>...
>
> I think you're missing the point.
>
> 1) If the source has to be edited in order to work with the new
> language, then that represents a _lot_ of work (i.e., editing hundreds
> or thousands of files). Not only that, but the new version of the
> program must now be verified. Many shops have strict requirements on
> testing and verification; in these environments changing a variable
> name can trigger a huge amount of regression testing.
>
> 2) In some cases, you may not be able to edit the code, because you
> don't own it. If you license a library from a vendor who provides
> headers and binaries, you can't simply change "of" to "abcdefg,"
> because the binary still uses "of." The result is a morass of link
> errors, about which you can do nothing.
>
> Both of these issues are non-trivial, and unlikely to be resolved to
> many people's satisfaction with a simple
>
> #define of some_mangled_name


Then what about a compiler switch /use_old_syntax_only.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"kartoffelsack" <kartoffelsack@gmx.net> wrote in message
news:65492935.0301210150.13c71d36@posting.google.com...
> > vector<vector<int> >s(50, vector<int>(10));
> >
> >
> > vector of (vector of int) s(50, vector of int(10));
> >
> >
> > The new syntax is far easier to understand. No question on that. :)
>
> Maybe in this case - but it's quite the same for me. But what about
>
> const X of(X of A,B) get (vector of int(10)& is, pair of double,in);
>
> Ho long does it take you to find the name of the function?


1sec.


> '('-Parentesis before and behind!
>
>
> Come on, it takes years for the new standard to come already. There
> are much more important things and there are important things that may
> not be in there ...
>
> I don't see what makes
>
> vector<int>
>
> complicated for an newbee.
>
> Nested templates and that stuff may be complicated but its complicated
> with the 'of' also and also it's not complicated because of the
> syntax.


I disagree but what the hell we will not fight. :)


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043183536.329958@athprx02>...
> "Herb Sutter" <hsutter@gotw.ca> wrote in message
> news:4c6r2vo38r3u2cqa1i9rdiecpr3uop9j33@4ax.com...
> >
> > I don't think that this is close to being a general solution. For one
>  thing,
> > it doesn't work. Just a few examples off the top of my head:
> >
> >   - What if there is already an identifer named "OF"?
>
> [...]
>
>
> And for the others.
>
>
> // old source code file
>
> #pragma This_is_a_minor_detail
>
>
> Please check
>
> http://users.forthnet.gr/ath/ivr/docs/templates.htm

I think you're missing the point.

1) If the source has to be edited in order to work with the new
language, then that represents a _lot_ of work (i.e., editing hundreds
or thousands of files). Not only that, but the new version of the
program must now be verified. Many shops have strict requirements on
testing and verification; in these environments changing a variable
name can trigger a huge amount of regression testing.

2) In some cases, you may not be able to edit the code, because you
don't own it. If you license a library from a vendor who provides
headers and binaries, you can't simply change "of" to "abcdefg,"
because the binary still uses "of." The result is a morass of link
errors, about which you can do nothing.

Both of these issues are non-trivial, and unlikely to be resolved to
many people's satisfaction with a simple

#define of some_mangled_name

Bob Bell

---
[ 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                       ]

belvis@pacbell.net (Bob Bell) writes:

> noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043116224.91905@athprx02>...
> > I hate begin - end and i do not like Pascal. :) Anyway what i am saying is
> > that if the template syntax does not get improved newcomers will always
> > begin with
> >
> >
> > int *p=new int[10];
> >
> > stuff instead of the standard containers. Failure to recognise this will
> > never allow templates to take off.
>
> I just don't get this. Why do you think
>
> int *p=new int[10];
>
> is more likely to be used by newbies than
>
> std::vector<int> arr(10);
[snip]

There are still 'instructors' who mis-teach that 'int *p=new int[10];'
    is better because 'std::vector<int> arr(10);' is 'too complicated,
    because it's a template'

Their numbers are decreasing, but I still find the majority of people
    I meet on the job were taught by them.

---
[ 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                       ]

"Andrew Koenig" <ark@research.att.com> wrote in message
news:yu997kd2wikq.fsf@europa.research.att.com...
>
> Ioannis> map of basic_string of char,basic_string of char m;
>
> Ioannis> is.
>
> It is also ambiguous: Does it mean
>
>         map <basic_string<char>, basic_string<char> > m;
>

It means the above. It could also be written:


map of (basic_string of char, basic_string of char) m;


In reality iy would be written:

map of string,string m;



> or does it mean
>
>         map<basic_string<char, basic_string<char> > > m;


?

The only difference with the current style is that the  <> pairs are
replaced with "of". This is simple but it is a lot nicer and far more
comprehensible:


map of int,float s;

vector of map of int,float vm;

or vector of (map of int,float) m;

Parenthesis can be ignored by the compiler, nor they can change the
precedence.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

On Sun, 19 Jan 2003, Ioannis Vranos wrote:
>
> "Andrew Koenig" <ark@research.att.com> wrote in message
> news:yu997kd2wikq.fsf@europa.research.att.com...
> > Ioannis> map of basic_string of char,basic_string of char m;
> > Ioannis> is.
> >
> > It is also ambiguous: Does it mean
> >
> >         map <basic_string<char>, basic_string<char> > m;
> >
>
> > or does it mean
> >
> >         map<basic_string<char, basic_string<char> > > m;
>
>
> ?
>
> The only difference with the current style is that the  <> pairs are
> replaced with "of". This is simple but it is a lot nicer and far more
> comprehensible:
>
> Parenthesis can be ignored by the compiler, nor they can change the
> precedence.

In that case, your syntax is much _less expressive_ than current C++
syntax, and many constructs are made impossible without extra
typedefs.  For example, how would one distinguish between the two
possible templates above?
That is:

   wibble < foo < bar > , baz < qux , quux > > fred;

   wibble of foo of bar, baz of qux, quux fred;

and

   template < foo < bar , baz < qux > ,  quux > fred;

   wibble of foo of bar, baz of qux, quux fred;

Oops!  Commas can't replace parentheses!  (And reverse
Polish notation, besides being unreadable, won't help you
here either, for the same reason.)

Verdict: C++ is better than this odd mishmash.

-Arthur

"llewelly" <llewelly.@@xmission.dot.com> wrote in message
news:86n0lzv1y6.fsf@Zorthluthik.foo...
> noicys@h01tmail.com ("Ioannis Vranos") writes:
>
> > I have been checking VDM-SL lately a math-style procedural modeling
> > language which has this style for a user type definition:
> >
> >
> > An array of int can be defined:
> >
> > int_type: seq of int
> >
> >
> > I thought that from this style of syntax a far cleaner syntax for
templates
> > can be invented. Consider these examples:
> >
> >
> > vector of int p;
> [snip]
>
> What would be the equivalent of 'vector<int,my_allocator> p;' ?


vector of int,my_allocator p;


And also consider this:


vector of vector of int p(50, vector of int(10));


which could also be written:

vector of (vector of int) p(50, vector of int(10));


but i would not use parenthesis for such simple case. Anyway parenthesis
comes with the whole syntax suggestion.


So my suggestion is:

a) The addition of keyword "of" for template instantiation (and for
templates only, the rest language syntax remains the same) together with the
ability for parenthesis.


Examples:

 vector of int v;

typedef basic_string of char string;


b) The addition of the keyword "of" as equivalents to the keywords "class"
and "typename" for template definitions so as the new syntax to fit
elegantly with the definition.


Example:

template <of T>
class something
{ //...
};

// ...

something of int s;


c) The old template syntax remains valid and interchangeable (but
deprecated).

Example:


template <class T>
class something
{ // ...
};


something of int s;


d) The default is the new syntax and the old one. For people using "of" in
old code, a special compiler switch could be used.

E.g.:

/no_newsyntax

or a pragma or whatever.

But the new syntax should be on by default.


Benefits: I believe that the adoption of this new syntax would have the
benefit that standard containers would become very comprehensible for
newcomers (and not only) and would be prefered (and be taught) instead of
the built in arrays etc. And except of the STL facilities, people would be
able to create templates and understand them more easily.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""James Kuyper Jr."" <kuyper@wizard.net> wrote in message
news:3E295BF4.1050708@wizard.net...
> Ioannis Vranos wrote:
> ....
> > This isn't difficult. A macro could be used signaling old syntax
> > compatibility. Something like:
> >
> >
> > #define TEMPLATES_OLD_ONLY
>
> You've got it reversed; for backwards compatibility, the old syntax
> would have to be the default.


Both the old syntax and the new one would be valid. I am talking about the
"of" thing being used for something else. For such code a special switch
could be invented. But this is a minor technicalities.


> Furthermore, macros aren't the appropriate mechanism. This should be a
> #pragma.


Yes. Or a compiler switch.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Ioannis Vranos wrote:
>
> So my suggestion is:
>
> a) The addition of keyword "of" for template instantiation (and for
> templates only, the rest language syntax remains the same) together with the
> ability for parenthesis.
>
> Examples:
>
>  vector of int v;
>
> typedef basic_string of char string;

The current syntax does not require any additional parentheses,
so we don't have ambiguities. However, in your proposal, there
can be ambiguous cases, in which case I guess you mean you have
to parenthesize. Suppose:

    template <typename T, typename U = T> class X { /* ... */ };
    X of X of A, B x;

Is it
    X< X<A>, B > x;
or
    X< X<A, B> > x;
?

You would have to write either
    X of (X of A), B x;
or
    X of (X of A, B) x;

---
[ 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                       ]

Ioannis Vranos wrote:
>
> The only difference with the current style is that the  <> pairs are
> replaced with "of".

You have the word "of" corresponding to the opening bracket '<',
but nothing to the closing bracket '>'. It is the source of ambiguities.
Suppose:

    template <typename T, typename U = T> class X { /* ... */ };
    X of X of A, B x;

Is it
    X< X<A>, B > x;
or
    X< X<A, B> > x;
?

> This is simple but it is a lot nicer and far more comprehensible:
>
> map of int,float s;
>
> vector of map of int,float vm;
>
> or vector of (map of int,float) m;
>
> Parenthesis can be ignored by the compiler, nor they can change the
> precedence.

Would you clarify the last sentence? I don't get the meaning.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

Ioannis Vranos wrote:
> "Andrew Koenig" <ark@research.att.com> wrote in message
> news:yu997kd2wikq.fsf@europa.research.att.com...
>
>>or does it mean
>>
>>        map<basic_string<char, basic_string<char> > > m;
>>
>>Whichever one you pick, please explain how you would write the other one.
>
>
>
> Can the above ever be valid?

Not if he's referring to std::map<>, which requires a minimum of two
arguments. However, the point was about syntax, not about semantics. One
alternative is to assume that the 'map' being used here is something
other than std::map<>. However, let me rewrite the question in order to
completely avoid that source of confusion:

Assume that A and B are two different template classes, each of which
can take either one or two arguments. Let C be a argument suitable for
use as the first template parameter of B<>. Using your proposed syntax,
how would you go about writing each of the following two expressions:

 A< B<C>, B<C> > m;

 A< B< C,B<C> > > m;

---
[ 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                       ]

"Darius" <ddarius86@hotmail.com> wrote in message
news:a40a15cb.0301182237.595d4a1f@posting.google.com...
>
> I have to agree with Ioannas, where'd you get the idea that the
> proposal was all-encompassing?  It's one additional keyword and some
> different syntax for templates.
>
>
> This is just bizarre.  So all languages are pretty much the same
> except their syntax?  I'd posit that the gross difference of paradigm
> is orders more distinguishing than syntax. C is not like Smalltalk is
> not like Haskell is not like Prolog.  The differences go much deeper
> than syntax.  And no one has trouble keeping Scheme and Lisp distinct
> despite having virtually the same syntax.
>
> More on-topic: besides '>>' what's wrong with the current template
> syntax?  The worse that could be said is that it doesn't fit in all
> that well with the rest of C++.  On that note, neither does this
> proposal.  Also, why do people keep saying this syntax is difficult
> for newbies?  They don't need to get used to it, it's just more
> syntax, it's all new and cryptic to them anyways.  The worse problems
> I can imagine with templates is template errors are enormous and
> incomprehensible; different syntax won't change that.


The new suggested syntax will make templates far more comprehensible. And
this will also reduce errors.




> This 'of' syntax is nice for basic usage with containers, but it seems
> to be asking for ambiguity problems especially with default parameters
> and nested templates.  Furthermore, for other template uses it seems
> less sensical: bitset of 10? foo of foo_traits? add of x,y (template
> metaprogramming)?



> if of cond,thenT,elseT (more template
> metaprogramming)?


I never suggested any conditional expressions.


> Then what about function templates?  Template
> metaprogramming really benefits from this aspect of the syntax (the
> rest is obscene), in that it looks similar to function application:
> less_than<5,10>::result, Factorial<10>::result; though in this case
> Factorial of 10 has a nice ring, but another issue is brought up, what
> is the syntax for accessing explicitly specialized members, it's
> obviously not: Factorial of 10 :: result.


I had posted 4 important message-replies containing important information
(including for the above) but never appeared. Now i have fixed my appearing
email address to be accurate and re-posted them again. Lets hope they will
appear soon. Until then and for the advancement of the discussion you can
also see them here:


http://users.forthnet.gr/ath/ivr/temp/elegance1.htm



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Arthur J. O'Dwyer" <ajo@andrew.cmu.edu> wrote in message
news:Pine.GSO.4.44L-027.0301191601120.17427-100000@squawvalley.ww.andrew.cmu
.edu...
>
> In that case, your syntax is much _less expressive_ than current C++
> syntax, and many constructs are made impossible without extra
> typedefs.  For example, how would one distinguish between the two
> possible templates above?
> That is:
>
>    wibble < foo < bar > , baz < qux , quux > > fred;
>
>    wibble of foo of bar, baz of qux, quux fred;
>
> and
>
>    template < foo < bar , baz < qux > ,  quux > fred;


That isn't valid. I suppose you mean:


wimple < foo < bar , baz < qux > >,  quux > fred;


That would be:

wimple of (foo of (bar,(baz of qux)),quux) fred;



>    wibble of foo of bar, baz of qux, quux fred;
>
> Oops!  Commas can't replace parentheses!  (And reverse
> Polish notation, besides being unreadable, won't help you
> here either, for the same reason.)


Yes you are right. There is the need of an extra symbol for grouping.

So i guess parenthesis would be required and play a role in precedence.


But in that case isn't

wimple of (foo of (bar,(baz of qux)),quux) fred;

more comprehensible than

wimple < foo < bar , baz < qux > >,  quux > fred;

?

I believe that the suggested syntax is to all scales.


The only change to my suggestion is the requirement of parenthesis.


What all have to say?



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""James Kuyper Jr."" <kuyper@wizard.net> wrote in message
news:3E295BF4.1050708@wizard.net...
> Ioannis Vranos wrote:
> ....
> > This isn't difficult. A macro could be used signaling old syntax
> > compatibility. Something like:
> >
> >
> > #define TEMPLATES_OLD_ONLY
>
> You've got it reversed; for backwards compatibility, the old syntax
> would have to be the default.


Both the old syntax and the new one would be valid. I am talking about the
"of" thing being used for something else. For such code a special switch
could be invented. But this is a minor technicalities.


> Furthermore, macros aren't the appropriate mechanism. This should be a
> #pragma.


Yes. Or a compiler switch.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""Ioannis Vranos"" <noicys@hotmail.com> wrote in message
news:1043012386.665093@athprx02...
>
> But in that case isn't
>
> wimple of (foo of (bar,(baz of qux)),quux) fred;
>
> more comprehensible than
>
> wimple < foo < bar , baz < qux > >,  quux > fred;

Err...no...it doesn't look any more comprehensible to me.  If you are
willing to put up with parenthesis, you can just define your own "of"

#define of(stuff) < stuff >

Ken


---
[ 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                       ]

""Ioannis Vranos"" <noicys@h01tmail.com> wrote in message
news:1042825062.761216@athprx02...
[ ...]

At the URL http://users.forthnet.gr/ath/ivr/temp/elegance1.htm i will be
keeping the proposal updated with the latest issues resolved. So since my
messages make some time to appear (even days) please check there and comment
on that content.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""Ken Alverson"" <Ken@Alverson.net> wrote in message
news:b0g4ua$du3$1@eeyore.INS.cwru.edu...
> ""Ioannis Vranos"" <noicys@hotmail.com> wrote in message
> news:1043012386.665093@athprx02...
> >
> > But in that case isn't
> >
> > wimple of (foo of (bar,(baz of qux)),quux) fred;
> >
> > more comprehensible than
> >
> > wimple < foo < bar , baz < qux > >,  quux > fred;
>
> Err...no...it doesn't look any more comprehensible to me.


What about

wimple of foo of ( (bar,baz of qux), quux) fred;




> If you are
> willing to put up with parenthesis, you can just define your own "of"
>
> #define of(stuff) < stuff >


No, because the suggestion is more flexible. To see the suggestion as it is
at any time with updates so as to resolve all the issues check:

http://users.forthnet.gr/ath/ivr/temp/elegance1.htm

since my messages sometimes take too long to reach the thread.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Ken Alverson wrote:
>
> Err...no...it doesn't look any more comprehensible to me.  If you are
> willing to put up with parenthesis, you can just define your own "of"
>
> #define of(stuff) < stuff >

Unfortunately it does not work for more than one template parameter.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

(Sorry, but previous postings of mine were truncated somehow, so
I'm reposting for the 3rd time. To mods: please cancel the 2nd one.)

Ioannis Vranos wrote:
>
> So my suggestion is:
>
> a) The addition of keyword "of" for template instantiation (and for
> templates only, the rest language syntax remains the same) together with
the
> ability for parenthesis.
>
> Examples:
>
>  vector of int v;
>
> typedef basic_string of char string;

The current syntax does not require any additional parentheses,
so we don't have ambiguities. However, in your proposal, there
can be ambiguous cases, in which case I guess you mean you have
to parenthesize. Suppose:

    template <typename T, typename U = T> class X { /* ... */ };
    X of X of A, B x;

Is it
    X< X<A>, B > x;
or
    X< X<A, B> > x;
?

You would have to write either
    X of (X of A), B x;
or
    X of (X of A, B) x;
, then what is the good of the new syntax?

> Benefits: I believe that the adoption of this new syntax would have the
> benefit that standard containers would become very comprehensible for
> newcomers (and not only) and would be prefered (and be taught) instead of
> the built in arrays etc. And except of the STL facilities, people would be
> able to create templates and understand them more easily.

I just don't see why

    map of int, float s;

is so much more comprehensible than

    map<int, float> s;

that it deserves even to deprecate the current syntax.
(Frankly speaking, I see the latter code more comprehensible.)
You would have to demonstrate that it gives much more benefit
by breaking existing codes.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

Ioannis Vranos wrote:
>
> ""Ken Alverson"" <Ken@Alverson.net> wrote in message
> news:b0g4ua$du3$1@eeyore.INS.cwru.edu...
> > If you are
> > willing to put up with parenthesis, you can just define your own "of"
> >
> > #define of(stuff) < stuff >
>
> No, because the suggestion is more flexible.

You are just repeating your proposal without answering the
most basic questions:

1. Which problems in the current language does it solve?
2. How worth is it? Enough to break current codes?

You insist that it is far more comprehensible and cleaner,
which sounds just too subjective without any supporting basis.
Furthermore, other posters have adequately pointed out problems
about your proposal but I don't think I have seen any real answer.

You'd have to be more persuasive.

> To see the suggestion as it is
> at any time with updates so as to resolve all the issues check:
>
> http://users.forthnet.gr/ath/ivr/temp/elegance1.htm
>
> since my messages sometimes take too long to reach the thread.

Summarizing the progress of the discussion is good,
but I hope you don't stop posting here any new opinions of yours.
(Subscribers of csc++ wouldn't want to read the web page over and over.)

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043012386.665093@athprx02>...
>
> But in that case isn't
>
> wimple of (foo of (bar,(baz of qux)),quux) fred;
>
> more comprehensible than
>
> wimple < foo < bar , baz < qux > >,  quux > fred;

Not really, to anyone who is comfortable with templates, it's pretty
much the same once you start using parentheses, and to anyone who
doesn't know templates very well, it'll probably be just as
incomprehensible.

Personally, this kind of syntactic sugar, where you start to need
other symbols to disambiguate what you mean, can makes it just as
confusing as the current method.

----
James "Doc" Livingston
email me at jrl@utas.edu.au

---
[ 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                       ]

James Doc Livingston wrote:

> noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043012386.665093@athprx02>...
> >
> > But in that case isn't
> >
> > wimple of (foo of (bar,(baz of qux)),quux) fred;
> >
> > more comprehensible than
> >
> > wimple < foo < bar , baz < qux > >,  quux > fred;
>
> Not really, to anyone who is comfortable with templates, it's pretty
> much the same once you start using parentheses, and to anyone who
> doesn't know templates very well, it'll probably be just as
> incomprehensible.

Worse because the syntax for simple examples doesn't lead to the syntax for multi-argument
examples.  So the beginner has to learn when to transition to the more advanced syntax.  With
the existing template syntax the beginner learns about pointy brackets and their limitations
once.  There are no subsequent refinements or complexities to stumble over.

---
[ 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                       ]

Ioannis Vranos wrote:
>
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0301171545.4131b764@posting.google.com...
> > noicys@h01tmail.com ("Ioannis Vranos") wrote
> >
> > I like this syntax. It's easy to write and understand. There doesn't
> > seem to be much room for ambiguities, either, and errors in the
> > declaration type should be very apparent. I would advocate this type
> > of syntax for any new language.
>
> Why a foreign language to steal this elegance in the future? (e.g. Java).

Nonsense. Did C++ "steal" so much of C that C doesn't have much now? :(

>
> I am talking about template syntax only and i said the old syntax to remain
> for backwards compatibility. I believe that the chance C++ to get a right
> template syntax must not be lost because of another language in the future
> having that. We are here *now*, so why not "fix" it right?

I don't think the C++ community "loses" anything because of other
languages. And what problem does your proposal fix?

--
KIM Seungbeom <musiphil@bawi.org>


---
[ 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                       ]

"KIM Seungbeom" <musiphil@bawi.org> wrote in message
news:3E2BD050.77240543@bawi.org...
> (Sorry, but previous postings of mine were truncated somehow, so
> I'm reposting for the 3rd time. To mods: please cancel the 2nd one.)
>
>
> The current syntax does not require any additional parentheses,
> so we don't have ambiguities. However, in your proposal, there
> can be ambiguous cases, in which case I guess you mean you have
> to parenthesize. Suppose:
>
>     template <typename T, typename U = T> class X { /* ... */ };
>     X of X of A, B x;
>
> Is it
>     X< X<A>, B > x;
> or
>     X< X<A, B> > x;
> ?
>
> You would have to write either
>     X of (X of A), B x;
> or
>     X of (X of A, B) x;
> , then what is the good of the new syntax?



Yes. As i said to yet unappeared messages of mine, parenthesis finally can
change the order of evaluation.

The new syntax is good because it is more comprehensible (and why not, more
flexible).


Consider this:

vector of int s(50);

instead of the more cryptic (and it is for newcomers and their teachers)

vector<int>s(50);


vector of vector of int s(50, vector of int(10));


vector<vector<int> >s(50, vector<int>(10));


vector of (vector of int) s(50, vector of int(10));


The new syntax is far easier to understand. No question on that. :)


To see the proposal as it is updated at any time check

http://users.forthnet.gr/ath/ivr/temp/elegance1.htm


You will be able to see any lst time fixes days before my messages arrive in
here. So better all to comment based on that page.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Ken Alverson wrote:

> ""Ioannis Vranos"" <noicys@hotmail.com> wrote in message
> news:1043012386.665093@athprx02...
> >
> > But in that case isn't
> >
> > wimple of (foo of (bar,(baz of qux)),quux) fred;
> >
> > more comprehensible than
> >
> > wimple < foo < bar , baz < qux > >,  quux > fred;
>
> Err...no...it doesn't look any more comprehensible to me.  If you are
> willing to put up with parenthesis, you can just define your own "of"
>
> #define of(stuff) < stuff >

Actually you can't.  Given the definition above stuff cannot contain a comma
outside of parentheses.  So lists of multiple arguments can't be arguments to
of(), they could only be arguments to of(()).

---
[ 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                       ]

""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
news:v2gn6klan5332c@corp.supernews.com...
> What would be the syntax of a template with more than one template
> parameter?


something of int,float s;



> Don't you think we need to replace most of the syntax
> that involves special punctuation with one using regular words:
>
>     vector from std of int with myintallocator myvector;
>
>     basic_string from std of char with mychartraits with
>              allocator of char mystring;
>
> ?  Is that really easier for the beginners to comprehend than
>
>     std::vector<int, myintallocator> myvector;
>     std::basic_string<char, mychartraits, allocator<char> > mystring;


No, i never suggested "with".




> ?  This is not intended as sarcasm, I am really curious.  Having
> outgrown and forgotten my beginner difficulties, I feel a bit out
> of touch...


I have no difficulties with templates myself too, but template syntax is one
of the main reasons why newcomers use built in types and not standard
library containers (and that's why they are taught to do so).


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Ioannis Vranos wrote:
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0301171545.4131b764@posting.google.com...
>
>>noicys@h01tmail.com ("Ioannis Vranos") wrote
>>
>>I like this syntax. It's easy to write and understand. There doesn't
>>seem to be much room for ambiguities, either, and errors in the
>>declaration type should be very apparent. I would advocate this type
>>of syntax for any new language.
>
>
>
> Why a foreign language to steal this elegance in the future? (e.g. Java).

Because it's too different from the normal style of C++. Language
designs have to work as a whole. Your suggestion is like putting a lobby
done in baroque style on a building, the entire rest of which was done
in art deco style. What's worse, the building already has a lobby,
adequate in size for that building's purposes, which the new lobby does
not replace. There's no special significance to the styles I chose -
those were just the first two style names I could think of that were
sufficiently distinct from each other. If you hate art deco, this might
seem like an improvement, but you're better off building a brand new
building, all in baroque style, and allow the art deco fans enjoy their
building.

In general, it's a bad idea for a language to define two different ways
to say exactly the same thing. Doing so doubles the effort needed to
learn the language, because backward compatibility means you can never
completely abandon the previous style. It far more than doubles the
complexity of the relevant sections of the standard, because the
standard has to define not only both syntaxes separately, but also how
they interact. It far more than doubles the impact on implementors,
because they have to not only recognize both syntaxes, but also have to
implement the standard's rules about how they interact.

>>What are the major differences between (say) C++ and Cobol? There are
>>a thousand different things, but most of the important ones come down
>>to syntax. At some level,
>>    ADD A TO B GIVING C
>>    COMPUTE D = E + F * G
>>    IF C<D THEN PERFORM C-LESS-THAN-D THROUGH C-LESS-THAN-D-END.
>>is similar to
>>    c = a + b;
>>    d = e + f*g;
>>    if (c<d) c_less_than_d();
>
>
>
> Irrelevant. I am talking about templates only.

You were talking about adding a new syntax for templates. He was talking
about the importance of having a consistent style of syntax within a
given language. That strikes me as being very relevant.

> I am talking about template syntax only and i said the old syntax to remain
> for backwards compatibility. I believe that the chance C++ to get a right
> template syntax must not be lost because of another language in the future
> having that. We are here *now*, so why not "fix" it right?

Because it's not broken. The right way to fix what you perceive to be
broken, is to define a new language for which the way you want to do it
is consistent with the style of the rest of the language.

---
[ 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                       ]

On Mon, 20 Jan 2003 06:04:31 +0000 (UTC), noicys@hotmail.com ("Ioannis
Vranos") wrote:

>"Darius" <ddarius86@hotmail.com> wrote in message
>news:a40a15cb.0301182237.595d4a1f@posting.google.com...

>> More on-topic: besides '>>' what's wrong with the current template
>> syntax?  The worse that could be said is that it doesn't fit in all
>> that well with the rest of C++.  On that note, neither does this
>> proposal.  Also, why do people keep saying this syntax is difficult
>> for newbies?  They don't need to get used to it, it's just more
>> syntax, it's all new and cryptic to them anyways.  The worse
problems
>> I can imagine with templates is template errors are enormous and
>> incomprehensible; different syntax won't change that.
>
>The new suggested syntax will make templates far more comprehensible.
And
>this will also reduce errors.

My question was more of, why is the _current_ template syntax
considered especially confusing to beginners.  There is plenty of
"cryptic" syntax in C++, what about template syntax makes it (so
people would have you believe) outrageously cryptic?

>> if of cond,thenT,elseT (more template
>> metaprogramming)?
>
>I never suggested any conditional expressions.

Give me a break. ifT of condT,thenT,elseT as in...
template <bool condT,typename thenT,typename elseT>
struct ifT{
    typedef thenT result;
};
template <typename thenT, typename elseT>
struct ifT<false,thenT,elseT>{
    typedef elseT result;
};

>> Then what about function templates?  Template
>> metaprogramming really benefits from this aspect of the syntax (the
>> rest is obscene), in that it looks similar to function application:
>> less_than<5,10>::result, Factorial<10>::result; though in this case
>> Factorial of 10 has a nice ring, but another issue is brought up,
what
>> is the syntax for accessing explicitly specialized members, it's
>> obviously not: Factorial of 10 :: result.
>
>I had posted 4 important message-replies containing important
information
>(including for the above) but never appeared. Now i have fixed my
appearing
>email address to be accurate and re-posted them again. Lets hope they
will
>appear soon. Until then and for the advancement of the discussion you
can
>also see them here:

Basically, I'm opposed to this proposal as it simplifies only a
relatively narrow set of usages (mainly containers), for most other
uses this syntax is meaningless or even misleading, e.g. Stack of
EmptyStrategy? (see chapter 7 of "Generative Programming");
furthermore, it only simplifies simple uses.  Complex templates will
be no more readable using this syntax.  The syntax is ambiguous,
"cryptic" but unambiguous syntax is better than English-like ambiguous
syntax, and using parenthesis is hardly a solution as now the syntax
is uglier than it was to begin with.  In my opinion, this syntax only
helps simple uses that would already be simple to understand, while
making more complex usages obfuscated as well as being downright
inappropriate in those complex usages. "of" has implications that are
not appropriate for a large set of template usages.  I've given
various examples in this post and the previous of usages where "of" is
meaningless or misleading.  None of these are oddball corner cases.
There are various examples from the Standard C++ Library and Boost;
the whole type_traits section from Boost would be nonsensical, is_void
of t?  And this doesn't benefit function templates at all.

Perhaps C++'s template syntax does need to be cleaned up, but this is
DEFINITELY not the right way to go.

---
[ 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                       ]

Ioannis Vranos wrote:
> I have been checking VDM-SL lately a math-style procedural modeling
> language which has this style for a user type definition:
>
>
> An array of int can be defined:
>
> int_type: seq of int
>
>
> I thought that from this style of syntax a far cleaner syntax for templates
> can be invented. Consider these examples:
>
>
> vector of int p;
>
> vector of int p(50);
>
> vector of vector of int s;
>
> vector of vector of int s(50, vector of int(10));
>
> basic_string of char s;
>
>
>
> In this style templates become far more comprehensible for newcomers (and
> why not for non-newcomers too).

I think your proposal is not sound. For one, it only makes sense for
certain special templatised classes, such as containers. It doesn't make
sense for other uses of templates, such as traits, policies,
metaprogramming, &c.

I also fail to see why you consider current syntax incomprehensible;
with the exception of using angle brackets instead of ordinary brackets
template syntax matches the intuition of "metafunctions" mapping tuples
of types to types. I wouldn't mind this being indicated more cleanly,
e.g. by endorsing the template typedef proposal.

For example, to me the obvious way to think of, say, vector is as a
function vector: Type x Allocator --> Type. The built in type system has
such functions, such as * : Type --> Type that maps a type to the
pointer to an object of the type type. Templates are a mechanism that
allows building user defined type functions. Now, if these were ordinary
functions, one would write, say, vector(int, some_allocator). The only
difference between this "obvious" syntax and the one currently in use
are the angle brackets.

> I think this would be an important improvement towards a cleaner syntax,
> and also its simplicity would help towards to the adoption of
> templates from newcomers, in place of inherently unsafe built-in arrays etc.

I don't think the template syntax is any more difficult for newcomers
than the other portions of the C++ syntax. Understanding the mechanism
of templates and template intensive programs is a whole another matter,
but can't really be fixed by syntax changes.

[snip]

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

---
[ 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                       ]

Ioannis Vranos wrote:

> I hate begin - end and i do not like Pascal. :) Anyway what i am saying is
> that if the template syntax does not get improved newcomers will always
> begin with
>
> int *p=new int[10];
>
> stuff instead of the standard containers. Failure to recognise this will
> never allow templates to take off.

Andrew Koenig & Barbara E. Moo:
``Accelerated C++: Practical Programming by Example''

http://www.research.att.com/~ark/bibliography/accelerated.html

fres

---
[ 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                       ]

Francis Glassborow wrote:

> In article <3E2C7395.10512B@attbi.com>, Witless <witless@attbi.com>
> writes
> >> Have you ever wondered why newcomers tend to use built in arrays instead of
> >> vectors and stuff?
> >
> >No, I have not.  In my experience new users take baby steps.  Comprehending the
> >STL is not a baby step.
> >And there is no way to teach proper usage of the STL without covering pointers
> >and arrays.
>
> I think that is completely untrue.

Out of context you might be right.

> I will happily teach you to write
> perfectly good programs without once explicitly using a pointer or an
> array.

Yes, in a course called "STL".  Not in a course called "C++".

> What I cannot do is to teach you to understand and maintain
> legacy code without understanding those two things. That is a completely
> different issue.
>
> --
> ACCU Spring Conference 2003 April 2-5
> The Conference you cannot afford to miss
> Check the details: http://www.accuconference.co.uk/
> Francis Glassborow      ACCU
>
> ---
> [ 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                       ]

---
[ 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                       ]

"Ioannis Vranos" <noicys@hotmail.com> wrote...
> [...] Anyway what i am saying is
> that if the template syntax does not get improved newcomers will always
> begin with
>
>
> int *p=new int[10];
>
> stuff instead of the standard containers.

And what's so bad about it?

> Failure to recognise this will
> never allow templates to take off.

That's where you will never get many of us to agree.  They _have_
_taken__off_ already and you seem to have missed it...  Too bad.

Victor
--
Please remove capital A's from my address when replying by mail


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"KIM Seungbeom" <musiphil@bawi.org> wrote in message
news:3E2BB40B.7410BF7@bawi.org...
> Ken Alverson wrote:
> >
> > Err...no...it doesn't look any more comprehensible to me.  If you
are
> > willing to put up with parenthesis, you can just define your own
"of"
> >
> > #define of(stuff) < stuff >
>
> Unfortunately it does not work for more than one template parameter.

Oops...you are, of course, correct.

Ken


---
[ 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                       ]

Ioannis Vranos wrote:
>
> "Herb Sutter" <hsutter@gotw.ca> wrote in message
> news:lngo2vgej3p8uql53ajd3fcgguucek6jv2@4ax.com...
> >
> > Adding any new keyword, and especially an English word like "of", has not
> > only potential conflicts, but in this case known conflicts (e.g., I'm pretty
> > sure I use "of" as a variable name in my own books and code). Defining the
> > semantics of how to manage such new reserved words in a backward-compatible
> > way (i.e., designing a general solution that can be used for all new
> > keywords we might propose in C++0x, not a special-purpose switch for "of")
> > is a major technical design issue. If you know of a good solution, I would
> > be very interested in learning more about it.
>
> Yes, a quick one is a #define in the old source code files:
>
> #define of OF
>
> // ...
>
> #undef of
>
> I do not think compatibility can be that a large issue. This patch is so
> simple that you can write even a small program in C patching the old source
> code files.
>
> I do not think this can be a issue!

How naive. ;-) What if the word 'OF' is also used?

Your solution does not solve any problem,
but just transforms it to another one.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043116224.91905@athprx02>...
> I hate begin - end and i do not like Pascal. :) Anyway what i am saying is
> that if the template syntax does not get improved newcomers will always
> begin with
>
>
> int *p=new int[10];
>
> stuff instead of the standard containers. Failure to recognise this will
> never allow templates to take off.

I just don't get this. Why do you think

int *p=new int[10];

is more likely to be used by newbies than

std::vector<int> arr(10);

???

Bob Bell

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") writes:

| Yes, a quick one is a #define in the old source code files:

So you propose to all _change_ old codes that happened to use that
identifier?  Sorry, that doesn't cut it.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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                       ]

> vector<vector<int> >s(50, vector<int>(10));
>
>
> vector of (vector of int) s(50, vector of int(10));
>
>
> The new syntax is far easier to understand. No question on that. :)

Maybe in this case - but it's quite the same for me. But what about

const X of(X of A,B) get (vector of int(10)& is, pair of double,in);

Ho long does it take you to find the name of the function?
'('-Parentesis before and behind!


Come on, it takes years for the new standard to come already. There
are much more important things and there are important things that may
not be in there ...

I don't see what makes

vector<int>

complicated for an newbee.

Nested templates and that stuff may be complicated but its complicated
with the 'of' also and also it's not complicated because of the
syntax.

---
[ 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                       ]

In article <1043116224.91905@athprx02>, Ioannis Vranos
<noicys@hotmail.com> writes
>I hate begin - end and i do not like Pascal. :) Anyway what i am saying is
>that if the template syntax does not get improved newcomers will always
>begin with
>
>
>int *p=new int[10];
>
>stuff instead of the standard containers. Failure to recognise this will
>never allow templates to take off.
>
>

In the book I am writing for genuine newcomers they will not see any
such syntax unless the read it elsewhere.

It is much easier to explain

vector<int> data(10);

than it is to explain your declaration. And if they have not yet seen
raw arrays declared they aren't even going to get caught by the
difference between the above and:

vector<int> data[10];


I say  again, it is a matter of good teaching and presentation.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

Ioannis Vranos wrote:
> ""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
> news:v2os3tccqt9cf5@corp.supernews.com...
>
>>So, drop the 'of', replace the parentheses with angle brackets...
>>
>>It makes less and less sense every day I read about it.  What is
>>the purpose of making a programming language constructs look more
>>like a natural language statements?  Are they easier to understand
>>that way?  I do not think so.  Why do we have the diameter symbol?
>>The sum symbol (sigma)?  The plus, etc.?  They mean the same thing
>>for people whose "normal" communication language is not necessarily
>>English.  Who will benefit from your proposal?  English-speaking
>>newbies.  What about those whose mother tongue is not English?  The
>>fewer keywords they need to learn the better.  Often they don't
>>know the meaning (or the translation) of the keyword outside the
>>context of a computer program.  That's not a bad thing.
>>
>>Is there any benefit of what you propose beyond making it simpler
>>for those who are just starting to learn C++?  Isn't your suggestion
>>similar to one about replacing curly braces with "begin" and "end"
>>(or "begin_compound_statement" and "end_compound_statement")?  What
>>about replacing the asterisk with "times" when it's a multiplication
>>and with "deref" when it's a dereference?
>
>
>
> I hate begin - end and i do not like Pascal. :) Anyway what i am saying is
> that if the template syntax does not get improved newcomers will always
> begin with
>
>
> int *p=new int[10];
>
> stuff instead of the standard containers. Failure to recognise this will
> never allow templates to take off.

I don't see why

  int * p = new int[10];

is more obvious to a beginner in C++ than

  vector<int> p(10);

In fact, since the latter does not require understanding of pointers or
dynamic memory management issues, it seems *easier* for a beginner to
understand. Both are equally difficult to grasp from a syntactical point
of view.

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043097547.293614@athprx02>...
> "Arthur J. O'Dwyer" <ajo@andrew.cmu.edu> wrote in message
> > is incompatible with much existing C++ code,
>
> It isn't. The current syntax remains.

It's incompatible with every program that uses "of" as an identifier.

Bob Bell

---
[ 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                       ]

On Mon, 20 Jan 2003 20:50:13 +0000 (UTC), noicys@hotmail.com ("Ioannis
Vranos") wrote:

>"Herb Sutter" <hsutter@gotw.ca> wrote in message
>news:lngo2vgej3p8uql53ajd3fcgguucek6jv2@4ax.com...
>> On Mon, 20 Jan 2003 06:05:09 +0000 (UTC), noicys@h01tmail.com ("Ioannis
>> Vranos") wrote:
>> >Both the old syntax and the new one would be valid. I am talking about the
>> >"of" thing being used for something else. For such code a special switch
>> >could be invented. But this is a minor technicalities.
>>
>> On the contrary, this is a major technical design issue.
>>
>> Adding any new keyword, and especially an English word like "of", has not
>> only potential conflicts, but in this case known conflicts (e.g., I'm pretty
>> sure I use "of" as a variable name in my own books and code). Defining the
>> semantics of how to manage such new reserved words in a backward-compatible
>> way (i.e., designing a general solution that can be used for all new
>> keywords we might propose in C++0x, not a special-purpose switch for "of")
>> is a major technical design issue. If you know of a good solution, I would
>> be very interested in learning more about it.
>
>Yes, a quick one is a #define in the old source code files:
>
>#define of OF
>// ...
>#undef of

I don't think that this is close to being a general solution. For one thing,
it doesn't work. Just a few examples off the top of my head:

  - What if there is already an identifer named "OF"?

  - What if you have code that #includes another file, which might
    use the name "of" in some public name? If it is a header for a
    library to which you do not have the source, you cannot change
    the "of".

  - Consider a combined example:

       //--- file x.cpp
       //
       #include <fstream>

       std::ofstream of( "myfile.txt" ); // note: "of"

       #include "somelibraryheader.h"    // note: mentions an "of" or "OF"

       class OF { };                     // note: "OF"

       vector of char v;                 // note: new "of" mixed in

       enum Foo { some, combination, of, values }; // note "of"

     Where would you write your #defines?

Also, even if this did work, it would need to be done manually for every new
keyword. It does not address the question, which was to design a generalized
solution that can be used for all new keywords -- not just "of".


>I do not think compatibility can be that a large issue. This patch is so
>simple that you can write even a small program in C patching the old source
>code files.
>
>I do not think this can be a issue!

It is indeed a difficult issue. Writing a custom program is kludgy and not a
practical solution -- and even if it were, you cannot always change all
source files (e.g., third-party library headers).

Herb

---
Herb Sutter (www.gotw.ca)

Convener, ISO WG21 - Secretary, ANSI J16        (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal        (www.gotw.ca/cuj)
C++ community program manager, Microsoft  (www.gotw.ca/microsoft)

---
[ 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                       ]

"Witless" <witless@attbi.com> wrote:
> Ioannis Vranos wrote:
>

> >
> > Have you ever wondered why newcomers tend to use built in arrays instead
of
> > vectors and stuff?
>
> No, I have not.  In my experience new users take baby steps.
Comprehending the
> STL is not a baby step.
> And there is no way to teach proper usage of the STL without covering
pointers
> and arrays.

Oh yes, there is!  :-)

Check out Koenig & Moo "Accelerated C++", which teaches C++ without hardly
mentioning C.

Containers and iterators are introduced in chapter 5, generic functions in
chapter 8, and pointers and arrays in chapter 10!

> > And why they are teached this way?
>
> It's usually called the building block approach.  You introduce the basic
> concepts early so that they are available when it is time to introduce the
more
> advanced concepts.

Yes, but what *is* the basic concept?

I loved reading section 10.1 of that book, which starts:

"An array is a kind of container, similar to vector but less powerful. A
pointer is a kind of random-access iterator that is essential for accessing
elements of arrays, ..."  (page 169 !)



Bo Persson
bop2@telia.com

---
[ 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                       ]

"Herb Sutter" <hsutter@gotw.ca> wrote in message
news:4c6r2vo38r3u2cqa1i9rdiecpr3uop9j33@4ax.com...
>
> I don't think that this is close to being a general solution. For one
thing,
> it doesn't work. Just a few examples off the top of my head:
>
>   - What if there is already an identifer named "OF"?

[...]


And for the others.


// old source code file

#pragma This_is_a_minor_detail


Please check

http://users.forthnet.gr/ath/ivr/docs/templates.htm


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Bo Persson wrote:

> "Witless" <witless@attbi.com> wrote:
> > Ioannis Vranos wrote:
> >
>
> > >
> > > Have you ever wondered why newcomers tend to use built in arrays instead
> of
> > > vectors and stuff?
> >
> > No, I have not.  In my experience new users take baby steps.
> Comprehending the
> > STL is not a baby step.
> > And there is no way to teach proper usage of the STL without covering
> pointers
> > and arrays.
>
> Oh yes, there is!  :-)
>
> Check out Koenig & Moo "Accelerated C++", which teaches C++ without hardly
> mentioning C.
>
> Containers and iterators are introduced in chapter 5, generic functions in
> chapter 8, and pointers and arrays in chapter 10!
>
> > > And why they are teached this way?
> >
> > It's usually called the building block approach.  You introduce the basic
> > concepts early so that they are available when it is time to introduce the
> more
> > advanced concepts.
>
> Yes, but what *is* the basic concept?

Depends on the curriculum.  This argument devolves in to the top-down versus
bottom-up argument over program design.  Both work.  Some problems are more
amenable to one approach than the other.   But if you are teaching program
design and leave one out you are doing the student a disservice.

Similarly, if you are teaching C++ and skimp on arrays and raw pointers you are
doing the student a disservice.  Now if the student is going to be using C++ to
implement one of the four COBOL programs they may not mind.  But if they are
going to be implementing a device driver, a file system, a task scheduler, a
graphics library, or a hard real-time program, they will mind.

>
>
> I loved reading section 10.1 of that book, which starts:
>
> "An array is a kind of container, similar to vector but less powerful. A
> pointer is a kind of random-access iterator that is essential for accessing
> elements of arrays, ..."  (page 169 !)

Lincoln claimed that calling a tail a leg does not give a dog five legs.  Are
you claiming that we could deprecate arrays and pointers and still have a
language called C++?  I doubt it.

One of the issues is whether the text uses C++ to teach programming, in which
case the STL is a somewhat reasonable place to start, or whether the text is
designed to teach C++, the language.  Since C++ is supposed to still be viable
for system programming it has to retain some of the close-to-the-metal nature of
C.  That means, among other things,  arrays and raw pointers.

And I dispute the quoted characterization of pointers as array accessors.
Pointers are at least as important for organizing data structures as they are
for accessing arrays.  After all arrays have indices, while linked lists, trees,
coral rings, etc. don't.

---
[ 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                       ]

"Herb Sutter" <hsutter@gotw.ca> wrote in message
news:4c6r2vo38r3u2cqa1i9rdiecpr3uop9j33@4ax.com...
> On Mon, 20 Jan 2003 20:50:13 +0000 (UTC), noicys@hotmail.com
("Ioannis
> Vranos") wrote:
> >Yes, a quick one is a #define in the old source code files:
> >
> >#define of OF
> >// ...
> >#undef of
>
> I don't think that this is close to being a general solution. For
one thing,
> it doesn't work. Just a few examples off the top of my head:
>
>   - What if there is already an identifer named "OF"?

I believe it is outright ill-formed to #define a keyword (even a newly
added one :-). For example,

2.6/1 There are five kinds of tokens: identifiers, keywords, literals,
operators, and other separators.

According to the grammar, "#define X ..." requires X to be an
identifier, so you can't supply it with a keyword token.

Not to mention

2.11/1 The identifiers shown in Table 3 are reserved for use as
keywords (that is, they are unconditionally treated as keywords in
phase 7):

I'm surprised nobody has mentioned this yet.

Raoul Gough.

---
[ 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                       ]

"llewelly" <llewelly.@@xmission.dot.com> wrote in message
news:86n0lzv1y6.fsf@Zorthluthik.foo...
> noicys@h01tmail.com ("Ioannis Vranos") writes:
>
> > I have been checking VDM-SL lately a math-style procedural modeling
> > language which has this style for a user type definition:
> >
> >
> > An array of int can be defined:
> >
> > int_type: seq of int
> >
> >
> > I thought that from this style of syntax a far cleaner syntax for
templates
> > can be invented. Consider these examples:
> >
> >
> > vector of int p;
> [snip]
>
> What would be the equivalent of 'vector<int,my_allocator> p;' ?


vector of int,my_allocator p;


And also consider this:


vector of vector of int p(50, vector of int(10));


which could also be written:

vector of (vector of int) p(50, vector of int(10));


but i would not use parenthesis for such simple case. Anyway parenthesis
comes with the whole syntax suggestion.


So my suggestion is:

a) The addition of keyword "of" for template instantiation (and for
templates only, the rest language syntax remains the same) together with the
ability for parenthesis.


Examples:

 vector of int v;

typedef basic_string of char string;


b) The addition of the keyword "of" as equivalents to the keywords "class"
and "typename" for template definitions so as the new syntax to fit
elegantly with the definition.


Example:

template <of T>
class something
{ //...
};

// ...

something of int s;


c) The old template syntax remains valid and interchangeable (but
deprecated).

Example:


template <class T>
class something
{ // ...
};


something of int s;


d) The default is the new syntax and the old one. For people using "of" in
old code, a special compiler switch could be used.

E.g.:

/no_newsyntax

or a pragma or whatever.

But the new syntax should be on by default.


Benefits: I believe that the adoption of this new syntax would have the
benefit that standard containers would become very comprehensible for
newcomers (and not only) and would be prefered (and be taught) instead of
the built in arrays etc. And except of the STL facilities, people would be
able to create templates and understand them more easily.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""Ioannis Vranos"" <noicys@h01tmail.com> wrote in message
news:1042825062.761216@athprx02...
[...]

Regarding functions:


Definition:

template <of T>
void f( const T &X)
{
// ...
}





For non-explicit instantiation things as usual:

int x=7;
f(x);


For explicit instantiation:


f of long (7);


"Template parenthesis" could also be used here:

(f of long)(7);


As mentioned before for template class instantiation, parenthesis are
ingored by the compiler and are provided only for notational purposes for
the user. So for template-classes:


map of int,float m;

map of (int,float) m;

(map of int), float m; // stupid use

are all equivalents.



Parenthesis does not change any syntax "precedence".


The same for explicit template-function instantiation:

f of long (7);

(f of long) (7);

(f) of long (7); // stupid use


are equivalents.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"llewelly" <llewelly.@@xmission.dot.com> wrote in message
news:86n0lzv1y6.fsf@Zorthluthik.foo...
> noicys@h01tmail.com ("Ioannis Vranos") writes:
>
> What would be the equivalent of 'vector<int,my_allocator> p;' ?


vector of int,my_allocator p;


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

noicys@hotmail.com (Ioannis Vranos) writes:

> "Andrew Koenig" <ark@research.att.com> wrote in message
> news:yu997kd2wikq.fsf@europa.research.att.com...
> >
> > Ioannis> map of basic_string of char,basic_string of char m;
> >
> > Ioannis> is.
> >
> > It is also ambiguous: Does it mean
> >
> >         map <basic_string<char>, basic_string<char> > m;
> >
>
> It means the above. It could also be written:
>
>
> map of (basic_string of char, basic_string of char) m;
>
>
> In reality iy would be written:
>
> map of string,string m;
>
>
>
> > or does it mean
> >
> >         map<basic_string<char, basic_string<char> > > m;
>
> ?
>
> The only difference with the current style is that the  <> pairs are
> replaced with "of". This is simple but it is a lot nicer and far more
> comprehensible:

I think you miss the point of Andrew's complaint.

basic_string<char> becomes basic_string of char, so:
basic_string<char, basic_string<char> > becomes:
basic_string of char,basic_string of char, so:
map<basic_string<char, basic_string<char> > > becomes:
map of basic_string of char,basic_string of char

which is the same construct you eariler said was equivalent to  map
    <basic_string<char>, basic_string<char> > .

Your scheme loses information. It has no precedence ordering rules,
    and therefor cannot handle nested template args. The standard C++
    library could not be implemented using your syntax; every
    container uses nested template arguments.

> map of int,float s;
>
> vector of map of int,float vm;
>
> or vector of (map of int,float) m;
>
> Parenthesis can be ignored by the compiler, nor they can change the
> precedence.
[snip]

This is where you went wrong. If you made parenthesis a *required*
    (that is, required to disambiguate cases like the above) part of
    your scheme, able to impose precedence,

    map <basic_string<char>, basic_string<char> >

    becomes:

    map of (basic_string of (char), basic_string of (char) )

    and

    map<basic_string<char, basic_string<char> > >

    becomes

    map of (basic_string of (char, basic_string of (char) ) )

Parenthesis, or some rule set of equivalent power, is necessary to
    preserve existing expressiveness.

Personally, I'd like to see some improvements in template syntax, but
    replacing a nestable construct with a non-nestable construct is
    unacceptable. Furthermore, 'of' really only improves readability
    for simple containers; consider:

    smart_pointer of (int)

    Does the resulting type 'contain' an int? No. Is it 'made' of int?
    No. Does smart_pointer come from a place named 'int'? No. 'of'
    doesn't even work well for real-world containers:

    vector of (int,Allocator of (int))

    The vector doesn't contain an Allocator, it isn't made of
    Allocators, etc.

I do believe new keywords can improve many aspects of C++ syntax, but
    they must be chose with an eye to a generic notion of what a
    construct does, not to favor one use case of many. Despite this
    last complaint, 'of' combined with parenthesis, or better yet the
    less used square brackets [] would likely have worn better than
    re-using a pair of charecters already in use by a small herd of
    unrelated operators (<,>,>>,<<,<=,>=, though the last 3 don't
    direct conflicts.), had it been selected in the late 80's, but I
    think it's so late now the small gain isn't worth the cost - even
    if of with parenthesis made it into the next TC (not possible),
    we'd have to live with 2 different template syntaxes for a long
    time.

Finally, while template syntax could bear some improvement, other
    parts of C++ syntax are in greater need; try declaring a function
    which returns a reference to an array of pointers to
    functions. The inside-out-fix notation of C++ declarators is
    worse.

(I'll let other posters discuss the real and potential burdens imposed
    by having 2 (or more!) different syntaxes for the same thing.)

---
[ 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                       ]

"Andrew Koenig" <ark@research.att.com> wrote in message
news:yu997kd2wikq.fsf@europa.research.att.com...
>
> Ioannis> map of basic_string of char,basic_string of char m;
>
> Ioannis> is.
>
> It is also ambiguous: Does it mean
>
>         map <basic_string<char>, basic_string<char> > m;
>

It means the above. It could also be written:


map of (basic_string of char, basic_string of char) m;


In reality iy would be written:

map of string,string m;



> or does it mean
>
>         map<basic_string<char, basic_string<char> > > m;


?

The only difference with the current style is that the  <> pairs are
replaced with "of". This is simple but it is a lot nicer and far more
comprehensible:


map of int,float s;

vector of map of int,float vm;

or vector of (map of int,float) m;

Parenthesis can be ignored by the compiler, nor they can change the
precedence.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"KIM Seungbeom" <musiphil@bawi.org> wrote in message
news:3E2B442E.95C90ED@bawi.org...
> Ioannis Vranos wrote:
> >
> > So my suggestion is:
> >
> > a) The addition of keyword "of" for template instantiation (and for
> > templates only, the rest language syntax remains the same) together with
the
> > ability for parenthesis.
> >
> > Examples:
> >
> >  vector of int v;
> >
> > typedef basic_string of char string;
>
> The current syntax does not require any additional parentheses,
> so we don't have ambiguities. However, in your proposal, there
> can be ambiguous cases, in which case I guess you mean you have
> to parenthesize. Suppose:
>
>     template <typename T, typename U = T> class X { /* ... */ };
>     X of X of A, B x;
>
> Is it
>     X< X<A>, B > x;
> or
>     X< X<A, B> > x;
> ?
>
> You would have to write either
>     X of (X of A), B x;
> or
>     X of (X of A, B) x;


Yes. As i said in another message (not appeared yet) parenthesis are finally
required to define "precedence". But isn't it clearer?


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

noicys@hotmail.com (Ioannis Vranos) writes:
> So my suggestion is:
>
> a) The addition of keyword "of" for template instantiation (and for
> templates only, the rest language syntax remains the same) together with the
> ability for parenthesis.
[snip]

Before I saw this, I wrote a long post which (amount other things)
    complains that your proposal needs parenthesis. I was confused by
    your reply to Andrew, which contained this statement:

noicys@hotmail.com (Ioannis Vranos) writes:
+ Parenthesis can be ignored by the compiler, nor they can change the
+ precedence.

I mis-interpreted this to mean your proposal did not include
    parenthesis, and spent a fair amount of space complaining about
    that lack. I appologize for any upset that causes.

I won't try to cancel my post; it contains other points I do not wish
    to re-write.

---
[ 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                       ]

""Ken Alverson"" <Ken@Alverson.net> wrote in message
news:b0g4ua$du3$1@eeyore.INS.cwru.edu...
> ""Ioannis Vranos"" <noicys@hotmail.com> wrote in message
> news:1043012386.665093@athprx02...
> >
> > But in that case isn't
> >
> > wimple of (foo of (bar,(baz of qux)),quux) fred;
> >
> > more comprehensible than
> >
> > wimple < foo < bar , baz < qux > >,  quux > fred;
>
> Err...no...it doesn't look any more comprehensible to me.


What about

==> wimple of foo of (bar,(baz of qux) ),quux fred;

It's definately more comprehensible than

wimple < foo < bar , baz < qux > >,  quux > fred;


But i would do it:

typedef foo of bar,(baz of qux) fb_type;

wimple of foo of fb_type fred;




> If you are
> willing to put up with parenthesis, you can just define your own "of"
>
> #define of(stuff) < stuff >


No, because the suggestion is more flexible. To see the suggestion as it is
at any time with updates so as to resolve all the issues check:

http://users.forthnet.gr/ath/ivr/temp/elegance1.htm

since my messages sometimes take too long to reach the thread.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

(Sorry, but a previous posting of mine was truncated somehow, so
I'm reposting. To mods: do you have any idea what would have happened?
I have the full message in my 'Sent' mailbox.)

Ioannis Vranos wrote:
>
> So my suggestion is:
>
> a) The addition of keyword "of" for template instantiation (and for
> templates only, the rest language syntax remains the same) together with the
> ability for parenthesis.
>
> Examples:
>
>  vector of int v;
>
> typedef basic_string of char string;

The current syntax does not require any additional parentheses,
so we don't have ambiguities. However, in your proposal, there
can be ambiguous cases, in which case I guess you mean you have
to parenthesize. Suppose:

    template <typename T, typename U = T> class X { /* ... */ };
    X of X of A, B x;

Is it
    X< X<A>, B > x;
or
    X< X<A, B> > x;
?

You would have to write either
    X of (X of A), B x;
or
    X of (X of A, B) x;

---
[ 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                       ]

In article <3E2C1600.5149BDB1@attbi.com>, Witless <witless@attbi.com>
writes
>Worse because the syntax for simple examples doesn't lead to the syntax for multi-argument
>examples.  So the beginner has to learn when to transition to the more advanced syntax.  With
>the existing template syntax the beginner learns about pointy brackets and their limitations
>once.  There are no subsequent refinements or complexities to stumble over.


Indeed, which if I can change the subject slightly is what is wrong
elsewhere in C++ why should the two declarations:

int a(23);
int b();

Have radically different meanings? Yes, I know why they do but we can do
with an effort made to solve this kind of wart long before we look at
things that have new warts of their own.

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

"KIM Seungbeom" <musiphil@bawi.org> wrote in message
news:3E2BFC70.AD1E9AF1@bawi.org...
>
> You are just repeating your proposal without answering the
> most basic questions:
>
> 1. Which problems in the current language does it solve?


Far more obvious what a certain expression does. It makes templates more
easy to use.



> 2. How worth is it? Enough to break current codes?


No current code is broken. Both syntaxes remain valid. However the new
syntax is far more comprehensible.



>
> You insist that it is far more comprehensible and cleaner,
> which sounds just too subjective without any supporting basis.


vector< vector <int> >s(50, vector<int>(10));


vector of (vector of int) s(50, vector of int(10));



> Furthermore, other posters have adequately pointed out problems
> about your proposal but I don't think I have seen any real answer.


Fixed. The expression is evaluated linearly from left to right. If it
doesn't suit you use parenthesis:


type1 of type2 of type3,type4 s;

equivallent to:

type1<type2<type3,type4> > s;



type1 of (type2 of type3),type4 s;

equivallent to:

type1<type2<type3 >, type4> s;



The new syntax is more comprehensible.



> You'd have to be more persuasive.


I try. :)



> Summarizing the progress of the discussion is good,
> but I hope you don't stop posting here any new opinions of yours.
> (Subscribers of csc++ wouldn't want to read the web page over and over.)


I will continue posting here too of course. But the discussion here may lag
some days.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Witless" <witless@attbi.com> wrote in message
news:3E2C1600.5149BDB1@attbi.com...
>
> Worse because the syntax for simple examples doesn't lead to the syntax
for multi-argument
> examples.  So the beginner has to learn when to transition to the more
advanced syntax.  With
> the existing template syntax the beginner learns about pointy brackets and
their limitations
> once.  There are no subsequent refinements or complexities to stumble
over.


Have you ever wondered why newcomers tend to use built in arrays instead of
vectors and stuff? And why they are teached this way? Templates will take
much longer to become mainstream  (if they will do become in C++) if the
current "Mars" syntax remains.

Imagine a competitive language using the style

list of int s;

how more convenient will be to use it. Why C++ to not have that chance?


The beginner will learn that to define the template argument he can use the
keyword of. If he wants to make things more readable and/or change the order
of evaluation he can use parenthesis. Nothing much to learn really.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

On Mon, 20 Jan 2003 06:05:09 +0000 (UTC), noicys@h01tmail.com ("Ioannis
Vranos") wrote:
>Both the old syntax and the new one would be valid. I am talking about the
>"of" thing being used for something else. For such code a special switch
>could be invented. But this is a minor technicalities.

On the contrary, this is a major technical design issue.

Adding any new keyword, and especially an English word like "of", has not
only potential conflicts, but in this case known conflicts (e.g., I'm pretty
sure I use "of" as a variable name in my own books and code). Defining the
semantics of how to manage such new reserved words in a backward-compatible
way (i.e., designing a general solution that can be used for all new
keywords we might propose in C++0x, not a special-purpose switch for "of")
is a major technical design issue. If you know of a good solution, I would
be very interested in learning more about it.

Herb

---
Herb Sutter (www.gotw.ca)

Convener, ISO WG21 - Secretary, ANSI J16        (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal        (www.gotw.ca/cuj)
C++ community program manager, Microsoft  (www.gotw.ca/microsoft)

---
[ 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                       ]

On Mon, 20 Jan 2003, "Ioannis Vranos" wrote:
>
> Have you ever wondered why newcomers tend to use built in arrays instead of
> vectors and stuff?

When I was a C++ newbie, I used arrays because of their familiarity (I
had studied C and Pascal before C++).

> And why they are [taught] this way?

They aren't, anymore.  C++ is not C.

> Templates will take
> much longer to become mainstream  (if they will do become in C++) if the
> current "Mars" syntax remains.

Not to mention the "Venus" curly-braces around function bodies, the
"Jupiter" use of '0x' to indicate a number in base 16, and the "Pluto"
syntax of member pointers.

>
> Imagine a competitive language using the style
>
> list of int s;

Kind of a mutant Pascal, you mean.

> how more convenient will be to use it. Why [should] C++ not have that
> chance?

Because it is ugly, is incompatible with much existing C++ code, has
unresolved ambiguities involving precedence (even with parentheses),
and does not solve any problem with the C++ language except that it
is not Pascal.

> The beginner will learn that to define the template argument he can use the
> keyword of. If he wants to make things more readable and/or change the order
> of evaluation he can use parenthesis. Nothing much to learn really.

Or he can learn to always enclose template arguments in angle brackets,
just as he always encloses function arguments in round brackets.  And
he can separate the elements of an argument list with commas.  Which is
easier?

> --
> Ioannis

-Arthur,
whose favorite language is not C++ either

"Herb Sutter" <hsutter@gotw.ca> wrote in message
news:lngo2vgej3p8uql53ajd3fcgguucek6jv2@4ax.com...
> On Mon, 20 Jan 2003 06:05:09 +0000 (UTC), noicys@h01tmail.com ("Ioannis
> Vranos") wrote:
> >Both the old syntax and the new one would be valid. I am talking about
the
> >"of" thing being used for something else. For such code a special switch
> >could be invented. But this is a minor technicalities.
>
> On the contrary, this is a major technical design issue.
>
> Adding any new keyword, and especially an English word like "of", has not
> only potential conflicts, but in this case known conflicts (e.g., I'm
pretty
> sure I use "of" as a variable name in my own books and code). Defining the
> semantics of how to manage such new reserved words in a
backward-compatible
> way (i.e., designing a general solution that can be used for all new
> keywords we might propose in C++0x, not a special-purpose switch for "of")
> is a major technical design issue. If you know of a good solution, I would
> be very interested in learning more about it.


Yes, a quick one is a #define in the old source code files:


#define of OF

// ...

#undef of


I do not think compatibility can be that a large issue. This patch is so
simple that you can write even a small program in C patching the old source
code files.

I do not think this can be a issue!


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"llewelly" <llewelly.@@xmission.dot.com> wrote in message
news:861y38ha5g.fsf@Zorthluthik.foo...
> noicys@hotmail.com (Ioannis Vranos) writes:
>
> I think you miss the point of Andrew's complaint.

[...]

The proposal has been updated since then. Parenthesis can be used optionally
so asto change to make code more comprehensible or change the order of
evaluation:


type1<type2<type3>, type4> s;

becomes:

type1 of (type2 of type3), type4 s;



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Francis Glassborow wrote:

> In article <3E2C1600.5149BDB1@attbi.com>, Witless <witless@attbi.com>
> writes
> >Worse because the syntax for simple examples doesn't lead to the syntax for multi-argument
> >examples.  So the beginner has to learn when to transition to the more advanced syntax.  With
> >the existing template syntax the beginner learns about pointy brackets and their limitations
> >once.  There are no subsequent refinements or complexities to stumble over.
>
> Indeed, which if I can change the subject slightly is what is wrong
> elsewhere in C++ why should the two declarations:
>
> int a(23);
> int b();
>
> Have radically different meanings? Yes, I know why they do but we can do
> with an effort made to solve this kind of wart long before we look at
> things that have new warts of their own.

Is there any hope of progress on this?  I have an incredibly hard time communicating RAII to new
users because they continuously stumble over Initialization Is Not Assignment (IINA).  It appears
to me that only a wholesale revamping of the operator syntax/semantics can address the wide
variety of usages that have grown up.  But I'd rather stick with C++ than propose C+=.  What
chance is there that these cognitive conflicts can be resolved?

---
[ 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                       ]

Ioannis Vranos wrote:

> "Witless" <witless@attbi.com> wrote in message
> news:3E2C1600.5149BDB1@attbi.com...
> >
> > Worse because the syntax for simple examples doesn't lead to the syntax
> for multi-argument
> > examples.  So the beginner has to learn when to transition to the more
> advanced syntax.  With
> > the existing template syntax the beginner learns about pointy brackets and
> their limitations
> > once.  There are no subsequent refinements or complexities to stumble
> over.
>
> Have you ever wondered why newcomers tend to use built in arrays instead of
> vectors and stuff?

No, I have not.  In my experience new users take baby steps.  Comprehending the
STL is not a baby step.
And there is no way to teach proper usage of the STL without covering pointers
and arrays.

> And why they are teached this way?

It's usually called the building block approach.  You introduce the basic
concepts early so that they are available when it is time to introduce the more
advanced concepts.

> Templates will take
> much longer to become mainstream  (if they will do become in C++) if the
> current "Mars" syntax remains.

Hardly.  Templates already are mainstream.  The only down side of the current
pointy bracket syntax is the inability to pass a template with multiple
arguments to a preprocessor macro.  Your proposal makes that situation worse not
better.

>
>
> Imagine a competitive language using the style
>
> list of int s;
>
> how more convenient will be to use it.

It will not be more convenient.

> Why C++ to not have that chance?

If you like it use it:

    #define of( arglist ) < arglist >

.... and live with its limitations.

>
>
> The beginner will learn that to define the template argument he can use the
> keyword of.

This is not better than the beginner learning to define template arguments with
the symbols < and >.

> If he wants to make things more readable and/or change the order
> of evaluation he can use parenthesis. Nothing much to learn really.

Nothing much to learn with the current syntax.  But learning when parentheses
are mandatory for the of syntax is quite a lot to learn for a beginner.

---
[ 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                       ]

"Arthur J. O'Dwyer" <ajo@andrew.cmu.edu> wrote in message
news:Pine.LNX.4.44L-027.0301201511190.11865-100000@unix48.andrew.cmu.edu...
>
> On Mon, 20 Jan 2003, "Ioannis Vranos" wrote:
> >
> > Have you ever wondered why newcomers tend to use built in arrays instead
of
> > vectors and stuff?
>
> When I was a C++ newbie, I used arrays because of their familiarity (I
> had studied C and Pascal before C++).
>
> > And why they are [taught] this way?
>
> They aren't, anymore.  C++ is not C.


I think they are, from all online lists that i participate. And this because
they find the new syntax uncomprehensible. I am always suggesting them to
use the standard containers instead but so far i have the impression that
noone applies that!


> >
> > Imagine a competitive language using the style
> >
> > list of int s;
>
> Kind of a mutant Pascal, you mean.


In fact the roots of the suggestion are VDM-SL.


> Because it is ugly,

! :)


> is incompatible with much existing C++ code,

It isn't. The current syntax remains.


> has
> unresolved ambiguities involving precedence (even with parentheses),


This is very important. An example?

(Check http://users.forthnet.gr/ath/ivr/temp/elegance1.htm to see the
suggestion how it is so far).




> Or he can learn to always enclose template arguments in angle brackets,
> just as he always encloses function arguments in round brackets.  And
> he can separate the elements of an argument list with commas.  Which is
> easier?


I do not see this happening from newcomers in mainstream.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Witless" <witless@attbi.com> wrote in message
news:3E2C1600.5149BDB1@attbi.com...
>
> Worse because the syntax for simple examples doesn't lead to the syntax
for multi-argument
> examples.  So the beginner has to learn when to transition to the more
advanced syntax.  With
> the existing template syntax the beginner learns about pointy brackets and
their limitations
> once.  There are no subsequent refinements or complexities to stumble
over.


My last message appeared truncated, so i repost.


Have you ever wondered why newcomers tend to use built in arrays instead of
vectors and stuff? And why they are teached this way? Templates will take
much longer to become mainstream  (if they will do become in C++) if the
current "Mars" syntax remains.

Imagine a competitive language using the style

list of int s;

how more convenient will be to use it. Why C++ to not have that chance?


The beginner will learn that to define the template argument he can use the
keyword of. If he wants to make things more readable and/or change the order
of evaluation he can use parenthesis. Nothing much to learn really.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Ioannis Vranos" <noicys@hotmail.com> wrote...
> "llewelly" <llewelly.@@xmission.dot.com> wrote in message
> news:861y38ha5g.fsf@Zorthluthik.foo...
> > noicys@hotmail.com (Ioannis Vranos) writes:
> >
> > I think you miss the point of Andrew's complaint.
>
> [...]
>
> The proposal has been updated since then. Parenthesis can be used
optionally
> so asto change to make code more comprehensible or change the order of
> evaluation:
>
>
> type1<type2<type3>, type4> s;
>
> becomes:
>
> type1 of (type2 of type3), type4 s;


So, drop the 'of', replace the parentheses with angle brackets...

It makes less and less sense every day I read about it.  What is
the purpose of making a programming language constructs look more
like a natural language statements?  Are they easier to understand
that way?  I do not think so.  Why do we have the diameter symbol?
The sum symbol (sigma)?  The plus, etc.?  They mean the same thing
for people whose "normal" communication language is not necessarily
English.  Who will benefit from your proposal?  English-speaking
newbies.  What about those whose mother tongue is not English?  The
fewer keywords they need to learn the better.  Often they don't
know the meaning (or the translation) of the keyword outside the
context of a computer program.  That's not a bad thing.

Is there any benefit of what you propose beyond making it simpler
for those who are just starting to learn C++?  Isn't your suggestion
similar to one about replacing curly braces with "begin" and "end"
(or "begin_compound_statement" and "end_compound_statement")?  What
about replacing the asterisk with "times" when it's a multiplication
and with "deref" when it's a dereference?

Victor
--
Please remove capital A's from my address when replying by mail


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<Pine.LNX.4.44L-027.0301201511190.11865-100000@unix48.andrew.cmu.edu>,
Arthur J. O'Dwyer <ajo@andrew.cmu.edu> writes
>Or he can learn to always enclose template arguments in angle brackets,
>just as he always encloses function arguments in round brackets.  And
>he can separate the elements of an argument list with commas.  Which is
>easier?

I have this great idea to replace function call syntax with:

foo of a and b and c;

that is so much clearer than:

foo(a, b, c);

Isn't it?

IOWs just learn that the <> syntax provides arguments to template
parameters that have been declared with <> syntax. Yes, the use of < and
 > was not the brightest syntactical decision ever made, but that is not
because of reading problems but because of parsing ones. That is the
fundamental language issue and cosmetic solutions are a waste of time.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

In article <1042859176.855998@athprx02>, Ioannis Vranos
<noicys@h01tmail.com> writes
>I have no difficulties with templates myself too, but template syntax is one
>of the main reasons why newcomers use built in types and not standard
>library containers (and that's why they are taught to do so).

No they are taught to do so because teachers are not willing to teach
them properly. I have taught absolutely raw novices with no prior
knowledge using vector as the basic container, they just do not have a
problem with such things as vector<int> unless their teacher thinks they
should.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

""Ioannis Vranos"" <noicys@h01tmail.com> wrote in message
news:1042928311.358639@athprx02...
>
> Benefits: I believe that the adoption of this new syntax would have the
> benefit that standard containers would become very comprehensible for
> newcomers (and not only) and would be prefered (and be taught) instead of
> the built in arrays etc. And except of the STL facilities, people would be
> able to create templates and understand them more easily.
>

It seems hardly believable to me that the <> syntax (including the '> >'
quirk) is a major factor that causes new C++ programmers difficulties with
using standard containers. Will it make it easier for anyone to understand
how to work with std::map and its "value_type of const K, V" and "pair of
iterator, bool"? Will it make it easier for anyone to understand why they
cannot write "vector of auto_ptr of T*", or why/when it is necessary to use
back_insert_iterator when a "vector of T" is the target destination of
std::copy()?

hys
--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

---
[ 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                       ]

In article <1043098067.744636@athprx02>, Ioannis Vranos
<noicys@hotmail.com> writes
>Have you ever wondered why newcomers tend to use built in arrays instead of
>vectors and stuff? And why they are teached this way? Templates will take
>much longer to become mainstream  (if they will do become in C++) if the
>current "Mars" syntax remains.
>
>Imagine a competitive language using the style
>
>list of int s;
>
>how more convenient will be to use it. Why C++ to not have that chance?

It would make absolutely no difference, the problem is not with the
newcomers but with those teaching them.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

noicys@hotmail.com ("Ioannis Vranos") wrote in message news:<1043087072.960647@athprx02>...
> Have you ever wondered why newcomers tend to use built in arrays instead of
> vectors and stuff? And why they are teached this way? Templates will take
> much longer to become mainstream  (if they will do become in C++) if the
> current "Mars" syntax remains.

As far as I know, it has more to do with ignorance and momentum than
syntax. Why do you think that using "of" in template declarations will
change that? Yes, I've seen

vector<vector<int> > x(10, vector<int>(50));

vs.

vector of vector of int s(10, vector of int(50));

Frankly, the second doesn't look any more readable than the first.
Couple that with the fact that "of" is often misleading, as in
auto_ptr of int, and I don't see this as an improvement at all.

> The beginner will learn that to define the template argument he can use the
> keyword of. If he wants to make things more readable and/or change the order
> of evaluation he can use parenthesis. Nothing much to learn really.

The beginner will learn that to define template arguments he can use
the characters "<" and ">". He must be careful not to put two ">"
characters adjacent to each other unless he means the right shift
operator. Nothing much to learn really.

Bob Bell

---
[ 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                       ]

Ioannis Vranos wrote:
>
> Yes, a quick one is a #define in the old source code files:
>
> #define of OF

class sample
{
public:
 sample(std::ofstream of) : OF(of) {}
private:
 std::ostream &OF;
};

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

In article <3E2C7395.10512B@attbi.com>, Witless <witless@attbi.com>
writes
>> Have you ever wondered why newcomers tend to use built in arrays instead of
>> vectors and stuff?
>
>No, I have not.  In my experience new users take baby steps.  Comprehending the
>STL is not a baby step.
>And there is no way to teach proper usage of the STL without covering pointers
>and arrays.

I think that is completely untrue. I will happily teach you to write
perfectly good programs without once explicitly using a pointer or an
array. What I cannot do is to teach you to understand and maintain
legacy code without understanding those two things. That is a completely
different issue.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

Ioannis Vranos wrote:
>
> > You would have to write either
> >     X of (X of A), B x;
> > or
> >     X of (X of A, B) x;
>
> Yes. As i said in another message (not appeared yet) parenthesis are finally
> required to define "precedence". But isn't it clearer?
>

No.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

Ioannis Vranos wrote:
>
> "KIM Seungbeom" <musiphil@bawi.org> wrote in message
> news:3E2BFC70.AD1E9AF1@bawi.org...
> >
> > You are just repeating your proposal without answering the
> > most basic questions:
> >
> > 1. Which problems in the current language does it solve?
>
> Far more obvious what a certain expression does. It makes templates more
> easy to use.

In what way is it *far* more obvious and more easy to use?
By introducing the keyword "of"?
Or by changing angle brackets to optional parentheses?

I'm afraid I don't see *any* improvements in your proposal.

>
> > 2. How worth is it? Enough to break current codes?
>
> No current code is broken. Both syntaxes remain valid. However the new
> syntax is far more comprehensible.

New keywords always break existing codes.

>
> >
> > You insist that it is far more comprehensible and cleaner,
> > which sounds just too subjective without any supporting basis.
>
> vector< vector <int> >s(50, vector<int>(10));
>
> vector of (vector of int) s(50, vector of int(10));

Still I don't see any improvements.
Worse, because 'int(10)' is visually more tightly bound together
and 'vector of int(10)' may rather look like 'vector of (int(10))',
a vector made of int(10)'s.. but it's not. Then I might be tempted
to write 'vector of string("hello")' somewhere else. ;-)

>
> > Furthermore, other posters have adequately pointed out problems
> > about your proposal but I don't think I have seen any real answer.
>
> Fixed. The expression is evaluated linearly from left to right.

We are talking about declarations, not expressions.
And they are parsed, not evaluated.

> If it doesn't suit you use parenthesis:
>
> type1 of type2 of type3,type4 s;
>
> equivallent to:
>
> type1<type2<type3,type4> > s;
>
> type1 of (type2 of type3),type4 s;
>
> equivallent to:
>
> type1<type2<type3 >, type4> s;
>
> The new syntax is more comprehensible.

To me, it isn't.

At least, parentheses should be required if there are more than
one template arguments. I hate to see template arguments enumerated
without any enclosing construct, as in 'map of int, int a, b;'.
'map of (int, int) a, b;' or 'map<int, int> a, b;' is much clearer.
If you don't agree to this, I have nothing more to say than that
we have to use different languages.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3E2C982B.D73CE87E@acm.org...
> Ioannis Vranos wrote:
> >
> > Yes, a quick one is a #define in the old source code files:
> >
> > #define of OF
>
> class sample
> {
> public:
> sample(std::ofstream of) : OF(of) {}
> private:
> std::ostream &OF;
> };


#define of ZaVaRaKaTRaNeMiA


#undef of


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
news:v2os3tccqt9cf5@corp.supernews.com...
>
> So, drop the 'of', replace the parentheses with angle brackets...
>
> It makes less and less sense every day I read about it.  What is
> the purpose of making a programming language constructs look more
> like a natural language statements?  Are they easier to understand
> that way?  I do not think so.  Why do we have the diameter symbol?
> The sum symbol (sigma)?  The plus, etc.?  They mean the same thing
> for people whose "normal" communication language is not necessarily
> English.  Who will benefit from your proposal?  English-speaking
> newbies.  What about those whose mother tongue is not English?  The
> fewer keywords they need to learn the better.  Often they don't
> know the meaning (or the translation) of the keyword outside the
> context of a computer program.  That's not a bad thing.
>
> Is there any benefit of what you propose beyond making it simpler
> for those who are just starting to learn C++?  Isn't your suggestion
> similar to one about replacing curly braces with "begin" and "end"
> (or "begin_compound_statement" and "end_compound_statement")?  What
> about replacing the asterisk with "times" when it's a multiplication
> and with "deref" when it's a dereference?


I hate begin - end and i do not like Pascal. :) Anyway what i am saying is
that if the template syntax does not get improved newcomers will always
begin with


int *p=new int[10];

stuff instead of the standard containers. Failure to recognise this will
never allow templates to take off.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

I have been checking VDM-SL lately a math-style procedural modeling
language which has this style for a user type definition:


An array of int can be defined:

int_type: seq of int


I thought that from this style of syntax a far cleaner syntax for templates
can be invented. Consider these examples:


vector of int p;

vector of int p(50);

vector of vector of int s;

vector of vector of int s(50, vector of int(10));

basic_string of char s;



In this style templates become far more comprehensible for newcomers (and
why not for non-newcomers too).


Also for template definitions a nice equivalent of keywords "class" and
typename" can be invented, so as this use to fit elegantly with the
definition. The keyword "of":


template <of T>
class S
{ // ... };


S of int p;


Another example with typedef:

typedef basic_string of char string;


I think this would be an important improvement towards a cleaner syntax,
and also its simplicity would help towards to the adoption of
templates from newcomers, in place of inherently unsafe built-in arrays etc.

This syntax or a similar one (for templates only) could be adopted while
preserving the current syntax for backwards compatibility at the next
revision of the standard.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""Ioannis Vranos"" <noicys@h01tmail.com> wrote in message
news:1042825062.761216@athprx02...
>
> I thought that from this style of syntax a far cleaner syntax for
templates
> can be invented. Consider these examples:
>
> vector of int p;

First *major* problem I see with this is I'm sure thousands of programs
out there already use "of" as an identifier...output file, object
factory, etc.  Making "of" a keyword would break all of those programs.

Second, the english-ness of the syntax breaks down when you using
non-simple containers...should it be

map of int of int of my_comparer m;

and while nesting works in your

vector of vector of int v;

example, what about slightly more complex nesting?

map of basic_string of char of basic_string of char m;

or maybe

map of (basic_string of char) of (basic_string of char) m;

I'm not sure that's getting cleaner than the <> syntax...really, the
only ugly part of the <> syntax as I see it is the fact you can't use >>
to close two levels of templates (due to it being interpreted as right
shift).  Sure, it's not immediately obvious to someone who knows english
but not C++...but once explained, it is pretty clear.

Ken


---
[ 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                       ]

"Ioannis Vranos" <noicys@h01tmail.com> wrote...
> I have been checking VDM-SL lately a math-style procedural modeling
> language which has this style for a user type definition:
>
>
> An array of int can be defined:
>
> int_type: seq of int
>
>
> I thought that from this style of syntax a far cleaner syntax for
templates
> can be invented. Consider these examples:
>
>
> vector of int p;
>
> vector of int p(50);
>
> vector of vector of int s;
>
> vector of vector of int s(50, vector of int(10));
>
> basic_string of char s;
>
>
>
> In this style templates become far more comprehensible for newcomers (and
> why not for non-newcomers too).
>
>
> Also for template definitions a nice equivalent of keywords "class" and
> typename" can be invented, so as this use to fit elegantly with the
> definition. The keyword "of":
>
>
> template <of T>
> class S
> { // ... };
>
>
> S of int p;
>
>
> Another example with typedef:
>
> typedef basic_string of char string;
>
>
> I think this would be an important improvement towards a cleaner syntax,
> and also its simplicity would help towards to the adoption of
> templates from newcomers, in place of inherently unsafe built-in arrays
etc.
>
> This syntax or a similar one (for templates only) could be adopted while
> preserving the current syntax for backwards compatibility at the next
> revision of the standard.


What would be the syntax of a template with more than one template
parameter?  Don't you think we need to replace most of the syntax
that involves special punctuation with one using regular words:

    vector from std of int with myintallocator myvector;

    basic_string from std of char with mychartraits with
             allocator of char mystring;

?  Is that really easier for the beginners to comprehend than

    std::vector<int, myintallocator> myvector;
    std::basic_string<char, mychartraits, allocator<char> > mystring;

?  This is not intended as sarcasm, I am really curious.  Having
outgrown and forgotten my beginner difficulties, I feel a bit out
of touch...

Thanks.

Victor
--
Please remove capital A's from my address when replying by mail


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

noicys@h01tmail.com ("Ioannis Vranos") wrote
> [In some other language,] An array of int can be defined:
>     int_type: seq of int
> I thought that from this style of syntax a far cleaner syntax for templates
> can be invented.
> In this style templates become far more comprehensible for newcomers (and
> why not for non-newcomers too).

I like this syntax. It's easy to write and understand. There doesn't
seem to be much room for ambiguities, either, and errors in the
declaration type should be very apparent. I would advocate this type
of syntax for any new language.

I don't think that language would be C or C++, though. Even ignoring
legacy issues (and it's hard to imagine a proposal which has bigger
legacy issues than this one!), the basic syntax is really the major
thing that keeps languages distinct.

What are the major differences between (say) C++ and Cobol? There are
a thousand different things, but most of the important ones come down
to syntax. At some level,
    ADD A TO B GIVING C
    COMPUTE D = E + F * G
    IF C<D THEN PERFORM C-LESS-THAN-D THROUGH C-LESS-THAN-D-END.
is similar to
    c = a + b;
    d = e + f*g;
    if (c<d) c_less_than_d();
Surely even without comments, the parallels are easy to see -- but the
distinctions are even more obvious. If the COBOL notation really
had that much advantage and no disadvantage, we'd all switch languages.
But even in the unlikely event that the majority of us found the
"Add...Giving" notation easier to write or understand than the C++
expression-statement, we still probably would never change the language
that radically, at least not without prior art.

(Meaning that someone somewhere could invent a C++BOL compiler
which works just like C++ except for the new statement, and make it
available for others. If it worked well and was popular with it's
users, MAYBE it would be considered for a future standard... but
that's a lot of IF!)

We may decide to tweak C++ declaration syntax to clean up some
ambiguities and common errors, but without prior art I doubt we would
ever make changes as dramatic as you proposed, no matter how useful
the result. The code you propose simply isn't C++.

IMHO.

---
[ 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                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301171545.4131b764@posting.google.com...
> noicys@h01tmail.com ("Ioannis Vranos") wrote
>
> I like this syntax. It's easy to write and understand. There doesn't
> seem to be much room for ambiguities, either, and errors in the
> declaration type should be very apparent. I would advocate this type
> of syntax for any new language.


Why a foreign language to steal this elegance in the future? (e.g. Java).



> I don't think that language would be C or C++, though. Even ignoring
> legacy issues (and it's hard to imagine a proposal which has bigger
> legacy issues than this one!), the basic syntax is really the major
> thing that keeps languages distinct.


I did not said to change the syntax of the whole language. I am talking
about templates only here and also i said the old syntax to remain for
compatibility.



>
> What are the major differences between (say) C++ and Cobol? There are
> a thousand different things, but most of the important ones come down
> to syntax. At some level,
>     ADD A TO B GIVING C
>     COMPUTE D = E + F * G
>     IF C<D THEN PERFORM C-LESS-THAN-D THROUGH C-LESS-THAN-D-END.
> is similar to
>     c = a + b;
>     d = e + f*g;
>     if (c<d) c_less_than_d();


Irrelevant. I am talking about templates only.


> Surely even without comments, the parallels are easy to see -- but the
> distinctions are even more obvious. If the COBOL notation really
> had that much advantage and no disadvantage, we'd all switch languages.
> But even in the unlikely event that the majority of us found the
> "Add...Giving" notation easier to write or understand than the C++
> expression-statement, we still probably would never change the language
> that radically, at least not without prior art.
>
> (Meaning that someone somewhere could invent a C++BOL compiler
> which works just like C++ except for the new statement, and make it
> available for others. If it worked well and was popular with it's
> users, MAYBE it would be considered for a future standard... but
> that's a lot of IF!)
>
> We may decide to tweak C++ declaration syntax to clean up some
> ambiguities and common errors, but without prior art I doubt we would
> ever make changes as dramatic as you proposed, no matter how useful
> the result. The code you propose simply isn't C++.


I am talking about template syntax only and i said the old syntax to remain
for backwards compatibility. I believe that the chance C++ to get a right
template syntax must not be lost because of another language in the future
having that. We are here *now*, so why not "fix" it right?



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

""Ken Alverson"" <Ken@Alverson.net> wrote in message
news:b09map$guf$1@eeyore.INS.cwru.edu...
> ""Ioannis Vranos"" <noicys@h01tmail.com> wrote in message
> news:1042825062.761216@athprx02...
> >
> > I thought that from this style of syntax a far cleaner syntax for
> templates
> > can be invented. Consider these examples:
> >
> > vector of int p;
>
> First *major* problem I see with this is I'm sure thousands of programs
> out there already use "of" as an identifier...output file, object
> factory, etc.  Making "of" a keyword would break all of those programs.


This isn't difficult. A macro could be used signaling old syntax
compatibility. Something like:


#define TEMPLATES_OLD_ONLY



>
> Second, the english-ness of the syntax breaks down when you using
> non-simple containers...should it be
>
> map of int of int of my_comparer m;
>
> and while nesting works in your
>
> vector of vector of int v;
>
> example, what about slightly more complex nesting?
>
> map of basic_string of char of basic_string of char m;
>
> or maybe
>
> map of (basic_string of char) of (basic_string of char) m;


At first at complexities we always typedef. Complexity exists today too. So
complexity for a large mixture is not an excuse

vector<vector<vector<int> > > (50, vector<vector<int > >(40,
vector<int>(5)));


Your map:

map<basic_string<char>,  basic_string<char> >m;

isn't simpler.


On the contrary

map of basic_string of char,basic_string of char m;

is.


Parenthesis is not bad too:


map of (basic_string of char,basic_string of char) m;


They couls be ignored by the compiler since the order counts. But in reality
it would not be that:


map of string,string m;




--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

Ioannis Vranos wrote:
....
> This isn't difficult. A macro could be used signaling old syntax
> compatibility. Something like:
>
>
> #define TEMPLATES_OLD_ONLY

You've got it reversed; for backwards compatibility, the old syntax
would have to be the default.
Furthermore, macros aren't the appropriate mechanism. This should be a
#pragma.

---
[ 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                       ]

Ioannis> Your map:

Ioannis> map<basic_string<char>,  basic_string<char> >m;

Ioannis> isn't simpler.


Ioannis> On the contrary

Ioannis> map of basic_string of char,basic_string of char m;

Ioannis> is.

It is also ambiguous: Does it mean

        map <basic_string<char>, basic_string<char> > m;

or does it mean

        map<basic_string<char, basic_string<char> > > m;

Whichever one you pick, please explain how you would write the other one.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                       ]

noicys@h01tmail.com ("Ioannis Vranos") writes:

> I have been checking VDM-SL lately a math-style procedural modeling
> language which has this style for a user type definition:
>
>
> An array of int can be defined:
>
> int_type: seq of int
>
>
> I thought that from this style of syntax a far cleaner syntax for templates
> can be invented. Consider these examples:
>
>
> vector of int p;
[snip]

What would be the equivalent of 'vector<int,my_allocator> p;' ?

---
[ 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                       ]

""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
news:v2gn6klan5332c@corp.supernews.com...
> What would be the syntax of a template with more than one template
> parameter?


something of int,float s;



> Don't you think we need to replace most of the syntax
> that involves special punctuation with one using regular words:
>
>     vector from std of int with myintallocator myvector;
>
>     basic_string from std of char with mychartraits with
>              allocator of char mystring;
>
> ?  Is that really easier for the beginners to comprehend than
>
>     std::vector<int, myintallocator> myvector;
>     std::basic_string<char, mychartraits, allocator<char> > mystring;


No, i never suggested "with".




> ?  This is not intended as sarcasm, I am really curious.  Having
> outgrown and forgotten my beginner difficulties, I feel a bit out
> of touch...


I have no difficulties with templates myself too, but template syntax is one
of the main reasons why newcomers use built in arrays and other stuff and
not standard library containers (and that's why they are taught to do so).


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

"Andrew Koenig" <ark@research.att.com> wrote in message
news:yu997kd2wikq.fsf@europa.research.att.com...
> or does it mean
>
>         map<basic_string<char, basic_string<char> > > m;
>
> Whichever one you pick, please explain how you would write the other one.


Can the above ever be valid?


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

---
[ 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                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0301171545.4131b764@posting.google.com>...
> noicys@h01tmail.com ("Ioannis Vranos") wrote
> > [In some other language,] An array of int can be defined:
> >     int_type: seq of int
> > I thought that from this style of syntax a far cleaner syntax for templates
> > can be invented.
> > In this style templates become far more comprehensible for newcomers (and
> > why not for non-newcomers too).
>
> I like this syntax. It's easy to write and understand. There doesn't
> seem to be much room for ambiguities, either, and errors in the
> declaration type should be very apparent. I would advocate this type
> of syntax for any new language.
>
> I don't think that language would be C or C++, though. Even ignoring
> legacy issues (and it's hard to imagine a proposal which has bigger
> legacy issues than this one!),

I have to agree with Ioannas, where'd you get the idea that the
proposal was all-encompassing?  It's one additional keyword and some
different syntax for templates.

> the basic syntax is really the major thing that keeps languages distinct.

This is just bizarre.  So all languages are pretty much the same
except their syntax?  I'd posit that the gross difference of paradigm
is orders more distinguishing than syntax. C is not like Smalltalk is
not like Haskell is not like Prolog.  The differences go much deeper
than syntax.  And no one has trouble keeping Scheme and Lisp distinct
despite having virtually the same syntax.

More on-topic: besides '>>' what's wrong with the current template
syntax?  The worse that could be said is that it doesn't fit in all
that well with the rest of C++.  On that note, neither does this
proposal.  Also, why do people keep saying this syntax is difficult
for newbies?  They don't need to get used to it, it's just more
syntax, it's all new and cryptic to them anyways.  The worse problems
I can imagine with templates is template errors are enormous and
incomprehensible; different syntax won't change that.

This 'of' syntax is nice for basic usage with containers, but it seems
to be asking for ambiguity problems especially with default parameters
and nested templates.  Furthermore, for other template uses it seems
less sensical: bitset of 10? foo of foo_traits? add of x,y (template
metaprogramming)? if of cond,thenT,elseT (more template
metaprogramming)? Then what about function templates?  Template
metaprogramming really benefits from this aspect of the syntax (the
rest is obscene), in that it looks similar to function application:
less_than<5,10>::result, Factorial<10>::result; though in this case
Factorial of 10 has a nice ring, but another issue is brought up, what
is the syntax for accessing explicitly specialized members, it's
obviously not: Factorial of 10 :: result.

---
[ 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                       ]