pchapin@sover.net ("Peter C. Chapin") writes:

[...]

> Is it realistic to use, say, the gcc front end when building a tool?

I'm not sure.  I think probably not, though the rewrite of the C++
parser probably helped.  There are also some political considerations
in that (in the past, anyway) some uses have been disapproved of.

> If not, perhaps someone somewhere could start an open source project
> around building a C++ front end for tool use.

There's TenDRA (a C/C++ compiler), Elsa
(<http://www.cs.berkeley.edu/~smcpeak/elkhound/> used in Oink, a
system for constructing C++ static analysis tools), OpenC++ (which I
know little about), and the Eclipse CDT contains enough of a parser
for the IDE, and maybe enough for other uses.

They tend to have most difficulty with tricky template usage (and who
doesn't), and with the standard library.  I'd have thought with Elsa
(and Oink) you could get a long way with just declarations: so cleaned
up header files, basically.  And for some uses of TenDRA
(cross-reference information, for example) that would also suffice.

And that doesn't feel too vast a task to me (producing just headers
for large parts of the standard library, so that C++ files can be
parsed).  But presumably I'm wrong, since I've never seen such a
thing.  (I haven't actually tried, so I presume I'm significantly
underestimating the work required, such that it's easier for the
projects to work on parsing the g++ headers.)

[...]

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <Fw4gi.4073$vi5.3205@newssvr17.news.prodigy.net>,
johnqREMOVETHISprogrammer@yahoo.com says...
>
> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
> news:MPG.20e99d913440cb0d98992f@news.sunsite.dk...

[ ... ]

> > It's not so practical for tools you're planning to give away though.
> > According to their web site, a source license normally costs at least
> > $40,000 US, and _very_ few people can spend that kind of money, then put
> > in a bunch of work to produce a tool that uses it, all with no hope of
> > ever making any money on it at all.
>
> And that hindrance is directly related to the complexity of C++.

I'm not sure that's true -- as far as I can see, EDG lists the same
price range for their Java front end, and Java is reputedly considerably
easier to parse. Easier parsing certainly makes it more practical to do
the job yourself, but I'm not sure it really has a tremendous effect on
the price. In most cases, price is based more on perceived value than
development cost.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Jerry Coffin wrote:

>> I knew that. I don't know enough about compilers to know that LALR(1) is
>> utopia. The thought that given a langauge with such a grammar could open up
>> the possibility of really new ways of development, is intriguing though.
>
> It would make a big difference in the complexity of developing tools
> that need to parse the language. It would make no real difference in
> terms of _using_ the language.

There's also a tendency, on the part of tool writers, to do everything
"on their own". Why don't they simply use something like the EDG
front-end, for instance? If Comeau may offer a complete compiler for
about fifty dollars, I guess tool writers could do very well with such
a choice, too.

--
      \|||/                Gennaro Prota   -   For hire
      (o o)           https://sourceforge.net/projects/breeze/
--ooO-(_)-Ooo-----   (to mail: name . surname / yaho ! 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.comeaucomputing.com/csc/faq.html                      ]

In article <f5o77n$akl$1@aioe.org>, invalid@yahoo.com says...

[ ... ]

> There's also a tendency, on the part of tool writers, to do everything
> "on their own". Why don't they simply use something like the EDG
> front-end, for instance? If Comeau may offer a complete compiler for
> about fifty dollars, I guess tool writers could do very well with such
> a choice, too.

EDG is almost certainly a great choice for a tool vendor -- you'd have
to find top-notch developers willing to work for nearly nothing to
develop as good a front end for anywhere close to its price.

It's not so practical for tools you're planning to give away though.
According to their web site, a source license normally costs at least
$40,000 US, and _very_ few people can spend that kind of money, then put
in a bunch of work to produce a tool that uses it, all with no hope of
ever making any money on it at all.

I suppose it's a bit closer to conceivable that you might be able to put
together a project and get 40-80 people to put up $500-1000 apiece to
get the front end. I'd guess even that would be pretty difficult though
-- a lot of good programmers can and will donate time, but not so many
can or will put up that kind of money as well.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.20e99d913440cb0d98992f@news.sunsite.dk...
> In article <f5o77n$akl$1@aioe.org>, invalid@yahoo.com says...
>
> [ ... ]
>
>> There's also a tendency, on the part of tool writers, to do everything
>> "on their own". Why don't they simply use something like the EDG
>> front-end, for instance? If Comeau may offer a complete compiler for
>> about fifty dollars, I guess tool writers could do very well with such
>> a choice, too.
>
> EDG is almost certainly a great choice for a tool vendor -- you'd have
> to find top-notch developers willing to work for nearly nothing to
> develop as good a front end for anywhere close to its price.
>
> It's not so practical for tools you're planning to give away though.
> According to their web site, a source license normally costs at least
> $40,000 US, and _very_ few people can spend that kind of money, then put
> in a bunch of work to produce a tool that uses it, all with no hope of
> ever making any money on it at all.

And that hindrance is directly related to the complexity of C++. Simplify
the language and it makes advanced tool development scenarios plausible
(takes away some of the cost of doing such). Assuming someone actually wants
those tools. From my own perspective, I'd like to see a simpler language so
I can derive other languages from it (assuming that no one else could
produce a language that is of my liking).

> I suppose it's a bit closer to conceivable that you might be able to put
> together a project and get 40-80 people to put up $500-1000 apiece to
> get the front end. I'd guess even that would be pretty difficult though
> -- a lot of good programmers can and will donate time, but not so many
> can or will put up that kind of money as well.

John

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

jcoffin@taeus.com (Jerry Coffin) wrote in
news:MPG.20e99d913440cb0d98992f@news.sunsite.dk:

> It's not so practical for tools you're planning to give away though.
> According to their web site, a source license normally costs at least
> $40,000 US, and _very_ few people can spend that kind of money, then
> put in a bunch of work to produce a tool that uses it, all with no
> hope of ever making any money on it at all.

Is it realistic to use, say, the gcc front end when building a tool? If
not, perhaps someone somewhere could start an open source project around
building a C++ front end for tool use. I agree that the complexity of
C++'s grammar (not to mention its semantics) probably inhibits tool
building. Simplifying the language is not really an option at this
point, and it might not even be desirable in the long run. Providing a
well made front end that anyone can use and that hides the complexity of
parsing from the tool's code would be a great service to the C++
community.

Perhaps such a project already exists?

Peter

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.20e860a5c122b80298992d@news.sunsite.dk...
> In article <xsmfi.35439$Um6.18920@newssvr12.news.prodigy.net>,
> johnqREMOVETHISprogrammer@yahoo.com says...
>>
>> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
>> news:MPG.20e70f93e0ecf1d698991d@news.sunsite.dk...
>> > In article <uZZei.5818$bP5.1393@newssvr19.news.prodigy.net>,
>> > johnqREMOVETHISprogrammer@yahoo.com says...
>> >> Is there any effort being made to move C++ toward having a less
>> >> ambigous
>> >> grammer/closer to LALR(1)?
>> >
>> > I don't believe so -- it's hard to imagine any real improvement in this
>> > area without breaking huge amounts of existing code.
>>
>> I knew that. I don't know enough about compilers to know that LALR(1) is
>> utopia. The thought that given a langauge with such a grammar could open
>> up
>> the possibility of really new ways of development, is intriguing though.
>
> It would make a big difference in the complexity of developing tools
> that need to parse the language. It would make no real difference in
> terms of _using_ the language.

It probably would make a difference, because having all the information
about the code in real time would make higher level (than text editing)
manipulation of "the code" possible. Indeed, instead of the source text
being "the code", the machine code would become "the code" (the source text
would just be one representation of "the code").

>
>> "I'm special" in that I don't need a lot of the functionality contained
>> within C++. Knowing that, I feel C++ may be keeping me from having those
>> "new ways of development" and want a new language or a way to generate
>> languages on the fly for a particular domain. Maybe C++ is the construct
>> base from which to derive "domain specific languages". (What's a "domain"
>> in
>> that context you ask? Anything your heart desires. Could be "desktop
>> domain"; "server domain"; "retail systems domain"; "John's mood today
>> domain").
>
> You might want to take a look at Boost.proto -- it's a library
> specifically designed to support creating domain specific languages
> within C++. Just as a warning, however, it uses templates _extremely_
> heavily. Unless you're quite comfortable with template programming, you
> may find it difficult. In fact, if you are comfortable with normal
> template progrmaming, it'll still probably take a fair amount of work to
> grasp it -- in my (admittedly limited) experiece with it, it seems to
> work quite well, but defining and implementing domain specific languages
> is non-trivial at best.

Non-trivial in general or non-trivial with the meta/template method?

John

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Jun 25, 6:49 pm, jcof...@taeus.com (Jerry Coffin) wrote:
> In article <f5o77n$ak...@aioe.org>, inva...@yahoo.com says...

> [ ... ]

> > There's also a tendency, on the part of tool writers, to do everything
> > "on their own". Why don't they simply use something like the EDG
> > front-end, for instance? If Comeau may offer a complete compiler for
> > about fifty dollars, I guess tool writers could do very well with such
> > a choice, too.

> EDG is almost certainly a great choice for a tool vendor -- you'd have
> to find top-notch developers willing to work for nearly nothing to
> develop as good a front end for anywhere close to its price.

> It's not so practical for tools you're planning to give away though.
> According to their web site, a source license normally costs at least
> $40,000 US, and _very_ few people can spend that kind of money, then put
> in a bunch of work to produce a tool that uses it, all with no hope of
> ever making any money on it at all.

First, just to relativize what you're saying: $40,000 US is
considerably less than three man-months, you couldn't develop a
C front-end for that, if you're paying your staff.  So as you
say, for vendors, it's a bargain.  (I don't think you meant too,
but it sounded like you were presenting it as expensive.)

For free projects, of course, even $40 could be out of the
question; regardless of the price, their licensing is likely not
compatible with yours.  (I'm pretty sure that they don't give an
open source license, although I think they do deliver the
sources.)  But for free projects, you can often live with the
GPL, so there's the g++ front-end.  From what I can tell, it's
not as good as the EDG front-end (but I've never used an EDG
based compiler in a real project), but it's still very, very
good; a lot better than anything you're likely to be able to
write yourself.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
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


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Jun 26, 11:48 am, pcha...@sover.net ("Peter C. Chapin") wrote:

> I agree that the complexity of
> C++'s grammar (not to mention its semantics) probably inhibits tool
> building. Simplifying the language is not really an option at this
> point, and it might not even be desirable in the long run. Providing a
> well made front end that anyone can use and that hides the complexity of
> parsing from the tool's code would be a great service to the C++
> community.

This reminds me of this paper from 2005:

 "A formalism for C++"
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1885.pdf

Maybe implementing such a beast as a support library would be a start.

--
 Pedro Lamar   o


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Is there any effort being made to move C++ toward having a less ambigous
grammer/closer to LALR(1)?

John

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <uZZei.5818$bP5.1393@newssvr19.news.prodigy.net>,
johnqREMOVETHISprogrammer@yahoo.com says...
> Is there any effort being made to move C++ toward having a less ambigous
> grammer/closer to LALR(1)?

I don't believe so -- it's hard to imagine any real improvement in this
area without breaking huge amounts of existing code.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:MPG.20e70f93e0ecf1d698991d@news.sunsite.dk...
> In article <uZZei.5818$bP5.1393@newssvr19.news.prodigy.net>,
> johnqREMOVETHISprogrammer@yahoo.com says...
>> Is there any effort being made to move C++ toward having a less ambigous
>> grammer/closer to LALR(1)?
>
> I don't believe so -- it's hard to imagine any real improvement in this
> area without breaking huge amounts of existing code.

I knew that. I don't know enough about compilers to know that LALR(1) is
utopia. The thought that given a langauge with such a grammar could open up
the possibility of really new ways of development, is intriguing though.
"I'm special" in that I don't need a lot of the functionality contained
within C++. Knowing that, I feel C++ may be keeping me from having those
"new ways of development" and want a new language or a way to generate
languages on the fly for a particular domain. Maybe C++ is the construct
base from which to derive "domain specific languages". (What's a "domain" in
that context you ask? Anything your heart desires. Could be "desktop
domain"; "server domain"; "retail systems domain"; "John's mood today
domain").

John

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <xsmfi.35439$Um6.18920@newssvr12.news.prodigy.net>,
johnqREMOVETHISprogrammer@yahoo.com says...
>
> "Jerry Coffin" <jcoffin@taeus.com> wrote in message
> news:MPG.20e70f93e0ecf1d698991d@news.sunsite.dk...
> > In article <uZZei.5818$bP5.1393@newssvr19.news.prodigy.net>,
> > johnqREMOVETHISprogrammer@yahoo.com says...
> >> Is there any effort being made to move C++ toward having a less ambigous
> >> grammer/closer to LALR(1)?
> >
> > I don't believe so -- it's hard to imagine any real improvement in this
> > area without breaking huge amounts of existing code.
>
> I knew that. I don't know enough about compilers to know that LALR(1) is
> utopia. The thought that given a langauge with such a grammar could open up
> the possibility of really new ways of development, is intriguing though.

It would make a big difference in the complexity of developing tools
that need to parse the language. It would make no real difference in
terms of _using_ the language.

> "I'm special" in that I don't need a lot of the functionality contained
> within C++. Knowing that, I feel C++ may be keeping me from having those
> "new ways of development" and want a new language or a way to generate
> languages on the fly for a particular domain. Maybe C++ is the construct
> base from which to derive "domain specific languages". (What's a "domain" in
> that context you ask? Anything your heart desires. Could be "desktop
> domain"; "server domain"; "retail systems domain"; "John's mood today
> domain").

You might want to take a look at Boost.proto -- it's a library
specifically designed to support creating domain specific languages
within C++. Just as a warning, however, it uses templates _extremely_
heavily. Unless you're quite comfortable with template programming, you
may find it difficult. In fact, if you are comfortable with normal
template progrmaming, it'll still probably take a fair amount of work to
grasp it -- in my (admittedly limited) experiece with it, it seems to
work quite well, but defining and implementing domain specific languages
is non-trivial at best.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]