Hi!

Thorsten Ottosen wrote:

 >My editor supports refactoring and code-completion for C++.
 >

Code completion I used for C++ is terribly slow.

Did you ever see Eclipse working on Java source code?
You can have it insert virtual functions of base classes into
your current class.
You can have it insert getter/setter functions.
You can have it remove compiler errors in several ways (add a
function, which you wanted to call but does not exist; rename to
match an existing function, ....)
You can have it rename a variable at all relevant places in souce.
You can have it refactor nested classes to non-nested ones.

There are so many useful things it does for you which make Java
programming fun. You get the feeling of doing your work instead
of doing a lot of small uninteresting things (which nevertheless
you also need, but which you don't want to type).

Anyway, I'm curious which Editor you are using.

Frank


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

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

Thorsten Ottosen wrote:
 > "John Torjo" <jtorjo@yahoo.com> wrote in message
 > news:c638aac5.0409072109.5e8195f6@posting.google.com...
 >>
 >> Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message
 > news:<chkira$peq$1@news1nwk.SFbay.Sun.COM>...
 >
 >>> Today we have more serious problems with template syntax than we did
 >>> in 1992. I think that if explicit template arguments on function calls
 >>> had been part of C++ in 1992, we would have changed the notation then.
 >>>
 >>
 >> That's why I (and probably Andrei) think it's quite imperative to
 >> change this.
 >> We could still allow for the old syntax (with a warning), create some
 >> automation tools (for updating files from old to new syntax) and allow
 >> for a newer/cleaner/easier to parse solution.
 >
 > If the only reason is faster parsing speed, then I don't see why one
 > should change anything. Time
 > is working to our advantage...the next time I buy a lap-top it will be 4
 > times as fast; even for many years
 > good compilers with pre-compiled  headers have been quite fast at
 > compiling stuff.

Should I say that one with this thinking shall try to workon commercial
applications for some time?  When your laptop will be 4 times faster, your
customers will demand features, which makes you cry for a 16 times faster
computer.  Growing CPU speed is never an excuse for pessimization, or for
not taking advantage of what we have learnt.

--
WW aka Attila
:::
Fear knocked at the door. Faith answered and no one was there.



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

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

"Frank Birbacher" <bloodymir.crap@gmx.net> wrote in message
news:2s5s88F1hh0vvU1@uni-berlin.de...
|
| Hi!
|
| Thorsten Ottosen wrote:
|
|  >My editor supports refactoring and code-completion for C++.
|  >

| Anyway, I'm curious which Editor you are using.

slick-edit 9.

-Thorsten



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

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

jtorjo@yahoo.com (John Torjo) wrote in message
news:<c638aac5.0409142247.1bcd4fe@posting.google.com>...
 > nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message
 > news:<414469cb$0$202$14726298@news.sunsite.dk>...

 > > For programs with heavy use of templates, I vaguely recall that
 > > Daveed V. said that something like his metacode would improve
 > > compilation speed. By how much I don't know.

 > That sounds nice.

 > But as I see it, the language has become so complex (I mean to
 > parse/compile) that we'll end up just patching things - to make the a
 > *little* faster.  In the long run, there's just no escape. And that's
 > a real pitty.

I'm not sure about that.  I think that much of the problem is that
templates were not originally designed as a meta-programming language.
Designing something new expressedly for meta-programming should result
in something that is considerably more readable (for starters), and
could easily result in something easier to compile as well.  Big-O
easier, I mean, and not just a tweak of the constant factor.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


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

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

The thread drifted toward ease of typing various syntax options, which
then depended on keyboards. This one and another like it were marginal.
I decided to allow them.

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

kwikius wrote:
> jtorjo@yahoo.com (John Torjo) wrote in message news:<c638aac5.0409162310.49deece0@posting.google.com>...
>
>>>Don't believe it.  I recently purchaced a new PC, the keyboard I got
>>>with it also requires strange combinations of keys for these characters.
>>>
>>>IMHO, the only solution which works (unless you really want carpal
>>>tunnel syndrome) is to learn to type without looking at the keyboard,
>>>and install the drivers for a US keyboard.
>>>
>>
>>Of course ;) I've been successfully doing this for over 4 years, and
>>it's done wonders for me ;) In fact I have a split US keyboard - one
>>you can't find these days. It is really split in two - bought it 4
>>years ago. Recently I wanted to buy a new one (since this one got kind
>>of "not clean" - to put it nicely ;)). Every store I tried - they
>>don't have it.
>>
>>Best,
>>John
>
>
> IMO this post is way OT, and I am rather surprised that it was accepted.
>
> regards
> Andy Little
>

--

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

kanze@gabi-soft.fr writes:

| jtorjo@yahoo.com (John Torjo) wrote in message
| news:<c638aac5.0409142247.1bcd4fe@posting.google.com>...
|  > nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message
|  > news:<414469cb$0$202$14726298@news.sunsite.dk>...
|
|  > > For programs with heavy use of templates, I vaguely recall that
|  > > Daveed V. said that something like his metacode would improve
|  > > compilation speed. By how much I don't know.
|
|  > That sounds nice.
|
|  > But as I see it, the language has become so complex (I mean to
|  > parse/compile) that we'll end up just patching things - to make the a
|  > *little* faster.  In the long run, there's just no escape. And that's
|  > a real pitty.
|
| I'm not sure about that.  I think that much of the problem is that
| templates were not originally designed as a meta-programming language.

That is largely irrelevant. One runs into the "<:" or ">>" "binary >"
issues without even considering meta-programming programming.

I disbelieve that meta-programming facility is at root here.  Sure,
syntactic improvement may help template abuse but I do not think it is
the root issue.

| Designing something new expressedly for meta-programming should result
| in something that is considerably more readable (for starters), and
| could easily result in something easier to compile as well.  Big-O
| easier, I mean, and not just a tweak of the constant factor.

I'm eager to see contributions in that area.  Looking around to see
what other communities are doing (MetaOcaml, Template Haskell, xtc, ...)
does not give me the impression that "considerably more readable (for
starters)" is really a feature there, for languages designed to
provide meta-programming facilities.  Taste just varies, I guess.

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


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

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

kanze@gabi-soft.fr wrote in message news:<d6652001.0409162317.1ba8ee29@posting.google.com>...
 > jtorjo@yahoo.com (John Torjo) wrote in message
 > news:<c638aac5.0409142247.1bcd4fe@posting.google.com>...
 >  > nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message
 >  > news:<414469cb$0$202$14726298@news.sunsite.dk>...
 >
 >  > > For programs with heavy use of templates, I vaguely recall that
 >  > > Daveed V. said that something like his metacode would improve
 >  > > compilation speed. By how much I don't know.
 >
 >  > That sounds nice.
 >
 >  > But as I see it, the language has become so complex (I mean to
 >  > parse/compile) that we'll end up just patching things - to make the a
 >  > *little* faster.  In the long run, there's just no escape. And that's
 >  > a real pitty.
 >
 > I'm not sure about that.  I think that much of the problem is that
 > templates were not originally designed as a meta-programming language.
 > Designing something new expressedly for meta-programming should result
 > in something that is considerably more readable (for starters), and
 > could easily result in something easier to compile as well.  Big-O
 > easier, I mean, and not just a tweak of the constant factor.
 >

My thoughts exactly!
At the speed of computers these days, it should be "hit Compile button
and run"-kind of thing.

Best,
John

John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
    + easily add validation rules (win32gui/examples/smart_dlg)


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

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

jtorjo@yahoo.com (John Torjo) wrote
 > A lot of boost libraries take a lot of time to compile. In a recent
 > project I've been involved in - just including
 > <boost/multi_array.hpp> takes about 1.5-2 secs.
 > And that's on a 2.8 Ghz intel (two processors)/ VC71.

Is VC71 multi-threaded? (I know the GUI is a different thread than the
compiler -- I mean, is the compiler multi-threaded?) I suspect it isn't,
so the second processor is idle during your compiles (unless you're
doing two independant compiles at once).

 > This all leads me to conclude that perhaps it's time we learn from
 > C++, and start to develop a new language with a cleaner syntax, easier
 > to parse,etc.

How many languages already claim to have done just that?

I'd like to see the existing language cleaned up, by making some of the
older features deprecated. But I also recognize that selecting exactly
WHICH features to deprecate is a huge job, probably involving more
politics than science, and will go largely thankless.

On the other hand, if we introduce new superior ways to do, for instance,
meta-programming -- if these new language features are well-designed,
easier to read and understand, and well-supported -- this will
discourage people from doing things the old slow difficult-to-read way
without having to deprecate anything.


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

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

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3mzznto9z.fsf@uniton.integrable-solutions.net>...
 > kanze@gabi-soft.fr writes:

 > | jtorjo@yahoo.com (John Torjo) wrote in message
 > | news:<c638aac5.0409142247.1bcd4fe@posting.google.com>...
 > |  > nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message
 > |  > news:<414469cb$0$202$14726298@news.sunsite.dk>...

 > |  > > For programs with heavy use of templates, I vaguely recall that
 > |  > > Daveed V. said that something like his metacode would improve
 > |  > > compilation speed. By how much I don't know.

 > |  > That sounds nice.

 > |  > But as I see it, the language has become so complex (I mean to
 > |  > parse/compile) that we'll end up just patching things - to make
 > |  > the a *little* faster.  In the long run, there's just no
 > |  > escape. And that's a real pitty.

 > | I'm not sure about that.  I think that much of the problem is that
 > | templates were not originally designed as a meta-programming
 > | language.

 > That is largely irrelevant. One runs into the "<:" or ">>" "binary >"
 > issues without even considering meta-programming programming.

But what do they have to do with compilation speed?

 > I disbelieve that meta-programming facility is at root here.  Sure,
 > syntactic improvement may help template abuse but I do not think it is
 > the root issue.

In itself, no.  But when templates were being designed, meta-programming
wasn't taken into account.  An implementation which is O(n^2), where n
is the level of template nesting, is perfectly acceptable for
applications where templates aren't nested more than one or two levels.
It's going to make instantiation in meta code awfully slow, though.

 > | Designing something new expressedly for meta-programming should
 > | result in something that is considerably more readable (for
 > | starters), and could easily result in something easier to compile as
 > | well.  Big-O easier, I mean, and not just a tweak of the constant
 > | factor.

 > I'm eager to see contributions in that area.  Looking around to see
 > what other communities are doing (MetaOcaml, Template Haskell, xtc,
 > ...)  does not give me the impression that "considerably more readable
 > (for starters)" is really a feature there, for languages designed to
 > provide meta-programming facilities.  Taste just varies, I guess.

In general, I think that anytime the "program" and the "data" are
embedded in one another, readability is going to suffer.  Templates
aren't alone here; I've encountered similar problems with TeX or the old
Intel text macros (in ASM 86 -- one of the most powerful "preprocessors"
I've ever encountered).  For readability, it would be far better if we
could use some sort of external mechanism, with two different input
files, one which described the transformations we wanted on the source,
and the other with the source.  Of course, do this, and you no longer
have access to all of the compiler internal information, like types,
etc., so most of what we do in template meta-programming today wouldn't
be possible.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

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

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

nesotto@cs.auc.dk ("Thorsten Ottosen") wrote in message news:<414469cb$0$202$14726298@news.sunsite.dk>...
> "Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
> news:ZpGdnXIM18P03t_cRVn-hA@speakeasy.net...
> |
> | Thorsten Ottosen wrote:
> |
> |  > If the only reason is faster parsing speed, then I don't see why one
> |  > should change anything. Time
> |  > is working to our advantage...the next time I buy a lap-top it will be 4
> |  > times as fast; even for many years
> |  > good compilers with pre-compiled  headers have been quite fast at
> |  > compiling stuff.
> |
> |
> | What about parsing/compiling portable code on the fly in situations where
> | you want virtually immediate results?  I don't believe that is beyond the
> | realm of foreseeable requirements.
>
> yeah, It's always nice with faster builds, but the confusion that two
> different syntaxes
> can bring is also worth considering.
>
> Another template syntax will probably hurt portability.
>
> For programs with heavy use of templates, I vaguely recall that Daveed V. said
> that
> something like his metacode would improve compilation speed. By how much I
> don't know.
>

That sounds nice.

But as I see it, the language has become so complex (I mean to
parse/compile) that we'll end up just patching things - to make the a
*little* faster.
In the long run, there's just no escape. And that's a real pitty.

What I want (which to me sounds more and more: a new language ;)) is
language clarity and FAST compilation speeds. And when I say fast, I
really mean fast.

For instance, I have a project with heavy use of templates that takes
about 1.5 mins to compile. It's really not that complex, and I know it
should really take no more than 3 secs or so.

It seems (to me) that compilers never get to catch up with
implementing the standard, and every feature they implement just makes
them slower.


Best,
John


John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
   + easily add validation rules (win32gui/examples/smart_dlg)


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

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

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3u0u1yeil.fsf@uniton.integrable-solutions.net>...
[...]
> Two years ago (2002), when I was giving a C++ class in an engineering
> university in Lyon (France), I faced that situation where students
> had to use old French HP keyboards with both {} and [] are accessible
> only through a cabalistic combination of keys.  But I was told that it
> is because the keyboards are rather old :-/

This used to be the case with italian keyboards too. Rather than
having to enter sequences of three key combinations just to get curly
brackets I found it easier to memorize the layout of a US keyboard and
changed configuration.

Cheers,
Nicola Musatti


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

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

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message news:<ZpGdnXIM18P03t_cRVn-hA@speakeasy.net>...
> Thorsten Ottosen wrote:
>
>  > If the only reason is faster parsing speed, then I don't see why one
>  > should change anything. Time
>  > is working to our advantage...the next time I buy a lap-top it will be 4
>  > times as fast; even for many years
>  > good compilers with pre-compiled  headers have been quite fast at
>  > compiling stuff.
>
>
> What about parsing/compiling portable code on the fly in situations where
> you want virtually immediate results?  I don't believe that is beyond the
> realm of foreseeable requirements.
>

indeed. And this would open a door of possibilities (refactoring/cool
parsing/code-completion/etc.). Just look at how many tools for java
are outthere. And parsing/compiling on the fly just makes that happen.

Best,
John


John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
   + easily add validation rules (win32gui/examples/smart_dlg)


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

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

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3u0u1yeil.fsf@uniton.integrable-solutions.net>...
> Bob Hairgrove <invalid@bigfoot.com> writes:

> | On Sat, 11 Sep 2004 15:06:20 +0000 (UTC), kanze@gabi-soft.fr wrote:

> |  >> Not on my German keyboard! In fact, the symbols <,>,| are all on
> |  >> one key, making <| and |> seem most natural.

> |  >On your German keyboard.  The position of | on German keyboards is
> |  >not standardized -- according to DIN, German keyboards don't even
> |  >have a |.  (In practice, it would be a silly keyboard driver which
> |  >put it anywhere else but where the Windows keyboard driver puts
> |  >it.  Which is on the same key as < and >.)

> | On my Swiss keyboard, | is only accessible by holding AltGr and
> | typing 7. The key with < and > has the backslash on it. There is a
> | similar character to | under the number 1, but I don't believe it is
> | the same character (you also need to hold AltGr to type it).

> | Actually, it is a huge PITA to do any C++ programming on a Swiss
> | keyboard since both {} and [] are only accessible by holding down
> | AltGr.

> Two years ago (2002), when I was giving a C++ class in an engineering
> university in Lyon (France), I faced that situation where students had
> to use old French HP keyboards with both {} and [] are accessible only
> through a cabalistic combination of keys.  But I was told that it is
> because the keyboards are rather old :-/

Don't believe it.  I recently purchaced a new PC, the keyboard I got
with it also requires strange combinations of keys for these characters.

IMHO, the only solution which works (unless you really want carpal
tunnel syndrome) is to learn to type without looking at the keyboard,
and install the drivers for a US keyboard.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


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

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

Thorsten Ottosen <nesotto@cs.auc.dk> wrote in message news:<41460eef$0$211$14726298@news.sunsite.dk>...
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> news:c638aac5.0409131049.546d60d2@posting.google.com...
>
> | True. But I think that's very hard - with so much legacy code.
> | What I really want (and I'm sure I'm not alone on this) is faster
> | compilation times.
>
> Vladirmir is working on adding PCH support to bjam v2.

Unfortunately I don't think that'll help very much.

>
> I've certainly worked with slow compilers, but I've also found that a compiler
> like vc7.1 is *really* fast
> with PCH even without the use of
>

I would be to disagree.
It is indeed very fast compared to other compilers, but can still be
improved (I wonder how vc8.0 is doing at this?)

In fact vc71 is my current compiler, so I know what I'm talking about.

Just try to compile:
#include <boost/multi_array.hpp>
int main() {
    boost::multi_array<int,2> a;
 return 0;
}

And let me know how long it takes ;)


As for PCH, it does indeed help, but it seems to me that we will end
up with a PCH that will include all boost libs soon ;)

Heavy use of templates still doesn't play nice with PCH.
What I mean, you #include the header, but a lot of compilation-time is
spent when you try to use a template-class/template-member-function
(especially when you couple this with using static class-members).
So, it's just a partial solution.

>
> I'm sure many other compilers are also fast with PCH when used correctly.

I only wish ;)

Best,
John



John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
   + easily add validation rules (win32gui/examples/smart_dlg)


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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409142259.ab809ff@posting.google.com...

| >
| > I've certainly worked with slow compilers, but I've also found that a
compiler
| > like vc7.1 is *really* fast
| > with PCH even without the use of
| >
|
| I would be to disagree.
| It is indeed very fast compared to other compilers, but can still be
| improved (I wonder how vc8.0 is doing at this?)
|
| In fact vc71 is my current compiler, so I know what I'm talking about.
|
| Just try to compile:
| #include <boost/multi_array.hpp>
| int main() {
|     boost::multi_array<int,2> a;
| return 0;
| }
|
| And let me know how long it takes ;)

with vc7.1

    0m0.690s

with como4.3.3

    0m2.668s

and please note that my computer is an antique 900Mhz laptop with not too fast
a harddisk.

| As for PCH, it does indeed help, but it seems to me that we will end
| up with a PCH that will include all boost libs soon ;)

I hope so. What should be wrong with that?

| Heavy use of templates still doesn't play nice with PCH.
| What I mean, you #include the header, but a lot of compilation-time is
| spent when you try to use a template-class/template-member-function
| (especially when you couple this with using static class-members).
| So, it's just a partial solution.

that's another part of compile-time: template instantiation speed. AFAIK, this
has nothing to do with
the parsing difficulties of C++.

br

Thorsten



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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409142249.10a501ce@posting.google.com...
|
| "Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
news:<ZpGdnXIM18P03t_cRVn-hA@speakeasy.net>...

| > What about parsing/compiling portable code on the fly in situations where
| > you want virtually immediate results?  I don't believe that is beyond the
| > realm of foreseeable requirements.
| >
|
| indeed. And this would open a door of possibilities (refactoring/cool
| parsing/code-completion/etc.).

My editor supports refactoring and code-completion for C++.

I'm not sure what you mean by parsing etc.

| Just look at how many tools for java
| are outthere. And parsing/compiling on the fly just makes that happen.

I'll answer that with Fact 7 from Robert Glass' "Facts and Fallacies of
Software engeneering":

"Software developers talk a lot about tools. They evaluate quite a few, buy a
fair number, and use practically none".

br

Thorsten



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

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

>
> Don't believe it.  I recently purchaced a new PC, the keyboard I got
> with it also requires strange combinations of keys for these characters.
>
> IMHO, the only solution which works (unless you really want carpal
> tunnel syndrome) is to learn to type without looking at the keyboard,
> and install the drivers for a US keyboard.
>

Of course ;) I've been successfully doing this for over 4 years, and
it's done wonders for me ;) In fact I have a split US keyboard - one
you can't find these days. It is really split in two - bought it 4
years ago. Recently I wanted to buy a new one (since this one got kind
of "not clean" - to put it nicely ;)). Every store I tried - they
don't have it.

Best,
John


John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
   + easily add validation rules (win32gui/examples/smart_dlg)

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

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

On Sat, 11 Sep 2004 15:06:20 +0000 (UTC), kanze@gabi-soft.fr wrote:

 >> Not on my German keyboard! In fact, the symbols <,>,| are all on one
 >> key, making <| and |> seem most natural.
 >
 >On your German keyboard.  The position of | on German keyboards is not
 >standardized -- according to DIN, German keyboards don't even have a |.
 >(In practice, it would be a silly keyboard driver which put it anywhere
 >else but where the Windows keyboard driver puts it.  Which is on the
 >same key as < and >.)

On my Swiss keyboard, | is only accessible by holding AltGr and typing
7. The key with < and > has the backslash on it. There is a similar
character to | under the number 1, but I don't believe it is the same
character (you also need to hold AltGr to type it).

Actually, it is a huge PITA to do any C++ programming on a Swiss
keyboard since both {} and [] are only accessible by holding down
AltGr.

--
Bob Hairgrove
NoSpamPlease@Home.com


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

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

"Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:<2qeaphFtv2ieU1@uni-berlin.de>...
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> news:c638aac5.0409082207.28fbedcb@posting.google.com...
>  > Or, we can use <| and |>
>  > Now, find a broken construct using <| |> !
>  > (although, again, I'm pretty against this, since | is very complicated
>  > to type - for me)
>
> There's no problem with <| and |>. I use them for generics in a little
> language for hardware specification, and people like them a lot.

Cool!
What language?

>
> On an unrelated vein, I use "!" for passing-in default arguments to
> function, and people say it looks great:
>
> void Foo(int = 0, string = "wyda", double = 0);
>
> can be called:
>
> Foo(2, !, 1); // calls Foo(2, "wyda", 1);

In the same language?
Anyway, it's quite a nice thing - I like this idea

Best,
John


John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
   + easily add validation rules (win32gui/examples/smart_dlg)


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

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

"Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:<2qbgnaFtesriU1@uni-berlin.de>...
> "John Torjo" <jtorjo@yahoo.com> wrote in message
> news:c638aac5.0409072109.5e8195f6@posting.google.com...
> > That's why I (and probably Andrei) think it's quite imperative to
> > change this.
>
> Indeed, I second that.
>
> > We could still allow for the old syntax (with a warning), create some
> > automation tools (for updating files from old to new syntax) and allow
> > for a newer/cleaner/easier to parse solution.
> >
> > (as a side-note, I think the best people to build those automation
> > tools would be the compiler writers ;))
>
> C++ is a wonderful language, and it has made some pioneering breakthroughs
> in areas where other languages either didn't try, didn't succeed, or
> succeeded but nobody cared :o). In doing so, it inevitably accumulated some
> scars.

Indeed.

>
> I now believe it is very important now for C++ to provide a coherent means
> to close those wounds.
>

True. But I think that's very hard - with so much legacy code.
What I really want (and I'm sure I'm not alone on this) is faster
compilation times.

In fact, I'm ok with the language as is (although a few additions
would be nice ;)), but with faster compilation times.

Due to the complexity C++ has acquired, I'm afraid we'll never get to
actually see those faster compilation times.

Sorry to say, but there are C++ features that I avoid to use exactly
because they require too much compilation time (and I mean, in matter
of seconds).

For win32gui, I avoided to use just boost::function because of that
(very high compilation times. I did develop my own though ;)

A lot of boost libraries take a lot of time to compile. In a recent
project I've been involved in - just including
<boost/multi_array.hpp> takes about 1.5-2 secs.
And that's on a 2.8 Ghz intel (two processors)/ VC71.

That is really a lot, IMO.

This all leads me to conclude that perhaps it's time we learn from
C++, and start to develop a new language with a cleaner syntax, easier
to parse,etc.


Best,
John



John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4.0 - true binding of your data to UI controls!
   + easily add validation rules (win32gui/examples/smart_dlg)


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

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

Bob Hairgrove <invalid@bigfoot.com> writes:

| On Sat, 11 Sep 2004 15:06:20 +0000 (UTC), kanze@gabi-soft.fr wrote:
|
|  >> Not on my German keyboard! In fact, the symbols <,>,| are all on one
|  >> key, making <| and |> seem most natural.
|  >
|  >On your German keyboard.  The position of | on German keyboards is not
|  >standardized -- according to DIN, German keyboards don't even have a |.
|  >(In practice, it would be a silly keyboard driver which put it anywhere
|  >else but where the Windows keyboard driver puts it.  Which is on the
|  >same key as < and >.)
|
| On my Swiss keyboard, | is only accessible by holding AltGr and typing
| 7. The key with < and > has the backslash on it. There is a similar
| character to | under the number 1, but I don't believe it is the same
| character (you also need to hold AltGr to type it).
|
| Actually, it is a huge PITA to do any C++ programming on a Swiss
| keyboard since both {} and [] are only accessible by holding down
| AltGr.

Two years ago (2002), when I was giving a C++ class in an engineering
university in Lyon (France), I faced that situation where students
had to use old French HP keyboards with both {} and [] are accessible
only through a cabalistic combination of keys.  But I was told that it
is because the keyboards are rather old :-/

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


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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409131049.546d60d2@posting.google.com...

| True. But I think that's very hard - with so much legacy code.
| What I really want (and I'm sure I'm not alone on this) is faster
| compilation times.

Vladirmir is working on adding PCH support to bjam v2.

I've certainly worked with slow compilers, but I've also found that a compiler
like vc7.1 is *really* fast
with PCH even without the use of

<std.hh>

and

<boost.hpp>

headers.

I'm sure many other compilers are also fast with PCH when used correctly.

br

Thorsten






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

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

paul_evans7@hotmail.com (bone bag) wrote in message
news:<4374f570.0409080443.6cd7f12a@posting.google.com>...
> jtorjo@yahoo.com (John Torjo) wrote in message
> news:<c638aac5.0409062202.5ef631b2@posting.google.com>...

> > Following this thread, I completely agree with Andrei.  I guess
> > parsing would be quite faster, language become cleaner, if we use=
d a
> > new syntax.

> > Since we're all used to <>, how about using </ and /> (or, somebo=
dy
> > else suggested <| and |> - although I think </ and /> are much
> > faster to type)
> [snip]

> Not on my German keyboard! In fact, the symbols <,>,| are all on on=
e
> key, making <| and |> seem most natural.

On your German keyboard.  The position of | on German keyboards is no=
t
standardized -- according to DIN, German keyboards don't even have a =
|.
(In practice, it would be a silly keyboard driver which put it anywhe=
re
else but where the Windows keyboard driver puts it.  Which is on the
same key as < and >.)

But I consider this a disadvantage -- I find it far easier to type
successive characters if they are on different keys.  Or rather, if I
don't have to play with shift, control or alt in the middle of the
sequence.  I find the placement of < and > on the same key (differing
only by the shift) a pain on German and French keyboards.  Of course,
the fact that you need to use alt to get some pretty common character=
s
in C++ (like { and }) means that I avoid such keyboards for entering =
C++
anyway:-).  (On a French keyboard, you have to shift to get numbers,
which makes it more or less awkward for many technical jobs.)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 =
34


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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409082207.28fbedcb@posting.google.com...
 > Or, we can use <| and |>
 > Now, find a broken construct using <| |> !
 > (although, again, I'm pretty against this, since | is very complicated
 > to type - for me)

There's no problem with <| and |>. I use them for generics in a little
language for hardware specification, and people like them a lot.

On an unrelated vein, I use "!" for passing-in default arguments to
function, and people say it looks great:

void Foo(int = 0, string = "wyda", double = 0);

can be called:

Foo(2, !, 1); // calls Foo(2, "wyda", 1);


Andrei



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

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

Thorsten Ottosen wrote:

 > If the only reason is faster parsing speed, then I don't see why one
 > should change anything. Time
 > is working to our advantage...the next time I buy a lap-top it will be 4
 > times as fast; even for many years
 > good compilers with pre-compiled  headers have been quite fast at
 > compiling stuff.


What about parsing/compiling portable code on the fly in situations where
you want virtually immediate results?  I don't believe that is beyond the
realm of foreseeable requirements.

--
Regards,
Steven


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

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

Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message news:<chkira$peq$1@news1nwk.SFbay.Sun.COM>...
> I had not followed the previous thread, so please forgive me if the
> following discussion is not new.
>
> At the November 1992 meeting of the C++ Committee, some syntax
> ambiguities of the <...> notation for template parameters and
> arguments were discussed, and some alternatives were presented.
>
> If I remember correctly, two suggestions that introduced no
> ambiguities were {...} and two new digraphs <|...|> (similar to your
> suggested </.../>). Tom Pennello, sitting in the back of the room, had

His name came up on the other discussion ;)

> a table-driven C++ parser on his laptop computer, and tested the
> suitability of suggested syntax modifications in real time. The {...}
> notation was considerd visually confusing, but the <|...|> notation
> had some support.
>
> At that time, explicit template arguments on function calls, such as
> foo<A,B>(), were not in the language. The arguments that won the day
> against any change were that the ambiguities were minor, and that "too
> many books and articles and too much code" already existed.
>
> Today we have more serious problems with template syntax than we did
> in 1992. I think that if explicit template arguments on function calls
> had been part of C++ in 1992, we would have changed the notation then.
>

That's why I (and probably Andrei) think it's quite imperative to
change this.
We could still allow for the old syntax (with a warning), create some
automation tools (for updating files from old to new syntax) and allow
for a newer/cleaner/easier to parse solution.

(as a side-note, I think the best people to build those automation
tools would be the compiler writers ;))

Best,
John


John Torjo
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/


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

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

jtorjo@yahoo.com (John Torjo) wrote in message
news:<c638aac5.0409062202.5ef631b2@posting.google.com>...

 > Following this thread, I completely agree with Andrei.  I guess
 > parsing would be quite faster, language become cleaner, if we used a
 > new syntax.

 > Since we're all used to <>, how about using </ and />
 > (or, somebody else suggested <| and |> - although I think </ and />
 > are much faster to type)

 > I think it's not possible to have </ and /> in the current language,
 > so this wouldn't break anything.

     bool b = a <//  Compare a and b
              b ;

That's a perfectly legal statement today.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


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

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

jtorjo@yahoo.com (John Torjo) wrote in message news:<c638aac5.0409062202.5ef631b2@posting.google.com>...
> Following this thread, I completely agree with Andrei.
> I guess parsing would be quite faster, language become cleaner, if we
> used a new syntax.
>
> Since we're all used to <>, how about using </ and />
> (or, somebody else suggested <| and |> - although I think </ and />
> are much faster to type)
[snip]

Not on my German keyboard! In fact, the symbols <,>,| are all on one
key, making <| and |> seem most natural.


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

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

Eric Backus <eric_backus@alum.mit.edu> wrote in message news:<1094582026.849711@cswreg.cos.agilent.com>...
 > "John Torjo" <jtorjo@yahoo.com> wrote in message
 > news:c638aac5.0409062202.5ef631b2@posting.google.com...
 > > Since we're all used to <>, how about using </ and />
 > > (or, somebody else suggested <| and |> - although I think </ and />
 > > are much faster to type)
 > >
 > > I think it's not possible to have </ and /> in the current language,
 > > so this wouldn't break anything.
 >
 > How about an explicit specialization:
 >
 >     template</*intentionally_empty*/> int my_max<int>(int x1, int x2) {
 > return (x1 > x2) ? x1 : x2; }
 >
 > Or, possibly some case of template deduction?:
 >
 >     x = func</*intentionally_empty*/>(arg1, arg2);
 >

Man, you got me here.
Although probably noone wrote such a thing, you're right.

Of course, the compiler can be smart and see if it encounters </* or
*/> and treat /* as comments.

Or, we can use <| and |>
Now, find a broken construct using <| |> !
(although, again, I'm pretty against this, since | is very complicated
to type - for me)

Best,
John

John Torjo
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/


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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409072109.5e8195f6@posting.google.com...
|
| Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message
news:<chkira$peq$1@news1nwk.SFbay.Sun.COM>...

| > Today we have more serious problems with template syntax than we did
| > in 1992. I think that if explicit template arguments on function calls
| > had been part of C++ in 1992, we would have changed the notation then.
| >
|
| That's why I (and probably Andrei) think it's quite imperative to
| change this.
| We could still allow for the old syntax (with a warning), create some
| automation tools (for updating files from old to new syntax) and allow
| for a newer/cleaner/easier to parse solution.

If the only reason is faster parsing speed, then I don't see why one should
change anything. Time
is working to our advantage...the next time I buy a lap-top it will be 4 times
as fast; even for many years
good compilers with pre-compiled  headers have been quite fast at compiling
stuff.

br

Thorsten



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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409072109.5e8195f6@posting.google.com...
> That's why I (and probably Andrei) think it's quite imperative to
> change this.

Indeed, I second that.

> We could still allow for the old syntax (with a warning), create some
> automation tools (for updating files from old to new syntax) and allow
> for a newer/cleaner/easier to parse solution.
>
> (as a side-note, I think the best people to build those automation
> tools would be the compiler writers ;))

C++ is a wonderful language, and it has made some pioneering breakthroughs
in areas where other languages either didn't try, didn't succeed, or
succeeded but nobody cared :o). In doing so, it inevitably accumulated some
scars.

I now believe it is very important now for C++ to provide a coherent means
to close those wounds.


Andrei



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

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

Following this thread, I completely agree with Andrei.
I guess parsing would be quite faster, language become cleaner, if we
used a new syntax.

Since we're all used to <>, how about using </ and />
(or, somebody else suggested <| and |> - although I think </ and />
are much faster to type)

I think it's not possible to have </ and /> in the current language,
so this wouldn't break anything.

Using it in code seems quite cute (to me):

template</class value_type/> struct test {
   ...
};


test</int/> t;


 >
 > Thinking ahead of what's to come - it would be great if a new notation for
 > templates were introduced by the next C++ standard, and the old one would be
 > deprecated (along with its camarilla of syntactic fixes for the problems
 > that it caused).
 >
 > A nice compiler feature would be to issue warning for the old syntax or not,
 > depending on the creation date of the files being compiled. So if there's
 > legacy code, no warning. New code will have warnings if using the old
 > syntax.
 >
 > I'll venture to note that there is no experimental data (such as user
 > studies) backing up the conjecture made by D&E, while there's quite some
 > hard evidence backing up Pennello's statement :o).
 >
 >
 > Andrei

Going futher, I guess we could even have automation tools to convert
old code to this syntax.


Best,
John


John Torjo
Freelancer
-- john@torjo.com

Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/


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

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

I had not followed the previous thread, so please forgive me if the
following discussion is not new.

At the November 1992 meeting of the C++ Committee, some syntax
ambiguities of the <...> notation for template parameters and
arguments were discussed, and some alternatives were presented.

If I remember correctly, two suggestions that introduced no
ambiguities were {...} and two new digraphs <|...|> (similar to your
suggested </.../>). Tom Pennello, sitting in the back of the room, had
a table-driven C++ parser on his laptop computer, and tested the
suitability of suggested syntax modifications in real time. The {...}
notation was considerd visually confusing, but the <|...|> notation
had some support.

At that time, explicit template arguments on function calls, such as
foo<A,B>(), were not in the language. The arguments that won the day
against any change were that the ambiguities were minor, and that "too
many books and articles and too much code" already existed.

Today we have more serious problems with template syntax than we did
in 1992. I think that if explicit template arguments on function calls
had been part of C++ in 1992, we would have changed the notation then.

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

John Torjo wrote:
> Following this thread, I completely agree with Andrei.
> I guess parsing would be quite faster, language become cleaner, if we
> used a new syntax.
>
> Since we're all used to <>, how about using </ and />
> (or, somebody else suggested <| and |> - although I think </ and />
> are much faster to type)
>
> I think it's not possible to have </ and /> in the current language,
> so this wouldn't break anything.
>
> Using it in code seems quite cute (to me):
>
> template</class value_type/> struct test {
>    ...
> };
>
>
> test</int/> t;
>
>
>  >
>  > Thinking ahead of what's to come - it would be great if a new notation for
>  > templates were introduced by the next C++ standard, and the old one would be
>  > deprecated (along with its camarilla of syntactic fixes for the problems
>  > that it caused).
>  >
>  > A nice compiler feature would be to issue warning for the old syntax or not,
>  > depending on the creation date of the files being compiled. So if there's
>  > legacy code, no warning. New code will have warnings if using the old
>  > syntax.
>  >
>  > I'll venture to note that there is no experimental data (such as user
>  > studies) backing up the conjecture made by D&E, while there's quite some
>  > hard evidence backing up Pennello's statement :o).
>  >
>  >
>  > Andrei
>
> Going futher, I guess we could even have automation tools to convert
> old code to this syntax.
>
>
> Best,
> John
>
>
> John Torjo
> Freelancer
> -- john@torjo.com
>
> Contributing editor, C/C++ Users Journal
> -- "Win32 GUI Generics" -- generics & GUI do mix, after all
> -- http://www.torjo.com/win32gui/


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

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

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0409062202.5ef631b2@posting.google.com...
> Since we're all used to <>, how about using </ and />
> (or, somebody else suggested <| and |> - although I think </ and />
> are much faster to type)
>
> I think it's not possible to have </ and /> in the current language,
> so this wouldn't break anything.

How about an explicit specialization:

    template</*intentionally_empty*/> int my_max<int>(int x1, int x2) {
return (x1 > x2) ? x1 : x2; }

Or, possibly some case of template deduction?:

    x = func</*intentionally_empty*/>(arg1, arg2);

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-356-6010 Tel


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

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