Re: [system][filesystem v3] Question about error_codearguments

On 10/31/09 12:48, Andrey Semashev wrote:
> Detlef Vollmann wrote:
> 
>> But the basic problem of throwing exceptions from destructors exists,
>> and is IMO a major flaw of how exception handling works in C++,
>> but I don't think that this will change.
> 
> FWIW, the language allows to work around this problem. You can use 
> std::uncaught_exception to detect whether to throw exception in a 
> destructor or not.
This was already discussed earlier in this thread.
And the issue is not so much that uncaught_exception() doesn't
always return what you want to know ("is it safe to throw?"),
but the exception safety guarantees that break if a destructor throws.

> Regarding the original idea of returning an object that would throw in 
> its destructor, I don't see this problem at all, as this object can only 
> be returned if there is no exception propagating. However, I can't say 
> I'm in favor of this idea.
I still somehow like it, but there are to many problems with it.

   Detlef

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [system][filesystem v3] Question about error_codearguments

On 10/31/09 04:49, Gottlob Frege wrote:
> bool diff(file srcA, file srcB, file output)
> {
>    // get our files ready...
>    error_code srcA_err = file_open(srcA);
>    error_code srcB_err = file_open(srcB);
>    error_code out_err = file_open(output);
> 
>    if (srcA_err || srcB_err || out_err) // check for errors
>       return false;
> 
>    // do the diff...
> 
>    return true;
> }
> 

> So that took a bit of thought for me to come up with, but the code
> doesn't look completely unreasonable, does it?
Hmmm, that depends on your background.
If you look at a respective POSIX program:

   int srcA_err = open(srcA);
   int srcB_err = open(srcB);
This will overwrite errno.
So system level programmers are used to write:
   int err = open(srcA);
   check_error(err, "first source file");
   err = open(srcB);
   check_error(err, "second source file");

Cross-platform date/time problems

Hello list,

Apologies for the cross-posting, this originally went to the boost-users
list but it got no responses, and then I also realized it was actually more
appropriate here.

Suppose I have a cross-platform agent that communicates with a server.
Agent from platform X sends a message to the server which contains a
date/time.  Server sends a message to another agent running platform Y with
the same date/time.  In practice X/Y are always either windows/linux or
linux/windows.  The server always tells the agent which platform's native
format the time is represented in, so there should be no problem.  Ideally
I'd like to write the following code:

    ptime time;
    if (msg.is_from_windows())
    {
        time = from_ftime<ptime>(msg.time());
    }
    else
    {
        time = from_time_t(msg.time());
    }

But this doesn't work because from_ftime<> is not defined on linux.  If
from_ftime<> is already templated on the FILETIME type, is there any reason
it needs to be #ifdef'd out on non-windows platforms?    I mean, a FILETIME
is really just a uint64, can't the templated function also just operate on a
boost::uint64_t?

Re: loglite - A logging library (JD)

On Thu, Oct 29, 2009 at 11:28 AM, Emil Dotchevski
<emildotchevski <at> gmail.com>wrote:

> On Wed, Oct 28, 2009 at 11:44 PM, Tan, Tom (Shanghai) <TTan <at> husky.ca>
> wrote:
> >>  Please have a look and let me know what you think could be improved.
> > The first thing I notice is that it does not support std::wstring
> > directly. It's a big problem in my case I use wide-character in all my
> > applications, which simplifies dealing with UTF-16 adopted by Modern
> > Windows platforms.
> >
> > If I need to any string info from my program, I'll have to convert from
> > UTF16(represented as std::wstring) to UTF8 so that it could be working
> > well with LOGLITE. That's inconvenient.
>
> OTOH, if you are targeting any other platform in addition to Windows,
> it probably makes more sense to adopt UTF-8 throughout your program
> and convert to UTF-16 before calling Windows functions.
>
> > Offtopic, I am expecting boost::filesystem V3 for this very same reason.
>
> Way offtopic, I also find path/wpath problematic. In my mind, their
> invariant doesn't differ enough from that of string/wstring to justify
> coupling my interfaces with boost::filesystem. So I use UTF-8
> string/char const * in my code on all platforms, and use
> boost::filesystem as an implementation detail, through wrappers that
> take UTF-8 strings.
>

I've always found it was easiest to do something like:

Re: Cross-platform date/time problems

Zachary Turner wrote:
> Hello list,
> 
> Apologies for the cross-posting, this originally went to the boost-users
> list but it got no responses, and then I also realized it was actually more
> appropriate here.
> 
> Suppose I have a cross-platform agent that communicates with a server.
> Agent from platform X sends a message to the server which contains a
> date/time.  Server sends a message to another agent running platform Y with
> the same date/time.  In practice X/Y are always either windows/linux or
> linux/windows.  The server always tells the agent which platform's native
> format the time is represented in, so there should be no problem.  Ideally
> I'd like to write the following code:
> 
>     ptime time;
>     if (msg.is_from_windows())
>     {
>         time = from_ftime<ptime>(msg.time());
>     }
>     else
>     {
>         time = from_time_t(msg.time());
>     }
> 
> But this doesn't work because from_ftime<> is not defined on linux.  If
> from_ftime<> is already templated on the FILETIME type, is there any reason
> it needs to be #ifdef'd out on non-windows platforms?    I mean, a FILETIME
> is really just a uint64, can't the templated function also just operate on a
> boost::uint64_t?

Re: [1.41.0] Release branch closed for all changes; beta RC tomorrow

> The release branch is closed for all changes. Unless someone objects
> strenuously, I'll build a release candidate for the beta tomorrow
> (Tuesday) morning, eastern US time.

using the current release branch, i get the following warnings
(gcc-4.4.1, x86_64-linux-gnu)

libs/boost/boost/exception/detail/exception_ptr_base.hpp:17: warning:
'class boost::exception_detail::exception_ptr_base' has virtual
functions and accessible non-virtual destructor
[snip]
libs/boost/boost/exception_ptr.hpp:43: warning: 'class
boost::exception_ptr' has virtual functions and accessible non-virtual
destructor

hth, tim

--

-- 
tim <at> klingt.org
http://tim.klingt.org

Life is really simple, but we insist on making it complicated.
  Confucius

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Time for another bug sprint (after 1.41 ships)?

On Sep 21, 2009, at 9:53 AM, I wrote:

> Earlier this year, we had a "bug sprint", where many people focused  
> on fixing bugs in Boost.
> We managed to get the # of open tickets down from 800 to about 720.
>
> As of today, there are 820 open tickets in Trac.
>
> Is it time to focus on swotting bugs again?
>
> 1.41 is scheduled for release on 1-November; that's six weeks from  
> yesterday.
>
> How about a bug sprint starting on 14-November, finishing on 22- 
> November?
> That's two weekends - and finishes up before the American  
> Thanksgiving holiday.
>
> -- Marshall

Who is up for this?

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Parallel Tree Merge

> If I have a representation of a tree and I have sub-portions of it spread
> across a number of processes (but the whole tree represents a well-formed
> and simple tree structure). Is there a reasonably straightforward way of
> doing this using BGL or PBGL. I had hoped that it might be as simple as
> defining some templated tree structure and using the add operator after
> gathering pieces onto one node.
>
> (The tree structure could be represented as XML where the root would exist
> on all processes, different sub-nodes and leaves and would occur on
> different processes - a simple xml merge would probably suffice for my needs
> right now).
>
> If examples using boost libraries ((p)BGL/MPI) or other similar combination
> exist and anyone can point me to resources I'd be most grateful. (I'm not an
> expert with BGL so will need some do some learning...)
>

Hi John,

You may want to re-post this with "[BGL]" or "[graph]" in the subject. The
people who are best-qualified to answer this question may be filtering posts
on those topics - I know I do.

Andrew Sutton
andrew.n.sutton <at> gmail.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Time for another bug sprint (after 1.41 ships)?

Marshall Clow wrote:
> Who is up for this?
Count me in ;)

--

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Time for another bug sprint (after 1.41 ships)?

> Who is up for this?

Good idea - but here's another suggestion - it would be great if someone 
could do an audit of release and trunk branches and see what hasn't been 
merged but should have been.  I get the impression that some folks have 
committed fixes to Trunk and then forgotten all about them 

Of course hopefully I'm wrong and there's nothing to actually do....

John. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost