headers
Joel de Guzman | 1 Sep 01:18
Picon
Favicon

Re: [Fusion] Heads up

David Abrahams wrote:
> Joel de Guzman <joel <at> boost-consulting.com> writes:
> 
>> There's also an interesting
>> use-case that became apparent recently: making arbitrary structs/classes
>> conforming sequences easily-- as easy as providing a single function.
>> Pardon me if this is rather sketchy at this point, but imagine
>> being able to write:
>>
>> Our user defined struct:
>>
>>      struct point { float x, float y; };
>>
>> Customization:
>>
>>      fusion::map<keys::x_, keys::y_, float&, float&>
>>      as_fusion_sequence(point& p)
>>      {
>>          return fusion::map_tie<keys::x_, keys::y_>(p.x, p.y);
>>      }
>>
>> Use:
>>
>>      point p = { 123.456, 789.012 };
>>      fusion::for_each(p, std::cout << _1 << std::endl);
> 
> That's nice, but I don't think it's really the same thing.  Doesn't it
> incur an extra level of indirection?

Not the same as what? Sorry, I think I missed something in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Walter Landry | 1 Sep 01:57
Favicon

More functions for Filesystem

Greetings,

I have recently upgraded from 1.32 to the current prerelease, and it
feels like filesystem is missing a few convenience functions.

  1) readlink: There is a way to create a symlink, but then no way to
     query it later.

  2) nlink: Similarly, we can create a hard link, but can not query
     its link count.

  3) copy_symlink: Note that this requires readlink in order to
     function.

  4) copy_directory: create_directory creates directories with the
     mode S_IRWXU|S_IRWXG|S_IRWXO.  That seems like a security hole
     waiting to happen.  This would at least provide a way of
     inheriting access properties.

  5) copy(): This would check what the first argument is and invoke
     the appropriate function (copy_file, copy_symlink,
     copy_directory).

Except for nlink, I have already implemented all of these functions
because I needed them.  Is there any interest in getting these
functions into the filesystem library?

Cheers,
Walter Landry
wlandry <at> ucsd.edu
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gregory Dai | 1 Sep 03:24
Picon

Re: [lexical_cast] optimization commited to HEAD

On 8/31/06, John Maddock <john <at> johnmaddock.co.uk> wrote:
>
> Gregory Dai wrote:
> > Perhaps we were not on the same page. What I meant was as long as
> > std::string is used as either the source or target of a lexical_cast,
> > thread safety may not be guaranteed (due to lack of a guarantee by
> > std::string). Though weird/bad things happen more frequently under
> > heavy load and/or on multiprocessor (hyperthreading included)
> > machines.
>
> Right but what do you expect us to do about components like std::string
> that
> are beyond our control?

No, I certainly was not blaming the boost community for some shortcomings of
std::string.

In any case all the implementations I'm aware of are minimally thread safe
> these days, if that's not the case I'd certainly like to hear about
> it.  BTW
> implementations that used copy-on-write in the early days almost all
> (all?)
> switched away from that precisely because of threading issues.
>
> John.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory Dai | 1 Sep 03:33
Picon

Re: [lexical_cast] optimization commited to HEAD

On 8/31/06, John Maddock <john <at> johnmaddock.co.uk> wrote:
>
> Caleb Epstein wrote:
> > On 8/31/06, John Maddock <john <at> johnmaddock.co.uk> wrote:
> >
> >> In any case all the implementations I'm aware of are minimally
> >> thread safe these days, if that's not the case I'd certainly like to
> >> hear about it.  BTW implementations that used copy-on-write in the
> >> early days almost all (all?) switched away from that precisely
> >> because of threading issues.
> >
> > Even the latest libstdc++ (GNU's Standard C++ library) uses a
> > refcounted std::string.
>
> Darn, I hadn't realised that :-(
>
> > One needs to be careful when sharing strings across thread boundaries.
> > See these bug reports for a detailed discussion:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
>
> Very interesting stuff!
>
> I'm not sure that it's relevent in this case though: if you're
> lexical_cast'ing *to* a string then these issues shouldn't arise, whether
> there are other threads getting involved or not.  If you're casting *from*
> a
> string, then it appears that you need a mutex if you know the string is
> likely to be visible to other threads, even if all accesses to it are
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gregory Dai | 1 Sep 04:38
Picon

Re: Exception lib proposal update: what()

On 8/21/06, Emil Dotchevski <emildotchevski <at> hotmail.com> wrote:
>
> Hello,
>
> I just finished an update to the exception library I am planning to
> propose
> for addition to Boost. I appreciate all feedback, including
> incompatibility
> reports with various compilers (I believe the implementation to be
> standard-conforming, but I have only tested with msvc 7.1/8.0 and gcc
> 3.4.4).
>
> As usual, the latest documentation is here:
>
> http://www.revergestudios.com/boost-exception/boost-exception.htm
>
> Here is a zip file with the source code, complete with jamfiles and tests:
>
> http://www.revergestudios.com/boost-exception/boost-exception.zip
>
> Here's what's new in this update: class boost::exception now defines
> what()
> function, similarly to std::exception. It automatically formats a message
> which combines all exception info stored by operator<< in the
> boost::exception object. The message is not user-friendly; it is designed
> for dumping in log files and for other debugging systems.
>
> For what() to work, the system needs to be able to convert the exception
> info values stored in a boost::exception to string. Because this is not a
> critical feature, I thought it wouldn't be a good idea to require the user
(Continue reading)

Permalink | Reply | 2 comments |
headers
Larry Evans | 1 Sep 05:31

Re: [preprocessor] undef file iteration includeguard?

On 08/31/2006 04:05 PM, Paul Mensonides wrote:
[snip] 

> Actually, you only need combinatorial forwarding on the function
> that takes arguments from the client.  You don't need it elsewhere
> because then you don't have temporaries.

[snip] 

>>One problem of forwarding is arity (which can be more-or-less solved
>>with code generation).  The more stubborn problem with forwarding is
>>temporaries.  They cannot be bound to a non-const reference, and the
>>template mechanism cannot deduce T as const U in a parameter of type
>>T&.  OTOH, non-temporaries don't have any problem deducing T as U or
>>const U in a parameter of type T&.  Unfortunately, the only way to
>>handle it transparently is to overload via cv-qualifier--which leads
>>the the combinatorial explosion when multiple parameters are
>>involved.

> Given the above, you could solve (i.e. avoid) the combinatorial
> problem by linearizing the input.

Paul, could explain what's meant by "linearizing the input"?  I'm
unfamiliar with that phrase :(

> If you have no temporaries, you can just use T& and T will bind
> correctly to a cv-qualified type.

> To get rid of temporaries (which can't bind to T&) you need:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andy Little | 1 Sep 10:13
Picon
Picon

Re: [linear algebra] - question to David Abrahams


"Matthias Troyer" <troyer <at> itp.phys.ethz.ch> wrote in message
news:3BF6C3DF-9F29-4CCE-BF04-D97B8CADFE83 <at> itp.phys.ethz.ch...

> Can't you just use std::complex<T> as value type in quan?

You can do:

quan::resistance<std::complex<> >:kR x;

but its preferable  to do:

quan::complex<quan::resistance::kR> x;

I tried  specialising/ overloading std::complex for quantities before but its
more work than just doing my own version, which will work with numeric types and
quantity types anyway.... and  complex<double>(1) * 2;  won't fail to compile in
my version ;-)

regards
Andy Little

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
KF | 1 Sep 10:58
Picon

Re: [linear algebra] - question to David Abrahams

Andy Little wrote:

> I tried  specialising/ overloading std::complex for quantities before [...]

Is this legal? Standard says (section 26.2, verse 2):

``The effect of instantiating the template complex for any type other 
than float, double or long double is unspecified.''

Regards,

fres
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
John Maddock | 1 Sep 11:01
Picon

Re: [lexical_cast] optimization commited to HEAD

Gregory Dai wrote:
>> Have I got that right?
>
>
> Well, not completely perhaps. E.g., at least if the target is a
> std::string of size=0, the resultant std::string may well be
> reference-counted and shared by multiple threads.

Can you explain some more?  Are you saying that if two unrelated threads 
each default construct a string (or maybe construct a zero length string?) 
then they will be entangled by reference counting?

Thanks, John. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 3 comments |
headers
David Abrahams | 1 Sep 12:39
Picon
Picon
Favicon
Gravatar

Re: [preprocessor] (Dave?) undef file iteration include guard?

"Paul Mensonides" <pmenso57 <at> comcast.net> writes:

>> [mailto:boost-bounces <at> lists.boost.org] On Behalf Of Larry Evans
>
>> > Regarding what the generated code is doing (as opposed to what the 
>> > generator code is doing), the major problem with forwarding without 
>> > language support is that it is a combinatorial problem--rather than 
>> > linear.  I.e. you really need various combinations of const and-or
>> [snip]
>> 
>> Ouch!  Do you know of anyone working on a compiler to solve 
>> this forwarding problem?
>
> I know this is one of the things being tossed around in the committee, but I
> don't know the likelihood that of acceptance or if it has already been accepted.
> Dave would know more.

It's solved by rvalue references, which, IIRC, are in a late stage of
review for inclusion into the next standard.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2027.html

> One problem of forwarding is arity (which can be more-or-less solved with code
> generation).  The more stubborn problem with forwarding is temporaries.  They
> cannot be bound to a non-const reference, and the template mechanism cannot
> deduce T as const U in a parameter of type T&.  OTOH, non-temporaries don't have
> any problem deducing T as U or const U in a parameter of type T&.
> Unfortunately, the only way to handle it transparently is to overload via
> cv-qualifier--which leads the the combinatorial explosion when multiple
> parameters are involved.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane