Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Next version of C++ as ambigous as today?

Reply
Thread Tools

Next version of C++ as ambigous as today?

 
 
JohnQ
Guest
Posts: n/a
 
      06-22-2007
Is there any effort being made to move C++ toward having a less ambigous
grammer/closer to LALR(1)?

John

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      06-22-2007
JohnQ wrote:
> Is there any effort being made to move C++ toward having a less
> ambigous grammer/closer to LALR(1)?


I think you should ask that in 'comp.std.c++'. The standardization
procedures are discussed there.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
 
 
 
Ira Baxter
Guest
Posts: n/a
 
      06-23-2007
"JohnQ" <(E-Mail Removed)> wrote in message
news:Z9Uei.3299$(E-Mail Removed) t...
> Is there any effort being made to move C++ toward having a less ambigous
> grammer/closer to LALR(1)?


If anything, it is likely to be much worse.
They can't dump backwards compatibility, so the existing
parse ambiguities are likely to stay, and they
are shoehorning more features into the dark
syntax corners of the language, so there are
likely to be more complications.

Of course, a miracle might occur.
I wouldn't count on it.

The real cure is to use a stronger parsing technology than
LALR, such as GLR. Our C++ front end
uses this quite successfully. The ambiguities
are still there, but they can be managed.


--
Ira Baxter, CTO
www.semanticdesigns.com


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      06-24-2007

"Ira Baxter" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "JohnQ" <(E-Mail Removed)> wrote in message
> news:Z9Uei.3299$(E-Mail Removed) t...
>> Is there any effort being made to move C++ toward having a less ambigous
>> grammer/closer to LALR(1)?

>
> If anything, it is likely to be much worse.
> They can't dump backwards compatibility, so the existing
> parse ambiguities are likely to stay, and they
> are shoehorning more features into the dark
> syntax corners of the language, so there are
> likely to be more complications.


Complexity grows on complexity. I hear ya.

>
> Of course, a miracle might occur.
> I wouldn't count on it.


That backward compatibility thing is a real bitch huh.

>
> The real cure is to use a stronger parsing technology than
> LALR, such as GLR. Our C++ front end
> uses this quite successfully. The ambiguities
> are still there, but they can be managed.


Or to avoid those ambiguities in a subset of C++ with a slightly modified
syntax (use <[]> for templates, for example), call it something else and
offer it to those who don't have a care about backward compatibility.

I read the first half or so of Stroustrup's "D&E" yesterday again and I for
one would not want to go through all the drudgery that the inventors of C++
did as it seems a herculean effort. The nice thing is though, to invent a
"new" language in the likeness of C++, one doesn't have to (!) for it's
already been done and the knowledge is reusable. After all these years, and
in reading certain passages in D&E, it's nice to know that, even though I
may be in the minority (or obscurity!), that there are others who voiced
opinions for things that went the other way with C++. A lot of good choice
were made. A few really bad ones were though too. The few "bad" ones are
enough to leave one wanting an "incrementally" better C++ (hehe, ++C++...
C++ should have been ++C, preincrement/then, leaving C++ for post
increment/now). What is one of those things you ask? Classes and structs
being the same. But that's easier to say now, surely, than it was back then.
But that's the point: a lot has been learned since then, but can't be
realized because of this "backward compatibility" thing. Solution: a "new"
language ("in the likeness of C++).

Let's see.. how would that go... Ooo I know, use C++ as a frontend of the
compiler for the new language. "C++Front". Well isn't that a novel idea.

John

 
Reply With Quote
 
Guillermo Schwarz
Guest
Posts: n/a
 
      06-28-2007
On Jun 24, 12:08 am, "JohnQ" <(E-Mail Removed)>
wrote:
.... The nice thing is though, to invent a
> "new" language in the likeness of C++, one doesn't have to (!) for it's
> already been done and the knowledge is reusable. After all these years, and
> in reading certain passages in D&E, it's nice to know that, even though I
> may be in the minority (or obscurity!), that there are others who voiced
> opinions for things that went the other way with C++.


The most successful C++ projects I've seen declare from the start the
subset of the language allowed to be used in the project. This
document is called the "code conventions", is written by the most
experienced programmers in the project and is used a guide during
every code review done before any check-in.

Another alternative is to use language D. http://www.digitalmars.com/d/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Where to get stand alone Dot Net Framework version 1.1, version2.0, version 3.0, version 3.5, version 2.0 SP1, version 3.0 SP1 ? MowGreen [MVP] ASP .Net 5 02-09-2008 01:55 AM
Re: Where to get stand alone Dot Net Framework version 1.1, version 2.0, version 3.0, version 3.5, version 2.0 SP1, version 3.0 SP1 ? PA Bear [MS MVP] ASP .Net 0 02-05-2008 03:28 AM
Re: Where to get stand alone Dot Net Framework version 1.1, version 2.0, version 3.0, version 3.5, version 2.0 SP1, version 3.0 SP1 ? V Green ASP .Net 0 02-05-2008 02:45 AM
Ambigous Match Found After Migrating App from VS2003 to 2005 =?Utf-8?B?Q29hY2g=?= ASP .Net 0 06-08-2006 03:33 PM
Ambigous operator '&' Mohammed A khader VHDL 8 04-24-2005 04:45 PM



Advertisments