Vincent Finn wrote:
What I did was to provide a *thin* wrapper around the internal C strucs
used by libxml2, so every dom manipulation call can be delegated down to
libxml2. For example xpath lookup: I call libxml2's xpath API, returning
me a C structure (possibly) holding a node set, i.e. a list
Stefan Seefeld said:
Vincent Finn wrote:
What I did was to provide a *thin* wrapper around the internal C
strucs used by libxml2, so every dom manipulation call can be
delegated down to libxml2. For example xpath lookup: I call libxml2's
xpath API, returning me a C structure (possibly)
Thomas Witt wrote:
1. std::endl was and is still abused heavily. I think there is a
reason for this. Most c++ programmers are taught to stay clear of
ugly low-level c things and to use the new shiny c++ facilities
instead. And that's what they do, replace '\n' with std::endl.
Personally I
William E. Kempf wrote:
there is no such thing as the 'Gnu licence'. There is the 'GNU General
Public License' (aka GPL) and the 'GNU Lesser General Public License'
(LGPL). libxml2 uses neither, and its license is fully compatible with
boost's license requirements.
Maybe, but it fails the
Vladimir Prus said:
William E. Kempf wrote:
there is no such thing as the 'Gnu licence'. There is the 'GNU
General Public License' (aka GPL) and the 'GNU Lesser General Public
License' (LGPL). libxml2 uses neither, and its license is fully
compatible with boost's license requirements.
William E. Kempf wrote:
What I think *is* a requirement is that any wrapper library
not be tied to a single backend, and I personally believe that what
follows from that is that the submission must have at least 2 referenced
backends for proof of concept.
Fair enough. What would you suggest me
Hello Justinas,
I don't know where to upload this piece of code currently so I beg you
pardon for sending an attachment. BTW, it is by no means a final
implementation of things I've just written above. It's just an initial
piece
of code - constructive comments, etc. would be nice :)
This
William E. Kempf wrote:
I tend to disagree here. Writing XML library is not easy, and libraries
like expat and libxml2 are already here, working and debugged. The
effort to write a new library from scratch would be quite serious, and
will result in anything tangible only after a lot of time.
Stefan Seefeld said:
William E. Kempf wrote:
What I think *is* a requirement is that any wrapper library
not be tied to a single backend, and I personally believe that what
follows from that is that the submission must have at least 2
referenced backends for proof of concept.
Fair
Vladimir Prus said:
William E. Kempf wrote:
Oh.. I misread your post. Apologies. Still, from a practical point of
view I can hardly imagine that if libxml2 wrapper works, somebody will
take the time to plug in another backend. That would mean rewriting
all/most implementation method and will
William E. Kempf wrote:
[...]
Not specifying the exact width
of various types is not really something that I think most people would
classify as brain damaged.
That's not the only problem with MS-interlocked API. For example, for
DCSI and DCCI things, all you need is hoist-load and
I've created a new page on the Wiki to gather opinions/suggestions on
features/requirements for an XML processing library.
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LibrariesUnderDiscussion
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostXMLDiscussion
I agree with these conclusions and strongly support the addition of newl.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL
My impressions of this are highly favourable from the examples and tests, but I
haven't tried to use it in anger yet as I am uncertain if it compiles with
MS.net 2003 (aka 7.1?). Is this known yet? Suck it and see?
(A feature I do not see is control of the number of items before a newline. I am
Alexander Terekhov said:
William E. Kempf wrote:
[...]
Not specifying the exact width
of various types is not really something that I think most people
would classify as brain damaged.
That's not the only problem with MS-interlocked API. For example, for
DCSI and DCCI things, all you
Paul A. Bristow wrote:
My impressions of this are highly favourable from the examples and tests,
but I
haven't tried to use it in anger yet as I am uncertain if it compiles with
MS.net 2003 (aka 7.1?). Is this known yet? Suck it and see?
I do not have access yet to MS VC7.1, so I have not been
Bohdan wrote:
I'll port to borland, but i'm not exprert in gcc build system.
For gcc better ask somebody else.
Thanks, I will get back to you as soon as I think the code is ready for
porting.
[snip]
Hmmm, I never liked it that much myself but I was forced to design
it this way due to some
Andreas Huber [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
After posting I realized that the current interface already allows you to
hide states. E.g. you often want to ensure that a machine is initiated
during construction:
*StopWatch.hpp*:
struct Active; // the only visible
William E. Kempf wrote:
I don't want to discourage you... in fact, I'd like to do the opposite. I
just haven't had the time to look at what you have so far to give any
helpful criticism, other than to emphasise that Boost discourages tight
coupling to libraries other than Boost or the standard
I read through the documentation but haven't tried coding against the
library yet. It looks quite useful for building isolated FSM mechanisms. I
observe in my own work that I typically have many FSM that interact with
each other. It could be argued that this is really just one large FSM, but I
Hi Chris and Andreas,
Have been listening but havent had anything to add. Now have about
0.02 worth...
snip
I read through the documentation but haven't tried coding against the
library yet. It looks quite useful for building isolated FSM mechanisms. I
observe in my own work that I typically
The terminology tutorial is excellent. Thanks - that's helpful. So my
question should have been:
Has any thought been given to the protocol(s) necessary to use the FSM
library for building systems (by Scott's definition).
DOT
That was a little bit of tongue in cheek. Not entirely a serious
Well i did manage to get it to compile by simply adding a primary
template declaration for the policy class. cringe
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 whether this is truly standard
-Original Message-
Well i did manage to get it to compile by simply adding a
primary template declaration for the policy class. cringe
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
It's worth noting that libxml2 is itself open source with what appears
to be
Boost compatible license:
http://www.opensource.org/licenses/mit-license.html
On Tuesday, Jun 3, 2003, at 20:21 America/Denver, Darryl Green wrote:
From: William E. Kempf [mailto:[EMAIL PROTECTED]
Vladimir Prus
Paul Mensonides wrote:
-Original Message-
snip
#define C C
#if C
X()
#endif
Wave spits out that this is an ill-formed preprocessor expression -
The expression of an #if (or #elif) directive should get four passes.
The first pass handles the defined operator.
This was my understanding too, which is why I claimed that my
wave executable might be buggy. Does your wave executable
also puke on the above snippet - if it does not, then i think
my wave's behavior may be an artifact of my dirty fix to
get the code to compile by declaring a primary
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
Bohdan wrote:
[snip]
I therefore think that it is not necessary to change the current
interface for information hiding purposes. Granted, it's not
perfect, but the alternative I've outlined in my previous post isn't
either, as Reece has pointed out. I might support both interfaces if
there
Chris Russell wrote:
I read through the documentation but haven't tried coding against the
library yet. It looks quite useful for building isolated FSM
mechanisms. I observe in my own work that I typically have many FSM
that interact with
each other.
Yep, I think that's the case for almost
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey
| Sent: Tuesday, June 03, 2003 2:49 PM
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: Re: I/O library status
|
| Beyond these are the performance concerns of course;
|
| rather than the more
Hi all!
The cyclic buffer implementation and documentation (cyclic_buffer.zip) can be
found at:
http://groups.yahoo.com/group/boost/files/
Regards,
Jan
--
Jan Gaspar | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel
The Command Line Config library by Vladimir Prus has been accepted
into Boost, pending the incorporation of suggestions brought up in
the review.
Thanks to everyone for all their comments, and to Vladimir for being
open and responsive to them!
There've been a fair amount of suggested
David Abrahams wrote:
I'm going to want to replace the old Boost iterator adaptors
implementation with the new one in the Boost sandbox pretty soon, and
while they are similar in intent and spirit, they have totally
incompatible interfaces.
Could you perhaps add the updated documentation to
That will certainly work, but you shouldn't have to do that since the
compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier
this
afternoon I am able to compile some non-boost code correctly which had
previously be failing.
Just let me jump in here: you absolutely can not use
Nicolas Fleury wrote:
Alexander Terekhov wrote:
Nicolas Fleury wrote:
[...]
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft Corp.
I'm delighted to hear that you want to use the library in a real-world
project but I must also warn you: You'd be the first to do so!
It's been argued by many Venture Capitalists that there's absolutely nothing
real world about my project. But I digress ;-)
Intel should be quite conformant
Beman Dawes [EMAIL PROTECTED] writes:
Hum... I just had a thought. Is it possible to detect if wchar_t is a
typedef at compile time?
Yes, I think so. Won't boost::is_same unsigned short, wchar_t
::value be true if wchar_t is a typedef, and false if a distinct type?
Yes, but you can't use the
Beman Dawes [EMAIL PROTECTED] writes:
So this is yet another case (like /Qoption,c,--arg_dep_lookup) where
Boost config code just has to assume the option has been set.
Well, the build system can tell boost what option's in use. That
doesn't help users of other build systems, but I know that
Randy Bowen wrote:
A disappointing aspect of this in regards to MSVC 7.0+ is
that there is no preprocessor macro ( as of 7.0, I haven't
checked 7.1 yet ) which MSVC defines for distinguishing
native C++ wide character from the previous typedef for
wchar_t.
The MS-specific macro
Alexander Terekhov wrote:
It is showing that semas (e.g. bin-semas aka auto-reset events)
are really error-prone.
you seem to equate microsoft's implementation of semaphores with
the concept of semaphores (which is what I'd like to get feedback on).
If all that is wrong is that microsoft does a
Fredrik Blomqvist [EMAIL PROTECTED] writes:
David Abrahams wrote:
I'm going to want to replace the old Boost iterator adaptors
implementation with the new one in the Boost sandbox pretty soon, and
while they are similar in intent and spirit, they have totally
incompatible interfaces.
Could
Stefan Seefeld said:
Alexander Terekhov wrote:
It is showing that semas (e.g. bin-semas aka auto-reset events) are
really error-prone.
you seem to equate microsoft's implementation of semaphores with
the concept of semaphores (which is what I'd like to get feedback on).
No, you miss
Nicolas Fleury wrote:
[...]
It is showing that semas (e.g. bin-semas aka auto-reset events)
are really error-prone. Their implementation of counting semaphore
How?
Review the code. You'll see that it has many problems. One problem
is precisely the thing that POSIX rationale is talking
[clip]
AFAICT, UML is the only internationally standardized modeling language
for
FSMs. However, I assume FSMs work more or less the same no matter what
graphical representation you use. I guess the only thing needed would be
a
mapping from your preferred modeling language to boost::fsm.
Nicolas Fleury wrote:
[...]
What is the paper you have in mind to justify the absence of semaphores?
I would like very much to understand and be convinced. It would also
be nice if the #10 of the FAQ would point to this paper.
It can be found here:
Greetings Boost,
I am not that much familiar with garbage collection techniques so please
excuse me if the technique I am thinking of is already used somewhere.
Let's say:
- you can easily detect weither an object was allocated on the stack or on
the heap;
- a smart pointer contained within
On Wednesday, Jun 4, 2003, at 08:22 America/Denver, Philippe A.
Bouchard wrote:
Greetings Boost,
I am not that much familiar with garbage collection techniques so
please
excuse me if the technique I am thinking of is already used somewhere.
Let's say:
- you can easily detect weither an
48 matches
Mail list logo
