Kim Barrett | 1 Apr 2011 01:04
Picon

Re: boost interprocess (>1.45) robust mutexes

On Mar 31, 2011, at 4:30 PM, Ion Gaztañaga wrote:
> El 31/03/2011 21:04, Kim Barrett escribió:
>> On Mar 31, 2011, at 2:41 PM, Kim Barrett wrote:
>>> I developed an API for robust mutexes and associated condition
>>> variables that has been in use for a while by my employer.
> 
> Thanks for the ideas. That would require adding a handler function to lock types, right? How does this work
with a typical condition variable wait loop? Shouldn't we notify the result to the caller?

Yes, the lock type associated with robust mutexes also needs to have
its locking and constructor functions take a handler function.

The caller provides the handler function.

So one has something like

class robust_mutex {
public:
    ... constructors & etc ...

    template<class Handler>
    void lock(Handler handler);

    void unlock();

    void set_consistent();
    void set_unrecoverable();
};

class robust_lock {
(Continue reading)

Cory Nelson | 1 Apr 2011 01:12
Picon
Gravatar

Re: [GSOC]SIMD Library

On Thu, Mar 31, 2011 at 3:07 AM, Mathias Gaunard
<mathias.gaunard <at> ens-lyon.org> wrote:
> On 31/03/2011 11:47, Cory Nelson wrote:
>
>> What would ever make intrinsics improper?
>
> GCC generates a compile-time error if you include the intrinsics files
> without the right option (-msse2 or similar) enabled with the compiler.
> For this reason, we took care of only including the files requested by the
> instruction set the user has chosen.
>
> Now then, I guess it would always be possible to cheat and redefine those
> things.

Is there a way to detect those compile options?  I think it would be
acceptable to just disable any support for them if -msse etc. aren't
given, and put a warning in the docs explaining it.  Does -msse/etc.
only enable those intrinsics, or does GCC actually try to use them
during code gen for plain C++?

--

-- 
Cory Nelson
http://int64.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Andrew Sutton | 1 Apr 2011 03:24
Picon

Re: GSOC2011 (Introduction)

> My name is Harinderpal Singh. I am from Lovely Professional University,
> Punjab, India. I am a fourth year B.Tech student. I have worked on c++. I
> also have basic knowledge of Mysql. I have competed in various inter college
> level competitions. I work on linux(ubuntu) and also have knowledge of
> windows. I don't have any experience with open source previously.I am
> interested in Checks & Hashes module

Hi,

Due to the number of people interested in submitting proposals, we
generally like students to have concrete goals in mind. If you have
specific ideas about what you want to work on, that would help us
evaluate your intentions and determine if your proposal is a match for
the organization.

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

Mostafa | 1 Apr 2011 04:20
Picon
Favicon

Re: [gsoc] Interest in BGL v2?

On Thu, 31 Mar 2011 07:02:43 -0700, Dave Abrahams <dave <at> boostpro.com>  
wrote:

> At Thu, 31 Mar 2011 08:53:02 -0500,
> Andrew Sutton wrote:
>>
>> I will say that our design does take a slightly more object-oriented
>> approach (g.size(), for example), but that hardly precludes
>> adaptation. Adaptors would have to be written as classes, but that
>> shouldn't be a big deal.
>
> I think you underestimate the cost of adaptation-via-wrapper and urge
> you to stick with free functions unless you have a really good reason
> to do otherwise.
>

Can you elaborate?

Thanks,

Mostafa

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

Andrey Semashev | 1 Apr 2011 04:24
Picon

Re: Boost.Log status

On 04/01/2011 01:42 AM, Vladimir Prus wrote:
>
> What I meant -- do you really want to work against Phoenix V3, which is bleeding
> edge and might not have yet be fully ready?

Are there other options? As I said in another reply, porting to Phoenix 
v2 is not very productive, especially when v3 is in SVN already. Not to 
do anything and wait until v3 gets more stable and mature? It might be 
ok, but I'd like to make all interface breaking changes before Boost.Log 
v2 is released and I don't want to delay the release that long.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Gordon Woodhull | 1 Apr 2011 04:56
Favicon
Gravatar

Re: [gsoc] Interest in BGL v2?

On Mar 31, 2011, at 10:20 PM, Mostafa <mostafa_working_away <at> yahoo.com> wrote:

> Can you elaborate?

Thanks Mostafa. I have the same Q.

Back in the day Jeremy told me he thought wrapper classes could be as efficient as function wrappers, but he
couldn't convince others, thus BGL is functional.  But I do remember seeing some convincing arguments
against wrappers since then.

Also, do concept maps (RIP) fix this? I seem to remember some blurring between OO and functional there.

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

Gordon Woodhull | 1 Apr 2011 05:55
Favicon
Gravatar

Re: [gsoc] Interest in BGL v2?

Thanks for the overview of changes, this is helpful and reassuring.

On Mar 31, 2011, at 6:23 PM, Andrew Sutton wrote:

>> It sounds to me like you are going to end up keeping the BGLv1 functional graph concepts for
compatibility, and also providing STL-style OO concepts (I prefer this aesthetic too).  I'll strive to be
compatible with both, if possible.
> 
> There are going to be some direct analogs, but they won't be the
> "same". Different names, (hopefully) clarified semantics, etc. For
> example, vertex_descriptor and edge_descriptor simply become vertex
> and edge and are required to be convertible to bool (so you can test
> to see if they're valid or not).

Sounds reasonable. 

> The edge function is replaced by
> get_edge, with adjacency matrices (eventually) supporting m(u, v).

Not sure what you mean here - just a rename?

> AdjacencyGraph is probably going to go away since adjacency is just an
> abstraction over incidence.

I still have to look up the difference between adjacency list and incidence list, every time; not sure why
those always sound like the same thing.  

But you're talking about AdjacencyGraph - yeah, I never saw the point of iterating over adjacent vertices
instead of the edges that lead there.

(Continue reading)

Ilya Sokolov | 1 Apr 2011 07:07
Picon

Re: [submission] STL-compliant containers with copy-on-write

On Fri, 01 Apr 2011 03:07:23 +0600, Jeremy Maitin-Shepard  
<jeremy <at> jeremyms.com> wrote:

> On 03/31/2011 01:48 PM, Alexandr Sterligov wrote:
>> Yes, sorry... I will be more careful with calling anything  
>> STL-compliant. It
>> is only STL-like.
>
> It seems that using a generic COW wrapper might be more suitable.  
> Internally it would maintain a pointer to a reference-counted instance  
> of the base type.  It would provide a method for getting a const  
> reference to the type (e.g. get(), operator*() and operator->()), and  
> also a method for obtaining a non-const reference to a unique copy of  
> the type (e.g. get_unique()), which would take care of copying if the  
> reference count is greater than 1.
>
> I believe this interface is better than a specialized type that tries to  
> mimic the interface of a particular container because generally if there  
> is a need to mutate the type, it will be done by a series of possibly  
> many mutating operations on the type/iterations, and it is inefficient  
> to check if there is a need to copy e.g. on each iterator dereference or  
> on each invocation of operator[].
>
> It also avoids the need to create the specialized types in the first  
> place; a single quite simple wrapper type will solve the problem for all  
> types.

See http://stlab.adobe.com/classadobe_1_1version__1_1_1copy__on__write.html

_______________________________________________
(Continue reading)

Michael Caisse | 1 Apr 2011 07:15

Re: Boost.Log status

On 3/31/2011 11:15 AM, Andrey Semashev wrote:
> On 03/31/2011 09:29 AM, Michael Caisse wrote:
>> Does it now work with filesystem V3 ?
>>
>> I'm currently building boost trunk using only V2 for Boost.Log support.
>
> Yes, the support for Boost.Filesystem v3 is in trunk now.
> _______________________________________________

Wonderful. Thank you Andrey.

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

Vladimir Prus | 1 Apr 2011 08:10

Re: Boost.Log status

Andrey Semashev wrote:

> On 04/01/2011 01:42 AM, Vladimir Prus wrote:
>>
>> What I meant -- do you really want to work against Phoenix V3, which is bleeding
>> edge and might not have yet be fully ready?
> 
> Are there other options? As I said in another reply, porting to Phoenix
> v2 is not very productive, especially when v3 is in SVN already. Not to
> do anything and wait until v3 gets more stable and mature? It might be
> ok, but I'd like to make all interface breaking changes before Boost.Log
> v2 is released and I don't want to delay the release that long.

I honestly have no idea whether using V2 now and porting to V3 later
will be more effort or less than using V3 right away. Hopefully, somebody
more competent can comment on this -- if not, you get to pick ;-)
--

-- 
Vladimir Prus
Mentor Graphics
+7 (812) 677-68-40

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


Gmane