 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Sep 2008 12:32:15 +0100, Invisible wrote:
> Parsec takes a completely different approach - and that is the subject
> of this text.
What you described -- I didn't read all of it though -- sounds
very much the same as what boost::spirit does in C++.
--
Joel Yliluoma - http://iki.fi/bisqwit/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Joel Yliluoma wrote:
> What you described -- I didn't read all of it though -- sounds
> very much the same as what boost::spirit does in C++.
Looking at the Spirit documentation, it *does* indeed look highly
similar. (Right down to using the ">>" operator for the same purpose
that Parsec does.)
The difference, of course, is that Spirit uses compile-time template
insanity to do it's work, whereas Parsec does all its cleverness at
runtime. (So Spirit is probably faster, and Parsec supports constructing
user-defined parsers at runtime.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> So Spirit is probably faster
To run, sure. But it probably takes even longer than your average Boost
library to compile :)
(seriously, many boost libraries are like compiler stress-tests)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Invisible wrote:
>> So Spirit is probably faster
>
> To run, sure. But it probably takes even longer than your average Boost
> library to compile :)
>
> (seriously, many boost libraries are like compiler stress-tests)
Hmm... interesting. Template metaprogramming FTW? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> Nicolas Alvarez wrote:
> > Invisible wrote:
> >> So Spirit is probably faster
> >
> > To run, sure. But it probably takes even longer than your average Boost
> > library to compile :)
> >
> > (seriously, many boost libraries are like compiler stress-tests)
> Hmm... interesting. Template metaprogramming FTW? :-P
Well, one idea (or maybe more a side-effect) of template metaprogramming
is: Why calculate something at runtime if you can do it at compile time?
It often may result in faster binaries. OTOH there are some huge projects
where compilation times are counted in hours rather than seconds, where
significantly slower compilation times might become an issue.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Well, one idea (or maybe more a side-effect) of template metaprogramming
> is: Why calculate something at runtime if you can do it at compile time?
>
> It often may result in faster binaries. OTOH there are some huge projects
> where compilation times are counted in hours rather than seconds, where
> significantly slower compilation times might become an issue.
I personally tend to prefer longer compile times for shorter runtimes.
OTOH, the largest programs I've ever written probably didn't exceed a
few hundred lines, so...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It often may result in faster binaries. OTOH there are some huge projects
> where compilation times are counted in hours rather than seconds, where
> significantly slower compilation times might become an issue.
I remember reading of an Ada project where the customer was complaining
the vendor's compiler was too slow. The vendor looked at the code,
basically said "WTF mate?" and pointed out that using packages nested
dozens of levels deep (the equivalent of templates referring to
templates recursively dozens of times) are going to be slow to compile,
and they asked the customer why they picked that technique. The customer
pointed out that it was in the vendor's sample files. The vendor pointed
out that *that* sample file was a compiler stress-test designed to
validate the compiler doesn't choke even under awful programming
practices. :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 21 Oct 2008 08:42:48 -0700, Darren New <dne### [at] sanrrcom> wrote:
> The customer
>pointed out that it was in the vendor's sample files. The vendor pointed
>out that *that* sample file was a compiler stress-test designed to
>validate the compiler doesn't choke even under awful programming
>practices. :-)
LOL
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> I remember reading of an Ada project where the customer was complaining
> the vendor's compiler was too slow. The vendor looked at the code,
> basically said "WTF mate?" and pointed out that using packages nested
> dozens of levels deep (the equivalent of templates referring to
> templates recursively dozens of times) are going to be slow to compile,
> and they asked the customer why they picked that technique. The customer
> pointed out that it was in the vendor's sample files. The vendor pointed
> out that *that* sample file was a compiler stress-test designed to
> validate the compiler doesn't choke even under awful programming
> practices. :-)
>
I recall that, couldn't find the exact quote anywhere though.
"WTF? Why the hell are you coding like that?"
"Well, we modelled it after one of your samples"
"That wasn't a sample, that was a compiler stress-test!"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 20 Oct 2008 19:27:16 -0200, Nicolas Alvarez wrote:
> Invisible wrote:
>> So Spirit is probably faster
>
> To run, sure. But it probably takes even longer than your average Boost
> library to compile :)
>
> (seriously, many boost libraries are like compiler stress-tests)
It indeed does. Here's an error message I got from gcc
when I was developing a certain project using the Spirit parser.
http://bisqwit.iki.fi/kala/gargantuan-gcc-error-message.bz2
(bzip2 -compressed text for your convenience).
Mind you, that file contains just _one_ error message,
together with its "instantiated from" lines.
--
Joel Yliluoma - http://iki.fi/bisqwit/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
