Re: [boost] Re: an XML API in boost
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 of C nodes. I just need to map these C structs back to my C++ wrapper objects and I'm done with it. (Luckily for me, libxml2 provides all the hooks to make that lookup very efficient...) One problem would be the licence libxml2 is a Gnu project isn't it? that means it's under the Gnu licence which is far more restrictive than the boost licence 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. Regards, Stefan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: an XML API in boost
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) holding a node set, i.e. a list of C nodes. I just need to map these C structs back to my C++ wrapper objects and I'm done with it. (Luckily for me, libxml2 provides all the hooks to make that lookup very efficient...) One problem would be the licence libxml2 is a Gnu project isn't it? that means it's under the Gnu licence which is far more restrictive than the boost licence 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 Boost Library Guidelines: Use the C++ Standard Library or other Boost libraries, but only when the benefits outweigh the costs. Do not use libraries other than the C++ Standard Library or Boost. See Library reuse (edit: http://www.boost.org/more/library_reuse.htm). If a submitted library required libxml2, I'd personally vote no. If the interface was supposed to be portable to other backends, I'd probably still vote no unless at least one other backend was included as proof of concept. It would still be nice to have a Boost supplied backend, probably via Spirit, but so long as I was confident that I was not tied to any specific non-Boost library, it wouldn't matter that much. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: I/O library status
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 believe this reason alone justifies a std library
extension std::newl.
What are your thoughts on the shininess of std::newl? To me, newl still seems kind
of cryptic, not much better than '\n'. Is the extra verbosity worth the downsides? I
see a few downsides:
* The general aliasing problem of having two ways to accomplish basically the same
thing ('\n' and newl) - it increases stylistic variances between different pieces of
code and means a higher learning curve for those who now have to know two constructs
to read existing code.
* We currently have two constructs with different semantics, where the name doesn't
provide any hint of the difference between those semantics: endl and '\n'. Do we
really want to add one more such unhinting name to the hat. How is the user to be
reminded that '\n' and newl are almost the same, but not quite, whereas endl is the
manipulator that provides the flush?
* Since only '\n' works when forming strings, the same snippet of code could have both
'\n' and newl used together.
Beyond these are the performance concerns of course; that is that people may tend to
use:
cout
My first line newl
My second line;
rather than the more efficient and arguably more readable:
cout
My first line \n
My second line;
2. IIUC the difference between a character and a manipulator is that
the manipulator is not tied to the streams character type. So for some
applications '\n' does not suffice. To me stream.widen('\n') is
sufficiently ugly to justify a newl modifier.
Could you elaborate here? I'm not up to speed enough to know where '\n' wouldn't get
widened automatically. I agree that stream.widen('\n') is indeed ugly.
Ed
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: an XML API in boost
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 Boost Library Guidelines: Use the C++ Standard Library or other Boost libraries, but only when the benefits outweigh the costs. Do not use libraries other than the C++ Standard Library or Boost. See Library reuse (edit: http://www.boost.org/more/library_reuse.htm). If a submitted library required libxml2, I'd personally vote no. If the interface was supposed to be portable to other backends, I'd probably still vote no unless at least one other backend was included as proof of concept. It would still be nice to have a Boost supplied backend, probably via Spirit, but so long as I was confident that I was not tied to any specific non-Boost library, it wouldn't matter that much. 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. Unless somebody has really lot of spare time, wrapping existing library is the only way how XML support can be added in boost. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: an XML API in boost
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. Maybe, but it fails the Boost Library Guidelines: Use the C++ Standard Library or other Boost libraries, but only when the benefits outweigh the costs. Do not use libraries other than the C++ Standard Library or Boost. See Library reuse (edit: http://www.boost.org/more/library_reuse.htm). If a submitted library required libxml2, I'd personally vote no. If the interface was supposed to be portable to other backends, I'd probably still vote no unless at least one other backend was included as proof of concept. It would still be nice to have a Boost supplied backend, probably via Spirit, but so long as I was confident that I was not tied to any specific non-Boost library, it wouldn't matter that much. 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. Unless somebody has really lot of spare time, wrapping existing library is the only way how XML support can be added in boost. Careful with what you disagree with. I stated that it would still be nice to have a Boost supplied backend, but I didn't state this was a requirement. 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. Note that this is precisely what Boost.Threads does, for instance. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: an XML API in boost
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 to do ? I do have a working wrapper around libxml2, but I don't have the time to reimplement it around another backend. Is this something that could be done in the boost cvs sandbox ? All I wanted to do is a) find out whether there is interest into a boost XML library b) if the answer to a) is 'yes' get feedback as to how to get there Regards, Stefan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: proposal for efficient geom. vector class
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 code below is not compiling with Borland
#include vector // only for size_t
template typename T,size_t class X;
template typename T class XT,0 {};
int main() {
Xint,0 x;
return 0;
}
The size_t for the second template is the cause. It compiles with
template typename T,int class X;
or in main()
Xint,size_t(0) x;
I think it could be a similar case in your tiny_vector definition.
Regards,
Patrick
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: an XML API in boost
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. Unless somebody has really lot of spare time, wrapping existing library is the only way how XML support can be added in boost. Careful with what you disagree with. I stated that it would still be nice to have a Boost supplied backend, but I didn't state this was a requirement. 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. Note that this is precisely what Boost.Threads does, for instance. 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 bring no end user value --- so it's not sufficiently interesting task to anybody to take. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: an XML API in boost
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 enough. What would you suggest me to do ? I do have a working wrapper around libxml2, but I don't have the time to reimplement it around another backend. Is this something that could be done in the boost cvs sandbox ? Yes, the sandbox would probably be useful. If you don't have the time to make it work with another backend, but still feel that it is portable in this manner, you might go ahead and submit any way. I personally would be inclined to vote no, unless I felt it was fairly obvious that the API truly is portable to other backends with out proof in multiple implementations, but others might not feel the same. The other alternative would be to ask for volunteers to do the port before submission. All I wanted to do is a) find out whether there is interest into a boost XML library Absolutely! This has been discussed before. b) if the answer to a) is 'yes' get feedback as to how to get there I think that's what we're trying to do ;). 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 libraries. This doesn't mean that you have to provide a full implementation of the back end parser as a Boost submission (though I do think that would be an interesting submission in and of itself), only that you need to convince people that you aren't tied to some other library. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: an XML API in boost
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 bring no end user value --- so it's not sufficiently interesting task to anybody to take. That totally depends on the wrapper. If it's a thin wrapper it will have very tight coupling and will require extensive rewriting, as you say. But such a design wouldn't be interesting to me any way, as a Boost submission. In any event, the amount of rewriting would be no different than the amount of code variation there is in Boost.Threads for the three target platforms it supports. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shared_ptr/weak_ptr and thread-safety
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 sink-store barriers; a full acquire/release is an overkill, so to speak. Also, for basic thread-safe reference counting, you really want to have naked increments and either naked decrements [for the immutable stuff] or decrements with acquire-if-min/release-if-not-min memory synchronization semantics. Now, can you provide documentation for the above, including preconditions, postconditions, etc. for each method? Do you mean refcount's methods? atomic stuff? refs-thing? A man-pages-like specification for plain C version of optionally non-blocking pthread_refcount_t without parameterization (I mean thread-safety and counter type) can be found here: http://terekhov.de/pthread_refcount_t/draft-edits.txt That's the only thing I have at the moment and I don't expect that I'll have more in the coming weeks. regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::xml discussion page added to the Wiki
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've posted some comments that expand a bit on how I use the BGL for XML processing currently. Certainly there are wide range of opinions on this subject. So go write them up so we can get a good look at 'em and decide how best to do this. (I have an immediate need for this work and will contribute to writing the code regardless if I'm overruled on using the BGL to store the data internally). - Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: I/O library status
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 PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Thomas Witt
| Sent: Tuesday, June 03, 2003 8:19 AM
| To: Boost mailing list
| Subject: Re: [boost] Re: I/O library status
|
|
|
| Hi,
|
| On Monday 02 June 2003 19:21, Ed Brey wrote:
| * newl differs from '\n' only in that newl doesn't perform background
| formatting. Presumably one would choose to use newl to avoid the
| formatting. What is undesirable about '\n' being formatted?
|
| To me there are basically two reasons that make newl desirable beside the
| formatting issue.
|
| 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 believe this reason alone
| justifies a std library extension std::newl.
|
| 2. IIUC the difference between a character and a manipulator is that the
| manipulator is not tied to the streams character type. So for some
| applications '\n' does not suffice. To me stream.widen('\n') is sufficiently
| ugly to justify a newl modifier.
|
| Thomas
|
| --
| Dipl.-Ing. Thomas Witt
| Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
| voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
| http://www.ive.uni-hannover.de
|
| ___
| Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] IO Formatting Manipulators
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 not sure if this is a sensible feature in these days of scroll bars and I can see it is fraught with difficulties). I didn't spot any examples with floating point values. Do these introduce any hidden snags? 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 PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn | Sent: Monday, June 02, 2003 12:42 PM | To: [EMAIL PROTECTED] | Subject: [boost] IO Formatting Manipulators | | | Does anyone have any ideas/suggestions: | * on where I should extend the code | * what features they would like to see that are not currently available | * bugs/inconsistencies with existing features | | I would also like to have comments on what people want out of the | documentations. Whether they want: | * a technical description of the facilities |* an 'under the hood' look at the implementation | * standardese description of the classes | * detailed examples of how to output a given type | * organisational ideas (e.g. separate the tutorial from the main section) | * rationale for the various design choices | * other features | | NOTE: Because I have revised the main code, I am looking at overhauling what | documentation I had. The documentation is high on my to do list, but I have | not started it yet as I have been busy. I should start it on Wednesday. | | All feedback would be very welcome. | | PS: Here is a link to the latest version in case you missed it. |http://lists.boost.org/MailArchives/boost/msg47757.php | | Regards, | Reece | | _ | Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
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 need is hoist-load and sink-store barriers; a full acquire/release is an overkill, so to speak. Also, for basic thread-safe reference counting, you really want to have naked increments and either naked decrements [for the immutable stuff] or decrements with acquire-if-min/release-if-not-min memory synchronization semantics. I'd agree with that, but that's not what you said in the thread to defend the brain damaged remark. Further, even this wouldn't classify it as brain damaged to me, because what they give can be used correctly and successfully for some use cases. Brain damaged implies it can't be used at all. It's too derogatory to be used for anything less, and you throw the term around very frequently. Now, can you provide documentation for the above, including preconditions, postconditions, etc. for each method? Do you mean refcount's methods? atomic stuff? refs-thing? All of it. A man-pages-like specification for plain C version of optionally non-blocking pthread_refcount_t without parameterization (I mean thread-safety and counter type) can be found here: http://terekhov.de/pthread_refcount_t/draft-edits.txt Thanks. I'll take a look at it. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] IO Formatting Manipulators
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 able to test it on this compiler. I have only had the oppotunity to test on: * MS VC7.0 * GCC 3.2.2 * GCC 3.3 * Borland C++Compiler 5.5 It should work on VC7.1 since it works on VC7.0 and GCC 3.x. If anyone can test my library on this compiler, or any others, I'd be greatful for feedback (test/example output, error messages, etc). Type/outputter deduction is working for GCC 3.x. The type deduction works on Borland, but it chokes on outputter deduction (can't figure this one out yet). MS VC7.0 does not have this facility since there is no template partial specialization; not checked for VC7.1 (may or may not need modification to work on it). I have used a configuration header to allow flexible management of facilities that do not work on various compilers. (A feature I do not see is control of the number of items before a newline. I am not sure if this is a sensible feature in these days of scroll bars and I can see it is fraught with difficulties). The results embedded in the examples are manually formatted with newlines to make them readable. In order to implement this, you will need to override the outputter used by the program to count the number of items being outputted. You would need to work out what the base unit is (e.g. basic value, pair value) and use this as a starting point. Such is the use of custom outputters :-) This would possibly be a good topic for the documentation - creating custom outputters. NOTE: The above will not work with automatic outputter deduction. I didn't spot any examples with floating point values. Do these introduce any hidden snags? Not so far as I am aware: std::list float lflt; lflt.push_back( 1.1 ); lflt.push_back( 2.1 ); lflt.push_back( 3.1 ); std::cout boost::io::formatlist( lflt ) '\n'; Regards, Reece _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: Finite State Machine framework
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 constraints of an earlier design. Now that
you mention it, I think it should be possible to specify the inner
initial state with the initiate() function, which could be called as
follows:
Pump.hpp:
class Pump : public fsm::state_machine Pump
{
public:
void Start();
};
Pump.cpp:
struct Idle : public fsm::simple_state Idle, Pump
void Pump::Start()
{
initiate Idle (); // * here *
}
Did you have something like this in mind?
Definitely!
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 forward
struct StopWatch : fsm::state_machine StopWatch, Active
{
StopWatch();
};
*StopWatch.cpp*:
struct Stopped;
struct Active : fsm::simple_state Active, StopWatch,
fsm::transition EvReset, Active , Stopped {};
struct Running : fsm::simple_state Running, Active,
fsm::transition EvStartStop, Stopped {};
struct Stopped : fsm::simple_state Stopped, Active,
fsm::transition EvStartStop, Running {};
StopWatch::StopWatch()
{
initiate();
}
The trick is to place the initiate(); call in a location where all states
are known.
So, clients see only one forward declaration of the initial state while all
the other states are hidden in the .cpp file. However, this approach still
exposes the whole state_machine interface to the clients (StopWatch *must*
derive publicly from state_machine), which is often not what you want. In
real-world code you'd probably more often have the state_machine subclass as
a data member, maybe even more hidden with a pimpl.
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 are other use cases
that don't work with the current interface.
Regards,
Andreas
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: Finite State Machine framework
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 forward
struct StopWatch : fsm::state_machine StopWatch, Active
{
StopWatch();
};
*StopWatch.cpp*:
struct Stopped;
struct Active : fsm::simple_state Active, StopWatch,
fsm::transition EvReset, Active , Stopped {};
struct Running : fsm::simple_state Running, Active,
fsm::transition EvStartStop, Stopped {};
struct Stopped : fsm::simple_state Stopped, Active,
fsm::transition EvStartStop, Running {};
StopWatch::StopWatch()
{
initiate();
}
The trick is to place the initiate(); call in a location where all states
are known.
So, clients see only one forward declaration of the initial state while all
the other states are hidden in the .cpp file. However, this approach still
exposes the whole state_machine interface to the clients (StopWatch *must*
derive publicly from state_machine), which is often not what you want. In
real-world code you'd probably more often have the state_machine subclass as
a data member, maybe even more hidden with a pimpl.
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 are other use cases
that don't work with the current interface.
Regards,
Andreas
I vote for both interfaces. If feature is easy to implement and
if it allows to avoid even forward state declaration than why
not ? I think you are right and initial state template parameter
will simpify code, but allowing default InnerInitial = detail::empty_list
as you did it for state template will allow complete removing of
initial state from interface.
BTW what about run-time selection of initial states ? :
StopWatch::StopWatch()
{
if( ... )
initiateMyInitialState1();
else
{
initiateMyInitialState2();
initiateMyOrthohonalInitialState2();
}
}
...
regards,
bohdan
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: an XML API in boost
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 libraries. This doesn't mean that you have to provide a full implementation of the back end parser as a Boost submission (though I do think that would be an interesting submission in and of itself), only that you need to convince people that you aren't tied to some other library. ok, whoever is interested: http://groups.yahoo.com/group/boost/files/xml/ contains my current working code (or almost), with some examples. As I said, it's based on libxml2, so the Makefiles rely on it. The demos use std::string as string class, but I'v already used QString (from the Qt GUI toolkit) successfully as a unicode-enabled alternative. Comments and suggestions are most welcome, Stefan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Some questions on the FSM submission
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 like to think of them in terms of discrete FSM that interact with each other because it makes it easier to conceptualize class structure, threading, and occasionally inter-process or in the case of a distributed application, inter-system partitioning. That being said, I have the following questions (note these are not criticisms of the library or even a formal review - I'm trying to understand how it fits into my own work to decide how much time to invest in it). If I understand the documentation correctly, the submission is geared more towards creating hermetically sealed FSM mechanisms than for describing multiple interacting FSM's. Is this correct? Also, I have some need to deal formally with Petri Networks. Related to FSM and automata theory in general, has any thought been given to supporting this class of FSA? I'm not a big UML fan so this aspect of the submission troubles me a little. Do we have a lot of UML fans here? I would be happier if it imported ATT GraphViz DOT or some other format that explicitly deals with the directed graph nature of FSM. But that's probably going to be an unpopular idea because it begs the question why not use the BGL then? - Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Some questions on the FSM submission
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 have many FSM that interact with each other. It could be argued that this is really just one large FSM, but I like to think of them in terms of discrete FSM that interact with each other because it makes it easier to conceptualize class structure, threading, and occasionally inter-process or in the case of a distributed application, inter-system partitioning. If I can offer some terminology (not mine but a mish-mash of SDL and others); * a FSM is a discrete, hermeticically sealed (like that) state machine * a collection of co-operating FSMs is a system * FSMs in a system interact by exchanging events * an exchange of events is known as a protocol. snip I'm not a big UML fan so this aspect of the submission troubles me a little. Do we have a lot of UML fans here? I would be happier if it imported ATT GraphViz DOT or some other format that explicitly deals with the directed graph nature of FSM. But that's probably going to be an unpopular idea because it begs the question why not use the BGL then? Not a UML fan. That is, UML isnt at all bad but have had SDL forced on me by the ITU and now feel it has a narrower (and more successful) focus on FSM systems (AKA signaling in SDL). Now I also have to check out DOT... Keep it going, SW ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Some questions on the FSM submission
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 comment. Not entirely. DOT is used to describe graphs and the BGL has facility to read and write in DOT format (and the ATT docs on DOT are complete). I've been on a if it can be modeled as a graph, use the BGL kick lately. Scott Woods [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 have many FSM that interact with each other. It could be argued that this is really just one large FSM, but I like to think of them in terms of discrete FSM that interact with each other because it makes it easier to conceptualize class structure, threading, and occasionally inter-process or in the case of a distributed application, inter-system partitioning. If I can offer some terminology (not mine but a mish-mash of SDL and others); * a FSM is a discrete, hermeticically sealed (like that) state machine * a collection of co-operating FSMs is a system * FSMs in a system interact by exchanging events * an exchange of events is known as a protocol. snip I'm not a big UML fan so this aspect of the submission troubles me a little. Do we have a lot of UML fans here? I would be happier if it imported ATT GraphViz DOT or some other format that explicitly deals with the directed graph nature of FSM. But that's probably going to be an unpopular idea because it begs the question why not use the BGL then? Not a UML fan. That is, UML isnt at all bad but have had SDL forced on me by the ITU and now feel it has a narrower (and more successful) focus on FSM systems (AKA signaling in SDL). Now I also have to check out DOT... Keep it going, SW ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [ANN] New Version of the Wave preprocessorlibraryreleased (Isthis a bug?)
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 behavior): #define C C #if C X() #endif Wave spits out that this is an ill-formed preprocessor expression - Is that true? From my reading of the standard this should first get transformed into: #if 0 X() #endif Can someone explain or confirm what the expected outcome should be, and whether it is my compilation of wave that is broken? regards, Faisal Vali ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [ANN] New Version of the Wavepreprocessorlibraryreleased (Isthis a bug?)
-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 whether this is truly standard behavior): #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. Each instance of defined XYZ and defined(XYZ) is replaced with 0 or 1. The second pass does macro expansion. For the expression above, macro expansion results in C. The third pass converts all remaining identifier tokens, with the exception of true and false, with 0. (Note that that alternative tokens are not identifiers, so this doesn't apply to them.) Finally, yielding the expression 0. The fourth pass finally evaluates the expression, which should evaluate to false. Regards, Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: an XML API in boost
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 said: William E. Kempf wrote: If a submitted library required libxml2, I'd personally vote no. If the interface was supposed to be portable to other backends, I'd probably still vote no unless at least one other backend was included as proof of concept. It would still be nice to have a Boost supplied backend, probably via Spirit, but so long as I was confident that I was not tied to any specific non-Boost library, it wouldn't matter that much. I tend to disagree here. Writing XML library is not easy, and libraries like expat and libxml2 are already here, working and debugged. ... Careful with what you disagree with. I stated that it would still be nice to have a Boost supplied backend, but I didn't state this was a requirement. 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. Note that this is precisely what Boost.Threads does, for instance. I agree that the interface shouldn't be too tightly bound to the underlying library. imho the interface Stefan has written isn't tightly coupled to libxml2 in the sense that the interface would need to change or be a poor fit on some other library. However, the implementation (and efficiency) of the wrapper is certainly aided by the libxml2 library interface needing only a very thin c++ veneer, and libxml2 being very comprehensive in its facilities. As a user, I had already decided to use libxml2 and wrap it when Stefan posted. The decision was based on code size, performance and features of the xml lib. I had already looked at using Spirit, and found the example xml parser too slow in comparison to other parsers, in particular expat and libxml2. To provide the same facilities as libxml2 requires considerably more than just a parser - performance issues aside. I can't think of a good reason for wanting to apply stephen's interface to another underlying xml lib, until or unless there is a better performing xml lib than libxml2. I would suggest that the portability (or otherwise) of Stefan's library could be assessed/reviewed without necessarily requiring another implementation for which there would likely be no users. This is a bit different to threads, (warning: Alexander bait) where there is clearly a requirement to use the native platform library facilites, and these facilities differ significantly. There isn't really that much variation in how one presents xml using a dom, sax and xpath based interface - it just needs a c++ language binding. Regards Darryl Green. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [ANN] New Version of the Wavepreprocessorlibraryreleased(Isthis a bug?)
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. Each instance of defined XYZ and defined(XYZ) is replaced with 0 or 1. The second pass does macro expansion. For the expression above, macro expansion results in C. The third pass converts all remaining identifier tokens, with the exception of true and false, with 0. (Note that that alternative tokens are not identifiers, so this doesn't apply to them.) Finally, yielding the expression 0. The fourth pass finally evaluates the expression, which should evaluate to false. 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 template in order to make the explicit specialization of policy... well-formed. I have not studied the source code for wave yet - and before (or if) i do, i was hoping if someone could confirm or deny experiencing the same behavior with their wave executable. regards, Faisal Vali ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [ANN] New Version of theWavepreprocessorlibraryreleased (Isthis a bug?)
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 template in order to make the explicit specialization of policy... well-formed. I have not studied the source code for wave yet - and before (or if) i do, i was hoping if someone could confirm or deny experiencing the same behavior with their wave executable. regards, Faisal Vali My executable does the same thing, so it is indeed a bug. I'm sure Hartmut will fix this shortly. Regards, Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [ANN] New Version of the Wavepreprocessorlibraryreleased (Isthis a bug?)
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 whether this is truly standard behavior): #define C C #if C X() #endif Wave spits out that this is an ill-formed preprocessor expression - Is that true? From my reading of the standard this should first get transformed into: #if 0 X() #endif Can someone explain or confirm what the expected outcome should be, and whether it is my compilation of wave that is broken? As Paul Mensonides already wrote, Wave shows clearly wrong behaviour here. This bug has been fixed. You can get the corrected version from the Spirit CVS. Thanks for reporting this problem. Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: Finite State Machine framework
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 are other use cases that don't work with the current interface.
Regards,
Andreas
I vote for both interfaces. If feature is easy to implement and
if it allows to avoid even forward state declaration than why
not ? I think you are right and initial state template parameter
will simpify code, but allowing default InnerInitial =
detail::empty_list as you did it for state template will allow
complete removing of
initial state from interface.
BTW what about run-time selection of initial states ? :
StopWatch::StopWatch()
{
if( ... )
initiateMyInitialState1();
else
{
initiateMyInitialState2();
initiateMyOrthohonalInitialState2();
}
}
That'd be such a use case then ;-). I'll support this in the next release
(in about a week).
Thanks,
Andreas
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Some questions on the FSM submission
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 all non-trivial programs using FSMs. It could be argued that this is really just one large FSM, but I like to think of them in terms of discrete FSM that It is indeed sometimes beneficial to use orthogonal regions instead of multiple FSMs, but only sometimes. interact with each other because it makes it easier to conceptualize class structure, threading, and occasionally inter-process or in the case of a distributed application, inter-system partitioning. I absolutely agree. That being said, I have the following questions (note these are not criticisms of the library or even a formal review - I'm trying to understand how it fits into my own work to decide how much time to invest in it). If I understand the documentation correctly, the submission is geared more towards creating hermetically sealed FSM mechanisms than for describing multiple interacting FSM's. Is this correct? No, but you are right in your observation that there's currently not much support for interacting FSMs. Most importantly, the current library is single-threaded, there's no support yet for FSMs running in their own threads. I made the current submission so that people can review the event processor and the way how they can build FSMs, which IMO is the most important part of an FSM library. Threading-support (and support for inter-FSM communication) will follow as soon as I'm convinced that there are no major problems with the current code. Also, I have some need to deal formally with Petri Networks. Related to FSM and automata theory in general, has any thought been given to supporting this class of FSA? No. I know little about these subjects. Can you recommend any books? I'm not a big UML fan so this aspect of the submission troubles me a little. Do we have a lot of UML fans here? I would be happier if it AFAICT, UML is the only internationally standardized modelling 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. No? Regards, Andreas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: I/O library status
| -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 efficient and arguably more readable: | | cout | My first line \n | My second line; Are you sure that this is more efficient? cout My first line endl My second line; has proven LESS efficient and I suspect the flush caused by encountering \n will have the same effect. Of course, the differences are tiny in practice. I view the newl as much clearer. And the concept that endl actually writes the buffered output doesn't seem too complicated. As a non-C programmer, \n looks plain nasty to me :-( 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] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Review Request: cyclic_buffer
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 +421(2)5930-0721 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Command Line Config review results
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 changes, many of which are documented on Wiki [1], and since the author himself keeps track of the issues, I won't reiterate them here - except for stressing the need for a) extensively reworked and extended documentation, and b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. Also, as acting on the review comments should result in large number of interface and design changes, I suggest that after incorporating them in the library and before the public release the author posts a note to the list so that the interested parties have a chance to comment on the final version. Once again, thanks to the author and all the reviewers. Aleksey Gurtovoy Command Line Config Review Manager [1] http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Optio ns_Library_Pages ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Imminent Code Breakage
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 the sandbox prior to that? // Fredrik Blomqvist ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Better Intel-Win32 support
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 _WCHAR_T_DEFINED to detect native wchar_t support: the windows headers will define this when wchar_t has been defined as a typedef (and wchar_t is not a native type). There appears to be no way to actually tell whether wchar_t is a native type or not with Intel. One other point: turning wchar_t support on may cause linker errors because you have now changed the name mangling of functions that take wchar_t as an argument - I don't know for sure but I would expect this to affect the std lib. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
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. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_metrsect.asp Take a look at their brain-damaged metered section semaphore implementation. Note that MS auto-reset event is nothing but a binary sema (well, brain-dead pulsing aside for a moment). Thx for the link, but I don't get it. How is Microsoft implementation of semaphore is showing that all implementations of semaphore should be avoided? It is showing that semas (e.g. bin-semas aka auto-reset events) are really error-prone. Their implementation of counting semaphore using a mutex (well, they actually use a totally brain-damaged dying spinlock) plus a binary semaphore is buggy (it contains erroneous synchronization). Now... you might to follow this link: http://google.com/groups?selm=3CE0BCD3.EF695748%40web.de (Subject: Re: The implementation of condition variables in pthreads-win32) regards, alexander. -- Pthreads win32 is just trying to be a general pupose condition variable as defined by the pthreads standard, suitable for any and all threads to go around calling pthread_cond_wait() and pthread_cond_signal() on. As a consequence the implementation contains several mutexes, semaphores etc, and a flow of control that will make your brains dribble out of your ears if you stare at the code too long (I have the stains on my collar to prove it ;-). Such are the joys of implementing condition variables using the Win32 synchronization primitives! -- http://tinyurl.com/b9vw ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Some questions on the FSM submission
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 but I wouldn't be surprised if you encounter non-trivial problems. I started out developing on MSVC7.0 and MSVC7.1 but I had to drop 7.0 because it caused too many problems. Only one way to find out. Please do not hesitate to contact me if I can be of any help! Thanks - I will. BTW, I assume you are going to pass fsm::event subclass objects between threads. fsm::event is intrusively reference counted and already does the necessary locking when you use boost::intrusive_ptr. However, nobody else has reviewed the locking for potential race-conditions and the like (as should be done with all multithreading code). If you want to be on the safe side you can use boost::shared_ptr, but can then no longer use event deferral (see also Event deferral chapter in the tutorial). This sounds a little scary given my schedule. I'm going to try it anyway. And if things get too out of control, then I'll fall back to something simpler (i.e. nested case-statement FSM implementation) and come back to it in several weeks when I've got more time. I think there's little I can do. When it comes to inter-FSM communication, one needs to make sure that a) the FSM event queue is absolutely bullet-proof regarding MT, b) FSMs commuicate with events only and c) the events will never contain references and pointers to data that is simultaneously accessed by multiple FSMs. I think there's a lot that we can do to codify this generically and satisfy practical and aesthetic requirements. I'll hold my comments until I've become familiar with your library design and spent some quality time staring at William Kempf's boost::thread (I'm currently using a thread library I wrote myself that is inferior to boost::thread but it does what I need and I understand and trust it). Thanks for all the hard work and inspiration Boosters! - Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Better Intel-Win32 support
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 result for conditional compilation in the traditional sense. Template instantiation comes after preprocessing ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Better Intel-Win32 support
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 everyone will immediately switch to BBv2 Real Soon Now 2.0 wink. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Better Intel-Win32 support
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 _NATIVE_WCHAR_T_DEFINED indicates the presence of the native type in MSVC 7.0+. However, use of this can cause a number of problems with existing MS libraries (and especially anything that deals with COM). The documentation is very confusing regarding this. First we have under Predefined Macros: _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED Defined when wchar_t is defined. Typically, wchar_t is defined when you use /Zc:wchar_t or when typedef unsigned short wchar_t; is executed in code. which implies that both the macros above are defined in both cases. Next we have under the compiler switch /Zc:wchar_t (wchar_t Is Native Type): When /Zc:wchar_t is specified, _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED symbols are defined; see Predefined Macros for more information. which simply reiterates the first part of the previous topic. Testing this out, both VC++ 7.0 and VC++ 7.1 yield the same result which confirms what you have written above. When the /Zc:wchar_t switch is used, both of the above macros are defined. When the /Zc:wchar_t is not used, only the _WCHAR_T_DEFINED macro is defined. So I was definitely wrong in thinking that there was no way to test for the difference. Perhaps the previous documentation which I read didn't explain the _NATIVE_WCHAR_T_DEFINED macro or perhaps I just missed it. But this is good for Boost. Now there is a way to determine whether which of the wchar_t types in VC++ are being used at compile time. My suggestion for Boost is that it use library implementors use this in order to alert the end-user at compile time that a particular usage of wchar_t is not supported, or use it to correctly link in the correct version of the library when both are supported. For VC++, the #pragma comment(lib,SomeLib) specifies the name of the library to link, either import or static. I know John Maddock does this in Regex++ but the general usage for our wchar_t, reiterated here, would be: #if defined(_NATIVE_WCHAR_T_DEFINED) #pragma comment(lib,NativeWchartVersion.lib #elif defined(_WCHAR_T_DEFINED) #pragma comment(lib,VCWchartVersion.lib) #endif Of course I expect Boost may want to create BOOST_ macros for these VC++ specific macros in the correct configuration file and use them instead, but one gets the general idea from this. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: no semaphores in boost::thread
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 crappy job at implementing them, the response could be to provide a special implementation using mutexes and cv's *for the MS platforms*, and using native implementations when possible. As boost doesn't, there must clearly be other reasons for them not to do that. Regards, Stefan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Imminent Code Breakage
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 you perhaps add the updated documentation to the sandbox prior to that? Why bother putting it in the Sandbox when I can put it in the regular Boost CVS? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: no semaphores in boost::thread
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 Alexander's point (which is easy to do, with his communication style... in this case he points you to a good example, but fails to explain why it's a good example). His point is that the MS concept of an auto-reset event is the same thing as a binary semaphore. The MeteredSection concept in this article was implemented using an auto-reset event (bin-semaphore), and on the surface looks like a reasonable implementation. However, if you do a thorough analysis of this implementation you'll find that it's prone to race conditions. Another great example is the attempts to implement a condition variable concept using semaphores, as has been done sooo many times on Windows. Nearly every attempt has been flawed, and the valid solutions are extremely complex. If all that is wrong is that microsoft does a crappy job at implementing them, the response could be to provide a special implementation using mutexes and cv's *for the MS platforms*, and using native implementations when possible. MS's actual semaphore is as valid an implementation as any other (Alexander will claim them to be brain damaged, but that's because of the design, not the implementation). As boost doesn't, there must clearly be other reasons for them not to do that. There is, but the explanations are long and quite complex. That's why the FAQ points you at a seminal paper on the subject, rather than attempting to explain it. Like I've said in numerous arguments about the Event concept, the problem with the concept isn't that it's broken or unusable, only that it's difficult to actually use correctly. Most users think their code is correct, when in fact they have race conditions waiting to bite them. When Mutexes and Condition variables provide everything that Semaphores and Events do, but in a way that's easier to use correctly, the choice to not include Event's or Semaphore's is reasonable. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
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 about -- the predicate checking -- With stateful primitives, such as binary semaphores, the wakeup in itself typically means that the wait is satisfied. The burden of ensuring correctness for such waits is thus placed on all signalers of the semaphore rather than on an explicitly coded Boolean predicate located at the condition wait. [...] But what's the relation between Microsoft implementation of semaphore, Damn. I should have called it metered section... without any mentioning that it's a counting semaphore. The point is that that code does illustrate the error-proness that POSIX rationale is talking about. pthread win32 implementation of condition http://groups.google.com/groups?selm=3CEA2764.3957A2C8%40web.de and the error-proness of semaphores versus mutexes/conditions in general? In general, you don't need semas for threading and you do need mutexes and condvars. Mutexes and condition variables together constitute an appropriate, sufficient, and complete set of inter- thread synchronization primitives. Is it simply a mather of preference and style, or is there a simple case to show why semaphores are error-prone instead of mutexes/conditions? Again, MS-metered section example IS a simple case to show why semaphores are error-prone instead of mutexes/conditions. regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Some questions on the FSM submission
[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. No? Scott Woods pointed out SDL (an ITU coding standard?) and remarks that in his opinion, it does a better job of handling FSM systems than UML. I'm not familiar with SDL. Check Scott's post for more information. Specification and Description Language also known as ITU Z.100. Check it out at; http://www.sdl-forum.org/SDL/ Authors might be a little put out that they are not on the list of internationally standardized modeling languages for FSMs ;-) UML certainly is on the list and is also the darling of the software industry. SDL is the equivalent for telecoms. As a consequence its pretty good for specifying large communities of distributed, co-operating FSMs. There is a large quantity of code running in switching networks that is based on SDL documentation, e.g. ITU-T Q.931 (ISDN PRI). Support your incremental approach to your FSM library Andreas. Have followed your work for a while and dont have anything to say that I havent said already. Good stuff, SW ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
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: http://www.amazon.com/exec/obidos/ASIN/0387954015/104-6312782-0737542 regards, alexander. -- http://groups.google.com/groups?selm=3D58D3BC.6D42748B%40web.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shared_cyclic_ptr question
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 an object can somehow access it's object
header when the object was allocated on the heap with a placement operator
new();
Given:
Node = element of a possible cyclic graph allocated on the heap.
Entity = possible cyclic graph in its entirety allocated on the heap.
struct entity_header
{
int count;
};
struct node_header
{
int count;
entity_header * p_entity;
};
// Erroneous but simple allocation example:
inline void * operator new (size_t s, gc const )
{
return malloc(s + sizeof(node_header)) + sizeof(node_header);
}
template typename T
struct smart_pointer
{
template typename U
smart_pointer(U * p) : m_p(p)
{
if (is_on_the_stack(this))
{
// Allocate an entity_header and affect its address to
m_p's header-p_entity. *
// Initialize m_p's header-p_entity-count to 1.
}
// 'this' is part of a node with a header on the heap.
else
{
// Copy the this's header-p_entity to m_p's
header-p_entity. **
}
...
}
template typename U
smart_pointer(smart_pointerU const p) : m_p(p.m_p)
{
// Possible merge / fragmentation of two entities. ***
...
// Possible incrementation / decrementation of this's
header-p_entity-count and m_p's header-p_entity-count.
}
~smart_pointer()
{
if (m_p m_p's header-p_entity-count == 1)
{
// Force an entity's destruction. *
}
}
...
private:
T * m_p;
};
Then:
An entity_header will be allocated each time a pointer on the stack refers
to a new node on the heap (*) and every other node derived from this root
node will refer to the same entity_header with node_header::p_entity. If a
new pointer on the stack refers to the entity, its entity_header::count will
be incremented. If the last pointer on the stack refers to the entity then
the entire entity will be destructed (no more possible cyclic graph).
Ex.:
template typename T struct rope; // cyclic entity
smart_pointer ropeint p = new (gc) ropeint(10);//
entity_header::count == 1
smart_pointer ropeint q = p;// entity_header::count == 2
p.~smart_pointer ropeint ();// entity_header::count == 1
q.~smart_pointer ropeint ();// entity_header::count == 0,
destruction
Thus:
The purpose of the entity_header is to know the number of times the entity
is refered by a pointer on the stack.
Do this algorithm already has a name? If so, why aren't you using it since
there is no need to scan the graph looking up for dangling entities. It may
take a little bit more memory (1 more pointer per node + 1 entity_header per
heap graph) but I think the cost / benefits here are quite acceptable since
the speed will always be O(1).
Regards,
Philippe
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_cyclic_ptr question
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 object was allocated on the stack
or on
the heap;
- a smart pointer contained within an object can somehow access it's
object
header when the object was allocated on the heap with a placement
operator
new();
Neither of which can be done portably.
Given:
Node = element of a possible cyclic graph allocated on the heap.
Entity = possible cyclic graph in its entirety allocated on the heap.
struct entity_header
{
int count;
};
struct node_header
{
int count;
entity_header * p_entity;
};
// Erroneous but simple allocation example:
inline void * operator new (size_t s, gc const )
{
return malloc(s + sizeof(node_header)) + sizeof(node_header);
}
template typename T
struct smart_pointer
{
template typename U
smart_pointer(U * p) : m_p(p)
{
if (is_on_the_stack(this))
{
// Allocate an entity_header and affect its
address to
m_p's header-p_entity. *
// Initialize m_p's header-p_entity-count to 1.
}
// 'this' is part of a node with a header on the heap.
else
{
// Copy the this's header-p_entity to m_p's
header-p_entity. **
}
...
}
template typename U
smart_pointer(smart_pointerU const p) : m_p(p.m_p)
{
// Possible merge / fragmentation of two entities. ***
...
// Possible incrementation / decrementation of this's
header-p_entity-count and m_p's header-p_entity-count.
}
~smart_pointer()
{
if (m_p m_p's header-p_entity-count == 1)
{
// Force an entity's destruction. *
}
}
...
private:
T * m_p;
};
Then:
An entity_header will be allocated each time a pointer on the stack
refers
to a new node on the heap (*) and every other node derived from this
root
node will refer to the same entity_header with node_header::p_entity.
If a
new pointer on the stack refers to the entity, its
entity_header::count will
be incremented. If the last pointer on the stack refers to the entity
then
the entire entity will be destructed (no more possible cyclic graph).
Ex.:
template typename T struct rope; // cyclic entity
smart_pointer ropeint p = new (gc) ropeint(10);//
entity_header::count == 1
smart_pointer ropeint q = p;// entity_header::count == 2
p.~smart_pointer ropeint ();// entity_header::count == 1
q.~smart_pointer ropeint ();// entity_header::count == 0,
destruction
Thus:
The purpose of the entity_header is to know the number of times the
entity
is refered by a pointer on the stack.
Do this algorithm already has a name? If so, why aren't you using it
since
there is no need to scan the graph looking up for dangling entities.
It may
take a little bit more memory (1 more pointer per node + 1
entity_header per
heap graph) but I think the cost / benefits here are quite acceptable
since
the speed will always be O(1).
Regards,
Philippe
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
