On Sat, Jan 10, 2009 at 10:50 AM, Bill Hoffman
bill.hoff...@kitware.com wrote:
Would it be good if someone from Kitware came?
Yes, particularly if we set time aside to work on outstanding issues.
Such as reporting of test results.
That would be a wonderful addition to the vendors track.
James W. Walker wrote:
Thanks, that helps, but I still have a question or two. The FAQ says
it is best to avoid rules as arguments to the parse functions, but
then what are rules good for? How else am I going to do any
nontrivial parsing?
Use grammars (see here:
David B. Held wrote:
The moral being:
Using anychar_p all by itself is usually a Bad Thing(TM)
That's because it's like the langoliers--it eats everything
up. You usually want to say what it shouldn't eat up by
subtracting the terminating character from the parser. I
think this
Brian McNamara wrote:
On Mon, Jul 28, 2003 at 03:16:52PM -0400, Brian McNamara wrote:
functional programming. Over the next couple of weeks I will make
documentation of the boostified version of FC++ that's
aimed at a C++
audience. Hopefully that will help.
I've been working on a
Eric Friedman wrote:
I hadn't actually committed the fix at the time I posted the
message. Didn't think you'd be getting my reply so soon.
The fixed header should be using
BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC (with the important part
being the trailing _SPEC). Also, make sure you get an
Beman Dawes wrote:
The variant library developers were checking in changes
almost daily until
a week or two ago, so you might want to make sure you have
the latest from
CVS.
Thanks for your response.
Yes, I have the latest CVS (Boost::HEAD) snapshot. BTW this error shows
up for the
Eric Friedman wrote:
The variant library developers were checking in changes
almost daily
until a week or two ago, so you might want to make sure
you have the
latest from CVS.
Thanks for your response.
Yes, I have the latest CVS (Boost::HEAD) snapshot. BTW this error
shows
Hi all,
I've tried to use the variant library to implement some new
functionality inside the Boost.Spirit library. I must say, I'm
impressed. Very well done!
I've stumbled over a problem though: gcc (Cygwin: gcc (GCC) 3.2 20020927
(prerelease)) reports:
In file included from
John Maddock wrote:
Here is the (main) code, which uses Wave to output the file
names of
all successfully opened include files (this needs some filtering to
avoid double output of the same file):
Interesting, the thing is I need the code to find all
possible dependencies, so that
Vladimir Prus wrote:
However, it seems to be confused by the preprocessor library.
Since the
includes sometime have the form:
#include BOOST_PP_ITERATE()
the 'bcp' tool does not find them. For example,
boost/preprocessor/iteration/detail/iter directory is needed by
Hartmut Kaiser wrote:
However, it seems to be confused by the preprocessor library.
Since the
includes sometime have the form:
#include BOOST_PP_ITERATE()
the 'bcp' tool does not find them. For example,
boost/preprocessor/iteration/detail/iter directory is needed by
boost
David Abrahams wrote:
Done.
What's done?
Sorry, seems, that I've stripped of from my mail all of the useful
information :-)
I've added a new file boost/iterator_adaptors.hpp to the boost-sandbox
CVS, which contains nothing more, than
#define BOOST_ITERATOR_ADAPTORS_VERSION 0x0200
#include
David Abrahams wrote:
As a last resort this certainly helps. And in a year or so
nobody will
talk about the transitional CVS versions. But now it would be very
helpful, if there was a separate BOOST_ITERATOR_ADAPTOR_VERSION pp
constant, which could be used for this needs (BTW Spirit
David Abrahams wrote:
Hmmm... You're removed the boost/iterator_adaptors.hpp file
intentionally, right? This makes it even more problematic, because,
there is no chance to circumvent compilation errors.
There are going to be compilation errors anyway, since the
interface is
David Abrahams wrote:
Some relatively significant revisions to the new iterator
adaptors and iterator facade in the sandbox have happened
recently. Among other things, we managed to eliminate one
template parameter from iterator_adaptor (yay!). We also
finalized our proposals for the
David Abrahams wrote:
Is there any way to tell, which version of the iterator library is
installed on a target system? I could think of some pp
constant, which
allows to configure a piece of code to use the 'old' or the 'new'
iterator lib. This would allow for a smooth transition of
faisal vali wrote:
Well i did manage to get it to compile by simply adding a
primary template declaration for the policy class. cringe
Fine.
It seemed to be behaving all right until i tried to
preprocess the following (and i wonder if i caused this
behavior by my above tinkering or
faisal vali wrote:
Has anyone had problems getting the new wave preprocessor
(cpp.cpp) to compile? NMotably any position_policy error
messages (not defined in spirit and
such...)
Also i've been getting some linker errors -
I'm using gcc 3.2.1 (is that the problem?)
any clues will be
Richard Hadsell wrote:
Beman Dawes wrote:
* What if the committee changes the namespace?
Hum... That could happen. Maybe we should use a macro to
make it easy
to change.
A macro would be ugly, unless it looked just like the namespace. Can
you define a macro to make std::tr1
Reece Dunn wrote:
In the file:
spirit/wave/wave/cpplexer/slex/cpp_slex_lexer.hpp
I have noticed two points that may be bugs (but have not verified
through compilation.)
1 line 335:
[332] // C++ only token definitions
[333] template typename IteratorT, typename PositionT
Reece Dunn wrote:
This utility class provides a mechanism for adding
indentation to an I/O
stream. I was wondering who would be interested in it, or if
anyone has
anything similar.
[snip]
I'm very interested in such a functionality, but your attachment seems
to be broken. Could you
David Abrahams wrote:
I have a problem while using the iterator_adaptor templates
in conjunction with a istreambuf_iteratorchar (an
input_iterator type). The problem shows up, because the
istreambuf_iteratorchar::operator*()
implementation of the STL I'm using returns a value_type
David Abrahams wrote:
[EMAIL PROTECTED] (Hartmut Kaiser) writes:
David Abrahams wrote:
I have a problem while using the iterator_adaptor templates in
conjunction with a istreambuf_iteratorchar (an input_iterator
type). The problem shows up, because the
istreambuf_iteratorchar
Hi all,
There is a new version of the 'Wave C++/C99 preprocessor library'
available: it is V0.9.1.
This library consists out of
- a set of (template-) classes exposing an iterator interface, which
when dereferenced return the preprocessed tokens, generated on the fly
from an underlying
David Abrahams wrote:
The following message seems to be written at an 'untime', because
nobody responded, especially nobody of the maintainers.
Nevertheless
IMHO this question is worth thinking about to find a resolution.
Hi all,
I have a problem while using the
The following message seems to be written at an 'untime', because nobody
responded, especially nobody of the maintainers. Nevertheless IMHO this
question is worth thinking about to find a resolution.
Hi all,
I have a problem while using the iterator_adaptor templates
in conjunction with a
Joel de Guzman wrote:
I have to port a Linux application that is using spirit on
the VS. NET
2003. Unfortunately the current release of the spirit is
crashing the
VC++ 2003 compiler,
You mean VC7.1 is crashing?
so I asked the spirit
guys when the next version (1.5.2) will be
Hi all,
I have a problem while using the iterator_adaptor templates in
conjunction with a istreambuf_iteratorchar (an input_iterator type).
The problem shows up, because the istreambuf_iteratorchar::operator*()
implementation of the STL I'm using returns a value_type (char), but the
dereference
Hi all,
Sorry for the somewhat lenghty post, but I hope it will be helpful for
someone of you.
The Boost.Spirit based C++ preprocessor iterator (the project name is
'Wave') is functionally complete now. All pp operators and pp statements
are in place, the macro expansion engine works as
John Maddock wrote:
I'm reposting this, because I think, that this bug should be fixed,
but there wasn't any response to the first mail. I would
try to fix it
myself, but the errors are so weird, that I'm not able to
grasp, how
to do it :-)
Sorry I missed the first one: the problem is
]
[mailto:[EMAIL PROTECTED]] On Behalf Of Hartmut Kaiser
Sent: Saturday, February 01, 2003 4:58 PM
To: 'Boost mailing list'
Subject: [boost] [regex] Linker errors with MSVC
Hi all,
I get a bunch of linker errors while compiling the following
testcase with VC6.5/VC7.1 (current Boost CVS
Hi all,
I get a bunch of linker errors while compiling the following testcase
with VC6.5/VC7.1 (current Boost CVS):
test_regex.cpp:
#include string
#define BOOST_REGEX_NO_LIB
#define BOOST_REGEX_STATIC_LINK
#include boost/regex.hpp
#include boost/regex/src.cpp
int main()
{
Gennadiy Rozental wrote:
Why reinvent the wheel and not reuse existing code, which
is much more
flexible (and _you_ are the one, who stresses flexibility)
and better
fits into the task to solve.
Even with my limited knowledge of Spirit, still I do not
believe I duplicate Spirit
Vincent Finn wrote:
I was talking to you on the boost newsgroup about spirit
being slow to
compile Here is a standalone section of code, it'll compile but you
can't do anything with it The compile takes about 15 mins on my
machine (We are using spirit for a second file but that is
smaller
Sorry, I've missed an important detail (see below):
Vincent Finn wrote:
I was talking to you on the boost newsgroup about spirit
being slow to
compile Here is a standalone section of code, it'll
compile but you
can't do anything with it The compile takes about 15 mins on my
machine
Vladimir Prus wrote:
(the previous message got truncated somehow, here is the
complete text)
Some time ago I worked on a library for parsing command line,
and there was some interest for such a library. Recently I've resumed
work on it, and believe it has now reached a mostly complete
David B. Held wrote:
Terje Slettebø [EMAIL PROTECTED] wrote in message
05ab01c2b695$2f125c70$cb6c6f50@pc">news:05ab01c2b695$2f125c70$cb6c6f50@pc...
Sure, that would be fine. I'm not that familiar with
Boost.PP, though,
so I think I leave it to someone else to write that
version. As quite
Terje Slettebø wrote:
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
Sure! Submit a patch (with docs) for the utility library.
Ok. Here's boost/utility/yes_no_type.hpp.
I just used the file
boost/type_traits/detail/yes_no_type.hpp, changed
David B. Held wrote:
Hartmut Kaiser [EMAIL PROTECTED] wrote in message
000f01c2b691$45a3a1a0$0b00a8c0@fortytwo">news:000f01c2b691$45a3a1a0$0b00a8c0@fortytwo...
Terje Slettebø wrote:
[...]
typedef char (yes_type)[1];
typedef char (no_type)[2];
Within the Boost.Spirit li
Andrei Alexandrescu wrote:
A very nice Spirit code sample would be the proverbial
dogfood that C++ eats
itself. To clarify:
1. How about an open-source C++ preprocessor (that takes care
of #define and
#include) written in Spirit? Then that preprocessor could be
compared with
existing
40 matches
Mail list logo
