Levent Yilmaz | 1 Oct 2006 01:13
Picon
Favicon

lambda boost::array operator[] error

Hi All,

Please take a look these two similar set of statements. One uses vector, 
the other boost::array :

/**/

using std::vector;
using boost::array;
using std::for_each;
using boost::lambda::_1;

// This one compiles:
typedef vector<int> Vector;
Vector v(2);
vector<Vector> vv(5,v);
for_each( vv.begin(), vv.end(), (_1[0]=10, _1[1]=9) );

// This one doesn't:
typedef array<int,2> Array;
vector<Array> va(5);
for_each( va.begin(), va.end(), (_1[0]=10, _1[1]=9) );

/**/

With MSVC 7.1, I get:
=====
d:\boost\include\boost-1_33_1\boost\lambda\detail\operator_lambda_func_base.hpp(237): 
  error C2679: binary '=' : no operator found which takes a right-hand 
operand of type 'const boost::tuples::cons<HT,TT>::stored_head_type' (or 
(Continue reading)

Jaakko Järvi | 1 Oct 2006 01:57
Picon
Favicon

Re: lambda boost::array operator[] error

The return type deduction mechanism of boost lambda does not
recognize boost::array, and does not know what the return type
of the subscription mechanism is:

Try:

ret<int&>(_1[0]) = 10, ret<int&>(_1[1]=9 )

(I didn't, but hopefully you get the idea).

   Jaakko

On Sep 30, 2006, at 6:13 PM, Levent Yilmaz wrote:

> Hi All,
>
>
> Please take a look these two similar set of statements. One uses  
> vector,
> the other boost::array :
>
> /**/
>
> using std::vector;
> using boost::array;
> using std::for_each;
> using boost::lambda::_1;
>
> // This one compiles:
> typedef vector<int> Vector;
(Continue reading)

Joel de Guzman | 1 Oct 2006 13:41
Picon
Favicon

[spirit] 1.8.4 release candidate + roadmap

Hi Y'all

Historically, Spirit had its own release cycle. Spirit 1.8.4 will
be released in the next few days. You can get a beta snapshot
here:

http://spirit.sourceforge.net/dl_more/spirit-1.8.4.beta1.zip
http://spirit.sourceforge.net/dl_more/spirit-1.8.4.beta1.tar.gz

These betas are provided to make sure that all is ok. We
appreciate feedback and reporting of problems encountered.
We'd like to make sure that the packages are in perfect shape
before we do the final release.

Roadmap:

* Spirit 1.8.4 release

* Soon after the release of Spirit 1.8.4, Spirit 1.8.5
   will follow. Spirit 1.8.5 is the bridge to Spirit-2.
   Spirit 1.8.5 integrates Fusion2 and Phoenix2. It is already
   in the final stages of development. Spirit 1.8.5 is not 100%
   backward compatible to Spirit 1.8.4. We shall provide some
   documents to make the transition as smooth as possible. The
   difference is minimal. Hopefully, 1.8.5 (and subsequent releases)
   will ease the transition to 2.0.

* Development of Spirit-2 shall proceed parallel to Spirit 1.8.5++.

Comments, feedback welcome.
(Continue reading)

David Abrahams | 1 Oct 2006 14:21
Picon
Picon
Favicon
Gravatar

Re: [BGL] Boost poor performance (against LEDA)

"Leandro Melo" <ltcmelo <at> gmail.com> writes:

> Hi.
> First of all, I'd like to apologize because I've not carried out my
> tests correctly.
>
> I had some optimization configurations not set correctly. So, this
> invalidates all tests I made. So, please ignore everything I said
> about my results.
>
> Anyway, if anyone has a comment about the topic it's still welcome.
> I'm gonna have to redo all tests. And I'm pretty sure that I'm gonna
> have better results for Boost. But I still have some surprises, I'll
> come back to this subject later on the list.
>
> Thank you again and sorry for the inconvinience.

You should probably know that although graph construction should be
fast with Boost, most of the attention to optimization went into the
algorithms, and on making them as fast as possible on a wide variety
of graph structures.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Douglas Gregor | 1 Oct 2006 15:43
Picon
Gravatar

Re: [function] How do you bind two boost::function objects together?


On Sep 30, 2006, at 1:01 PM, Jason House wrote:

> I'm trying to convert the input argument to a function object using a
> small helper function object.  The code below looks relatively simple,
> but it doesn't seem to compile.  Any ideas what could be wrong?
>
> template<typename inputType, typename outputType>
> boost::function<outputType (int)>
> convert(boost::function<outputType (inputType)> &object_to_convert){
>    boost::function<intputType (int)> input_converter(...);
>
>    // The following fails to compile
>    boost::function<outputType (int)> converted_function
>      (boost::lambda::bind(object_to_convert, input_converter));

The bind expression is going to result in a function object that  
calls object_to_convert(input_converter). What you really want is a  
function object that takes one parameter ("arg1") and call  
object_to_object with the result of input_converter(arg1). To do so,  
you will need a nested bind expression that will look something like  
this:

   boost::function<outputType (int)> converted_function
    (boost::lambda::bind(object_to_convert, boost::lambda::bind 
(input_converter, arg1)));

	Cheers,
	Doug
(Continue reading)

Jens Müller | 1 Oct 2006 16:18
Picon
Favicon

[BGL] Reading GraphML

I tried to read a GraphML file using Douglas' code and the following:

std::auto_ptr<boost::dynamic_property_map>
string2string_gen(const std::string& name,
                  const boost::any&,
                  const boost::any&) {
  typedef std::map<std::string,std::string> map_t;
  typedef
    boost::associative_property_map< std::map<std::string, std::string> >
    property_t;

  map_t* mymap = new map_t(); // hint: leaky memory here!

  property_t property_map(*mymap);

  std::auto_ptr<boost::dynamic_property_map> pm(
    new
boost::detail::dynamic_property_map_adaptor<property_t>(property_map));

  return pm;
}

int main(int argc, char* argv[]){
        // create a typedef for the Graph type
        using namespace boost;

        typedef boost::adjacency_list<vecS, vecS, directedS> Graph;
        Graph g;

        std::ifstream input(argv[1]);
(Continue reading)

Jason House | 1 Oct 2006 05:18
Picon

Re: [function] How do you bind two boost::function objects together?

Jason House wrote:
> I'm trying to convert the input argument to a function object using a 
> small helper function object.  The code below looks relatively simple, 
> but it doesn't seem to compile.  Any ideas what could be wrong?
> 
> template<typename inputType, typename outputType>
> boost::function<outputType (int)>
> convert(boost::function<outputType (inputType)> &object_to_convert){
>    boost::function<intputType (int)> input_converter(...);
> 
>    // The following fails to compile
>    boost::function<outputType (int)> converted_function
>      (boost::lambda::bind(object_to_convert, input_converter));
> 
>    return converted_function
> }

I realize the use of local variables in the object creation is a bad 
idea, but that doesn't affect the compilation.

While I get buried in "instantiated from here" messages, here's the 
actual error message (altered to match the example)

/usr/local/include/boost/lambda/detail/function_adaptors.hpp:41:
error: no match for call to
'(const boost::function<outputType()(inputType),std::allocator<void> >)
  (const boost::function<outputType()(int),     std::allocator<void> >&)'
Arkadiy Vertleyb | 1 Oct 2006 18:13
Picon
Favicon

Re: [spirit] 1.8.4 release candidate + roadmap

"Joel de Guzman" wrote

> Historically, Spirit had its own release cycle. Spirit 1.8.4 will
> be released in the next few days. You can get a beta snapshot
> here:
>
> http://spirit.sourceforge.net/dl_more/spirit-1.8.4.beta1.zip
> http://spirit.sourceforge.net/dl_more/spirit-1.8.4.beta1.tar.gz
>
> These betas are provided to make sure that all is ok. We
> appreciate feedback and reporting of problems encountered.
> We'd like to make sure that the packages are in perfect shape
> before we do the final release.
>
> Roadmap:
>
> * Spirit 1.8.4 release
>
> * Soon after the release of Spirit 1.8.4, Spirit 1.8.5
>    will follow. Spirit 1.8.5 is the bridge to Spirit-2.
>    Spirit 1.8.5 integrates Fusion2 and Phoenix2. It is already
>    in the final stages of development. Spirit 1.8.5 is not 100%
>    backward compatible to Spirit 1.8.4. We shall provide some
>    documents to make the transition as smooth as possible. The
>    difference is minimal. Hopefully, 1.8.5 (and subsequent releases)
>    will ease the transition to 2.0.
>
> * Development of Spirit-2 shall proceed parallel to Spirit 1.8.5++.

Just a few questions to clear some confusion:
(Continue reading)

Jeff Garland | 1 Oct 2006 18:36

Re: date_time: convert std::time_t to printable date in local time

Andreas Ntaflos wrote:
> 
> Thank you both for your replies!
> 
> Constructing a posix_time_zone (CET with DST), a ptime from the 
> timestamp (time_t) using from_time_t() and then creating a 
> local_date_time object from the constructed posix_time_zone and the 
> ptime did exactly what I initially wanted.
> 
> I also considered the method shown in the Local to UTC Conversion 
> example which uses the c_local_adjustor, but it's apparently very 
> undocumented, which is probably why I didn't find it when searching 
> through the docs. This method seems to have the advantage that I do not 
> need to hard code the time zone into the program or read it from an 
> external database file. 

Yes, but it has other limitations.

> BTW: Why would it be dangerous to rely on the machine's time zone 
> settings? It seems to me that this would be a more robust and 
> convenient way of applying time zone adjustments. 

It's *dangerous* because it's basically impossible for a program to tell if 
the settings are correct.  On some OS's, average users can alter these 
settings and so your program may fail in unexpected ways if you expect the 
settings to be correct.

BTW, the various 'clock' classes already retrieve dates and times using the 
machine tz settings.  The real issue here is that there is no portable way to 
retrieve a timezone from the machine configuration that has all of the 
(Continue reading)

Jeff Garland | 1 Oct 2006 18:42

Re: [date_time] Stricter stream input validation

Johan Nilsson wrote:
> Jeff Garland wrote:
>> Johan Nilsson wrote:

>> Maybe something like this?
>>
>> -- Output --
>>
>> 23:59:59
>> Hour out of range: 0 to 23
>> Minute out of range: 0 to 59
>> Second out of range: 0 to 59
> 
> Perhaps:
> 
> "<unit> out of range (valid: [<min>,<max>])"
> 
> would be more descriptive, or even something like:
> 
> "<unit> out of range (is: <actual>, valid: [<min>, <max>])"

I know...that's an enhancement that needs to go in, but it isn't there right 
now...

>> -- Code --
>
 > <snip details...>
> 
> [snip rest of example implementation]
> 
(Continue reading)


Gmane