On Thursday 12 June 2003 17:05, William E. Kempf wrote:
> JOLY Loic said:
> > 1/ Dynamic libraries
> > Although I compiled boost with the option "-sBUILD=debug release
> > static/dynamic", the library is still generated as a DLL.
> > I do not exactly know what is meant by "static" in this case.
>
>
Hi Thorsten,
Thank you for your feedback.
> You can avoid your handcoded loop by something like
>
> transform( ..., &address_of );
>
I suppose that's true. If you have a unary address_of() function, you can do
it cleanly enough with a transform.
> What would have been nice was some kind of temp
Title: RE: [boost] [filesystem] "." directory-placeholder added
From: Beman Dawes [mailto:[EMAIL PROTECTED]]
>There are a bunch of reasons - but particularly it would be creating
>names that will just be rejected by many (or even most) modern operating
>systems. What would be the point of th
On Thu, 2003-06-12 at 22:12, Stefan Seefeld wrote:
> I'm wrapping libxml2. The structs provided by libxml2 all carry a
> '_private' member, precisely because it's a good way for extensions
> such as language wrapping.
> libxml2 itself calls callbacks whenever it allocates instances of these
> stru
William E. Kempf wrote:
JOLY Loic said:
Hello,
I am currently trying to use the Boost.Threads library on windows (VC++
7.0 and 7.1 compilers), and I wonder about some points :
[...]
What I know is I would appreciate to link fully statically with a .lib
file and no .dll at run-time.
On Thursday, June 12, 2003, at 12:43 PM, Nigel Stewart wrote:
I can see the appeal here in using a circular buffer in
this manner, while at the same time I'm cooling against
the compromise of "insert auto-resizes, while push doesn't"
which seems inconsistant. Give
At 01:31 PM 6/12/2003, Daryle Walker wrote:
>On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
>
>> An updated version of Boost.Filesystem has been added to CVS. The
>> primary change is adding "." as a directory-placeholder to the generic
>> path grammar.
>>
>> This solves the problem o
Hamish Mackenzie wrote:
Looks good. I have only looked at the dom stuff so far. Why are you
storing information in _private? What goes in there that could not be
extracted when the nodes are accessed? It seems like a lot of
unnecessary overhead.
I'm wrapping libxml2. The structs provided by lib
Looks good. I have only looked at the dom stuff so far. Why are you
storing information in _private? What goes in there that could not be
extracted when the nodes are accessed? It seems like a lot of
unnecessary overhead.
Here are some suggestions...
1) parse_file could be
class parse_file
{
Hi,
the attached patch changes the order in which compilers are checked in
config/select_compiler.hpp. This is required to detect Comeau C++
with gcc backend correctly.
ok to apply?
Regards,
m
Index: select_compiler_config.hpp
===
RC
Larry Evans wrote:
[snip]
Any comments? Maybe this method could be used
Yeah. What happens when ostream destructor is called.
Since this probably calls the streambuf destructor,
and if the streambuf is actually a fwd_streambuf,
and the ~fwd_streambuf resets the ostream.rdbuf,
this just may be a
Larry Evans wrote:
[snip]
The prototype of the "using overflow+sputc" method is in
files/col_io/test_fwd_streambuf.zip.
A more complete marg_ostream example is in
files/col_io/test_marg_ostreambuf.zip. It
shows how an ostream indentation can be changed
without resorting to a wrapper class like
mar
On Thursday 12 June 2003 01:31 pm, Daryle Walker wrote:
> On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
> > An updated version of Boost.Filesystem has been added to CVS. The
> > primary change is adding "." as a directory-placeholder to the generic
> > path grammar.
> >
> > This solve
"William E. Kempf" <[EMAIL PROTECTED]> wrote:
> ...The warnings are known and will
> be fixed soon. Ignore them for now.
I have built the dll version of the threads library several times, with the
mentioned warnings, which I ignore. However, once in a while I get one or
two unamed errors (i..e.,
Maxim Egorushkin wrote:
> I posted here a while ago streambuf adapters. There was no any answer. May
> be you might find it intresting.
>
> The main idea is simple: to present any linear sequence as
> std::basic_streambuf<>.
Yes, this is very elegant. No codecvt's in sight -- just pure adaptors.
On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
An updated version of Boost.Filesystem has been added to CVS. The
primary change is adding "." as a directory-placeholder to the generic
path grammar.
This solves the problem of distinguishing between an empty path and
one that acts a
deque is more expensive than a resizing circular buffer in both
performance and code size. One also can not control *when* deque will
allocate as one can with a resizing circular buffer. In a nutshell, a
resizing circular buffer is often a better deque than std::deque is.
;-( A resizing circ
>
> No, there is no MFC dependency. Changing your project settings to use the
> MFC dll cleared the warnings because this change also effects how you link
> against the C RTL. When you tried to compile the project with no MFC you
> got the error you did because you failed to compile against a
> m
Adrian Michel said:
> I am using MSVC 6, but I run into the same problem. Changing the project
> settings to use the MFC dll cleared the warnings.
>
> Moreover, I tried to run my project with no MFC support and I got this
> message:
> d:\documents and
> settings\administrator\desktop\dev\boost_1_3
William,
>
> I did look deeper into the problem, but there seems to be some hidden MFC
> dependency in the thread libraries.
This should read "I did _not_ look deeper...".
Other than this very minor issue, the thread library works beautifully and I
am not planning on using any native thread APIs
I am using MSVC 6, but I run into the same problem. Changing the project
settings to use the MFC dll cleared the warnings.
Moreover, I tried to run my project with no MFC support and I got this
message:
d:\documents and
settings\administrator\desktop\dev\boost_1_30_0\boost\thread\thread.hpp(17)
:
Peter Dimov wrote:
Looks reasonable, but we don't want the architecture of the backend to
affect the interface.
right. So what is would be reasonable semantics to expect from a dom API
? May be I'v just got used to libxml2's way of life, but I think it is
a good choice. Nodes are owned by their pa
Adrian Michel said:
>> 2/ The use of DLL-exported classes that derive from or uses as member
>> variables non-DLL-exported classes is generating some warnings by msvc
>> that fall into two categories (4275 and 4251). Would it be possible to
>> insert #pragma to remove these spurious warnings ?
>>
An updated version of Boost.Filesystem has been added to CVS. The primary
change is adding "." as a directory-placeholder to the generic path
grammar.
This solves the problem of distinguishing between an empty path and one
that acts as a placeholder.
This change does change some existing behav
Hello,
I am currently trying to use the Boost.Threads library on windows (VC++
7.0 and 7.1 compilers), and I wonder about some points :
1/ Dynamic libraries
Although I compiled boost with the option "-sBUILD=debug release
static/dynamic", the library is still generated as a DLL.
I do not exact
JOLY Loic said:
> Hello,
>
> I am currently trying to use the Boost.Threads library on windows (VC++
> 7.0 and 7.1 compilers), and I wonder about some points :
>
> 1/ Dynamic libraries
> Although I compiled boost with the option "-sBUILD=debug release
> static/dynamic", the library is still genera
> 2/ The use of DLL-exported classes that derive from or uses as member
> variables non-DLL-exported classes is generating some warnings by msvc
> that fall into two categories (4275 and 4251). Would it be possible to
> insert #pragma to remove these spurious warnings ?
>
These warnings are generat
Stefan Seefeld wrote:
> Peter Dimov wrote:
>>
>> I think that there is considerable interest in a boost::xml library.
>> But...
>>
>> Document *document = Document::parse_file(argv[1]);
>>
>> ... I don't believe that a raw pointer based interface is acceptable.
>>
>> xml::dom::document docu
Peter Dimov wrote:
Stefan Seefeld wrote:
Is there any interest in this library evolving
into a boost::xml library ? If so, what needs to change,
what needs to be added / removed ?
I think that there is considerable interest in a boost::xml library. But...
Document *document = Document::pars
Stefan Seefeld wrote:
>
> Is there any interest in this library evolving
> into a boost::xml library ? If so, what needs to change,
> what needs to be added / removed ?
I think that there is considerable interest in a boost::xml library. But...
Document *document = Document::parse_file(argv[1
Larry Evans wrote:
[snip]
with buffered input. After thinking some more, I thought about just
using overflow and sputc to "pipe" the output to the next streambuf.
This greatly simplified the code. Would something similar work with
[snip]
The prototype of the "using overflow+sputc" method is in
f
Maxim Egorushkin wrote:
[snip]
I posted here a while ago streambuf adapters. There was no any answer. May
be you might find it intresting.
Sorry I overlooked it.
The main idea is simple: to present any linear sequence as
std::basic_streambuf<>.
It sounds like what people, in particular Robert Rame
Reece Dunn wrote:
This means having a conversion manager in the traits class, e.g.
agreed. It's already there, have a look !
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gennadiy Rozental wrote:
Here is my vision on the problem, couple ideas on XML parser design:
1. No xmlChar type -> template parameter
hmm, what code did you look at ? I *do* use templates for this. I use
'xmlChar' internally as that's the type used by libxml2. But that
part is private, the publ
Gennadiy Rozental wrote:
1. No xmlChar type -> template parameter
namespace xml {
template
class parser {...};
}
I agree with this, but think that the basic problem is with the underlying
implementation. The xml++ implementation makes use of libxml2, who's
underlying representation is xmlChar.
> This discussion was a long time ago, but I didn't get the end of it.
> As building the thread library I get a lot of warnings I would like
> to remove them somehow (I'm using the 1.30 release version).
>
> So, what would you suggest? Using pragma's is safe enough?
> If yes, where is the best plac
Hugo Duncan wrote:
> Aleksey and all,
Hi Hugo,
>
> mpl::size returns integral_c on gcc, vc7.1 but
> integral_c on bcc564.
>
> Is this intentional?
Nope, it's a bug. Fixed in the main trunk.
Thanks for the report,
Aleksey
___
Unsubscribe & other ch
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thanks for your interest. I have posted the library at
> http://groups.yahoo.com/group/boost/files/streambuf_lib/.
>
> The implementation needs to be streamlined, but it works, and the main
ideas
> are clear enough
Hi Eric,
First of all, thanks for the report!
Eric Friedman wrote:
> I've found that mpl::is_sequence fails to operate correctly on
> certain types under MSVC7.
To be precise, on class types that have a member named 'begin' that is
not a typename.
> I haven't tested extensively, but there cer
Hi Alex,
> There are many more possibilities beyond those described here. Does this
> sound interesting to anyone
I don't have time to comment very thoroughly, but I can say that it does
sound
interesting. In the project I'm working on now I needed to sort the pointers
from
several containers
40 matches
Mail list logo
