headers
Christopher Kohlhoff | 1 Nov 01:07
Favicon

Re: [system] Problem with error_code.hpp dependency on winerror.h


On Wed, 31 Oct 2007 19:50:04 -0400, "Beman Dawes" <bdawes <at> acm.org> said:
> Emil Dotchevski wrote:
> > Perhaps the enum should be placed in a platform-specific header, for
> > example "boost/system/windows/error_code.hpp"?
...
> I'll go ahead and put in the BOOST_SYSTEM_NO_ENUM #ifndef. That will at 
> least allow users to avoid the system-specific enums if they wish. But 
> the enums provide a really nice facility for dealing with 
> system-specific errors, so I don't recommend using BOOST_SYSTEM_NO_ENUM 
> except in unusual circumstances.

I find the suggestion of separate header files a nice idea. We can
restrict system/error_code.hpp to only those interfaces specified for
C++0x, and have a header file for each of the OS-specific namespaces
(with the same name as the namespace for convenience), i.e.
system/windows_error.hpp, system/linux_error.hpp,
system/cygwin_error.hpp, and so on. Developers have to use the
OS-specific namespace qualification to refer to those error codes
anyway, so it doesn't seem like much extra burden to include the
additional header file.

Cheers,
Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Emil Dotchevski | 1 Nov 01:09

Re: [system] Problem with error_code.hpp dependency on winerror.h

> >> Actually, the user *can* use the enum without <winerror.h>.
> >
> > I see this in error_code.hpp:
> >
> > namespace windows_error
> > {
> >   enum windows_error_code
> >   {
> >     success = 0,
> >     // These names and values are based on Windows winerror.h
> >     invalid_function = ERROR_INVALID_FUNCTION,
> >     file_not_found = ERROR_FILE_NOT_FOUND,
> >     path_not_found = ERROR_PATH_NOT_FOUND,
> >     ....
> >   }
> > }
> >
> > I don't understand how this enum can be compiled without including <winerror.h>.
>
> The <boost/error_code.hpp> header already includes <winerror.h>, so the
> user doesn't have to include it.

Seems like there is some kind of misunderstanding. :)

My original problem was triggered by the fact that
"boost/error_code.hpp" *attempts* to include <winerror.h>, and on my
Windows system <winerror.h> is not accessible "just like that" (I am
including "boost/error_code.hpp" in a CPP file which, although being
built using MSVC on Windows, does not see the platform SDK because
it's platform independent.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Marcin | 1 Nov 01:10

Re: [pimpl] Proposal. Determining interest.

Vladimir.Batov <at> wrsa.com.au wrote:
>> I've downloaded it, read the documentation, and I think it looks 
> promising.
>> To test it out I'm converting a pimpled class in my code base to use 
>> your library. This class is noncopyable and as such it isn't immediately 
> 
>> obvious to me whether the class should be modeled using the pimpl's 
>> value semantics, pointer semantics, or some other semantic that doesn't 
>> yet exist.
>>
>>
>> Thanks,
>>
>> Michael Marcin
> 
> Achieving non-copyability seems as straightforward as 
> 
> struct Foo : public pimpl<Foo>::pointer_semantics, boost::noncopyable
> {
> };
> 

Does this not use shared_ptr under the hood still?
Isn't that a bit inefficient?

Thanks,

Michael Marcin

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boris Gubenko | 1 Nov 01:13
Picon
Favicon

Re: [interprocess] inteprocess_exception is not defined

Ion Gaztanaga wrote:
> I see. But don't know what to do now;-)

After closer examination, it turned out to be a typo in
interprocess_recursive_mutex.hpp -- see patch below.

Ok to commit?

Index: posix/interprocess_recursive_mutex.hpp
===================================================================
--- posix/interprocess_recursive_mutex.hpp      (revision 40632)
+++ posix/interprocess_recursive_mutex.hpp      (working copy)
@@ -112,7 +112,7 @@
    int res = 0;
    res = pthread_mutex_lock(&m_mut);
    if(res != 0){
-      throw inteprocess_exception(system_error_code());
+      throw interprocess_exception(system_error_code());
    }
    assert(res == 0);

Thanks,
  Boris

----- Original Message ----- 
From: "Ion Gaztañaga" <igaztanaga <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Wednesday, October 31, 2007 11:15 AM
Subject: Re: [boost] [interprocess] inteprocess_exception is not defined
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel de Guzman | 1 Nov 01:41
Picon
Favicon

Re: [rfc] dynamic overload: a new version is out

Marco Costalba wrote:
> On 10/31/07, Marco <mrcekets <at> gmail.com> wrote:
>> A new release of boost overload is out.
>> You can find it under overload-mrcec in boost vault.
>> Link: http://tinyurl.com/2w4wob
>>
> 
> Compiles and runs for me: Mandriva with gcc 4.2.2
> 
> Impressive! almost a world apart from it's humble origins ;-)

Very good! Keep up the good work!

Regards,
--

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 11 comments |
headers
David Abrahams | 1 Nov 02:46
Picon
Picon
Favicon
Gravatar

Re: [1.35.0] Developer preparation


on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:

> Stefan Seefeld wrote:
>> Markus Schöpflin wrote:
>>> Stefan Seefeld wrote:
>> 
>>>> That doesn't explain why there were no failures prior to the 1.34
>>>> release. Are the current failures all on newly added platforms ? What is
>>>> different now from before 1.34 ?
>>> It still works on my test platform (COMSOFT), I'm using python 2.4.1. 
>>> Probably the python version used by the regression test runners have changed?
>> 
>> That's entirely possible (I read that Python's handling of default
>> search paths has changed on Windows with version 2.5).
>> 
>> This brings up a point I have been making for a long time:
>> 
>> Can the testing / regression harness be fixed to report more parameters
>> that affect the development / runtime environment ? In this particular
>> case: the python version is certainly a critical piece of information,
>> but it doesn't appear to be listed in the platform description.

Get the output from passing --debug-configuration when you invoke
bjam.  That tells everything one needs to know.

--

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Nov 02:50
Picon
Picon
Favicon
Gravatar

Re: [1.35.0] Tickets, Milestone, Testing


on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:

> Marshall Clow wrote:
>> Dave Abrahams wrote:
>>> http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority
>>> shows all the tickets that have been assigned to the 1.35.0 milestone.
>>> Does this list have any meaning?  In other words, are we actually
>>> intending to address all of these problems for 1.35, and put off other
>>> tickets for 1.35.1 or 1.36.0?
>> 
>> Personally, I'd like to see all the submitted patches "dealt with" for 1.35.
>> Either apply them or reject them. [ There are about 50 outstanding patches ]
>
> Patches seem a particularly high priority to me, too.
>
> I've reproduced the latest patch report from Marshall so we can all see 
> who the guilty parties are:-)
>
> Developers, now is a great time to clear your outstanding patches!

IMO, promising patches that are merely new features that haven't been
in testing for some time should be assigned to the 1.36.0 milestone
rather than "cleared" by either integrating them or rejecting them.

Patches should only be a high priority if they fix bugs... and in that
case they should come with a test that breaks until the bug is fixed.

--

-- 
Dave Abrahams
(Continue reading)

Permalink | Reply | 9 comments |
headers
Howard Hinnant | 1 Nov 03:16
Picon

Re: Comments about N2320

On Oct 31, 2007, at 12:45 AM, Johan Nilsson wrote:

> Howard Hinnant wrote:
>> On Oct 28, 2007, at 11:53 AM, Yuval Ronen wrote:
>>
>
> [snip]
>
>>> * Thread cancellation is new, and
>>> disable_cancellation/restore_cancellation are even newer. They are
>>> new for C++ programmers, and maybe new for *all* programmers (I  
>>> never
>>> heard
>>> of a language with them). I'm not sure if it's a good idea to
>>> standardize them before we get some real-life experience with thread
>>> cancellation.
>>
>> Actually thread cancellation is old.  Many (not all) thread API's
>> have some form or another of cancellation.  That being said, the
>> compromise reached at the Kona meeting 4 weeks ago was to remove
>> cancellation (or interruption) from the proposal.  This removal is
>> reflected in N2411.
>
> Oh, no. I think thread cancellation is a must-have in general, and  
> it would
> be really great to have it within the standard.
>
> It's not that it's a big problem to make/use composite cv  
> predicates, where
> one part holds the "cancel" part and the other the real stuff - but
(Continue reading)

Permalink | Reply | 14 comments |
headers
Gennadiy Rozental | 1 Nov 03:47
Picon

Re: [Test] debug.ipp breaking Windows CE tests


"David Deakins" <ddeakins <at> veeco.com> wrote in message 
news:fg7v3l$aqk$1 <at> ger.gmane.org...
> Hi Gennadiy,
>
> If you have a chance, can you please apply the attached debug.ipp patch
> for WinCE?  Because Windows CE does not have most of the ANSI versions
> of the Win32 functions or structures (only the wide-character versions),
> some of the code in debug.ipp fails to compile.  This causes all the
> regression tests for almost all libraries to fail.  Since automatic
> support for the debugger probably would not work as intended on a WinCE
> device anyway, the attached patch disables debugger support on Windows
> CE builds.

I've applied the patch, but can you figure out how to make these facilities 
to work on CE?

Gennadiy 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Gennadiy Rozental | 1 Nov 03:50
Picon

Re: [Test] Re: Unresolved symbols show up on the trunk


"David Deakins" <ddeakins <at> veeco.com> wrote in message 
news:fg83qu$tsk$1 <at> ger.gmane.org...
Markus Schopflin wrote:
> Gennadiy Rozental wrote:
>> Markus Schopflin <markus.schoepflin <at> comsoft.de> writes:
>>
>>> ld:
>>> Unresolved:
>>> boost::debug::under_debugger(void)

> I am seeing what may or may not be a related error under VC8 when
> building the prg_exec_monitor DLL.  The linker is reporting 2 unresolved
> symbols:

Thanks, fixed

Gennadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |

Gmane