Alexander Dong Back Kim | 1 Sep 05:15 2008
Picon

[boost 1.35][thread] Compile error with GCC 3.2

Dear members,

I wrote an application using boost thread. It compiled well with GCC 3.4 but
not with 3.2. I'm using Boost version 1.35.

When I compile the application it shows the following error messages...

/usr/local/include/boost-1_35/boost/config/requires_threads.hpp:47:5: #error
"Compiler threading support is not turned on. Please set the correct command
line options for threading: -pthread (Linux), -pt
hreads (Solaris) or -mthreads (Mingw32)"
/usr/local/include/boost-1_35/boost/thread/detail/platform.hpp:67:9: #error
"Sorry, no boost threads are available for this platform."
/usr/local/include/boost-1_35/boost/thread/thread.hpp:19:2: #error "Boost
threads unavailable on this platform"
/usr/local/include/boost-1_35/boost/thread/condition_variable.hpp:18:2:
#error "Boost threads unavailable on this platform"
/usr/local/include/boost-1_35/boost/thread/condition.hpp:13: syntax error
   before `;' token
/usr/local/include/boost-1_35/boost/thread/mutex.hpp:18:2: #error "Boost
threads unavailable on this platform"
/usr/local/include/boost-1_35/boost/thread/once.hpp:18:2: #error "Boost
threads unavailable on this platform"
/usr/local/include/boost-1_35/boost/thread/once.hpp:23: type specifier
omitted
   for parameter `once_flag'
/usr/local/include/boost-1_35/boost/thread/once.hpp:23: syntax error before
`&'
   token
/usr/local/include/boost-1_35/boost/thread/once.hpp: In function `void
(Continue reading)

David Abrahams | 1 Sep 05:24 2008
Picon
Picon

Re: lifetime of ranges vs. iterators


on Sun Aug 31 2008, Arno Schödl <aschoedl-AT-think-cell.com> wrote:

>> > How is the separation of common_data and unique_data different from a
> separation
>> > of ranges and iterators? If iterators of ranges can rely on their range to
>> > exist, this is where common data like functors, end iterators etc. can be
>> > stored.
>
>> Naturally the point is to store the common data once when you need to
>> store more than one iterator to the same sequence -- in a range, for
>> example.
>
>> If you're asking why I bother reconstituting the whole iterator out of
>> its parts, instead of simply referring to the common_data stored in the
>> range: an adapted iterator is a useful concept regardless of whether
>> anyone is using a range abstraction.
>
> You could provide an adapted_iterator and also an adapted_range. 

My point is that the adapted_range would then have semantically
equivalent iterators with a different representation (and an extra
indirection), which seems like a waste.

> If we subscribe to the rule that ranges must stay valid for their
> iterators to be valid,

I don't.  I do subscribe to the rule that generic code cannot afford to
destroy an arbitrary range while its iterators are still in use.

(Continue reading)

Jaakko Järvi | 1 Sep 07:19 2008
Picon

[review] Dataflow Review starts today, September 1st

The review of Stjepan Rajko's Dataflow library starts today, September 1st, 
and will run until September 10th.

---------------------------------------------------------
Description of the library:

Dataflow is a generic library for dataflow  programming. Dataflow
programs can typically be expressed as a graph in which vertices
represent components that process data, and edges represent the flow
of data between the components. As such, dataflow programs can be
easily reconfigured by changing the components and/or the connections.

This review focuses on the Dataflow.Signals layer of the library. For
its data transport mechanism, Dataflow.Signals uses Boost.Signals
which can be used to make lasting dataflow connections based on
function calls. Dataflow.Signals provides the following to facilitate
signals-based dataflow networks:

* A number of useful general-purpose components, and building blocks
  for implementing new components.
* Various free functions and operators for connecting and using components.

The library documentation provides some concrete examples of how
Dataflow.Signals layer can be used. Some examples are:

* Implementing distributed dataflow applications using
  Dataflow.Signals and Boost.Asio
* An image processing network using Dataflow.Signals and Boost.GIL
* A GUI dataflow editor (located in the Dataflow.Blueprint documentation)

(Continue reading)

Igor Nazarenko | 1 Sep 07:59 2008
Picon

[log] filtering performance

It seems that the library does quite a bit of work before filtering
away a record, unless the logging is turned off entirely. There's at
least two mutex locks, some memory allocation, etc. Callgrind claims
~2500 instructions when the record is thrown away by the global
severity filter. Shortened callgrind output is in-line below; full
output and the test program attached. Compiled by gcc 4.2.3 using
boost.build variant=release threading=multi.

 7      BOOST_LOG_SEV(slg, normal) << "A normal severity message, will
not pass to the output (global filter)";
99,557  => bool basic_severity_logger::open_record() (1x)
 7      BOOST_LOG_SEV(slg, normal) << "A normal severity message, will
not pass to the output (global filter)";
2,530   => bool basic_severity_logger::open_record() (1x)
 7      BOOST_LOG_SEV(slg, normal) << "A normal severity message, will
not pass to the output (global filter)";
2,530   => bool basic_severity_logger::open_record() (1x)

 7      BOOST_LOG_SEV(slg, warning) << "An warning severity message,
will not pass to the output (sink filter)";
5,212   => bool basic_severity_logger::open_record() (1x)
 7      BOOST_LOG_SEV(slg, warning) << "An warning severity message,
will not pass to the output (sink filter)";
3,904   => bool basic_severity_logger::open_record() (1x)
 7      BOOST_LOG_SEV(slg, warning) << "An warning severity message,
will not pass to the output (sink filter)";
3,904   => bool basic_severity_logger::open_record() (1x)
 .
10      BOOST_LOG_SEV(slg, error) << "An error severity message, will
be printed";
(Continue reading)

Alexander Dong Back Kim | 1 Sep 08:32 2008
Picon

[boost 1.35] Linking problem with GCC 3.2

Hi members,

I'm using both GCC 3.2 and 3.4 in different linux machines. The application
uses a number of BOOST libraries such as program_options, iosterams, thread
and system. When I compiled the application with GCC 3.4 (of course linking
correct library files like "libboost_program_options-gcc34-mt"), it compiled
well and works well. I did "ldd" to see what library files are linked... and
it says...

    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0048a000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x005e8000)
    libm.so.6 => /lib/tls/libm.so.6 (0x00372000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00555000)
    libc.so.6 => /lib/tls/libc.so.6 (0x0023e000)
    /lib/ld-linux.so.2 (0x00224000)

Now, I compiled the same application and link different gcc version of boost
library files because it uses GCC 3.2 instead. I compiled it and there was
no compile-time error but it cannot be executed because it can't find the
target library files. I did "ldd" for the application and now it has all the
boost library files...

    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0038d000)
    libboost_system-gcc32-mt-1_35.so.1.35.0 => not found
    libboost_thread-gcc32-mt-1_35.so.1.35.0 => not found
    libboost_serialization-gcc32-mt-1_35.so.1.35.0 => not found
    libboost_program_options-gcc32-mt-1_35.so.1.35.0 => not found
    libboost_iostreams-gcc32-mt-1_35.so.1.35.0 => not found
    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00b8e000)
    libm.so.6 => /lib/tls/libm.so.6 (0x007a6000)
(Continue reading)

vicente.botet | 1 Sep 08:33 2008
Picon

Re: [exception][policy]

----- Original Message ----- 
From: "Emil Dotchevski" <emil <at> revergestudios.com>
To: <boost <at> lists.boost.org>
Sent: Sunday, August 31, 2008 8:59 PM
Subject: Re: [boost] [exception][policy]

>
> On Sun, Aug 31, 2008 at 8:54 AM, vicente.botet <vicente.botet <at> wanadoo.fr> 
> wrote:
>>> On Sat, Aug 30, 2008 at 7:21 PM, vicente.botet 
>>> <vicente.botet <at> wanadoo.fr>
>>> wrote:
>>>>>
>>>>> What use case do you have in mind?
>>>>
>>>> Sorry, but I dont understand your question. What use case do I have in
>>>> mind
>>>> for what? Maybe you can question is related to:"What is worst is that 
>>>> the
>>>> final user can not do anything for the exceptions thrown by 3pp 
>>>> libraries
>>>> that do not use boost::enable_current_exception or
>>>> boost::throw_exception."
>>>
>>> I am trying to be as objective as possible in answering your previous
>>> questions. For that, I need to understand what is the use case you
>>> have in mind. I understand that it involves a 3rd party library
>>> throwing an exception, but more details please:
>>
>> My own application request a thread pool library to execute a function F
(Continue reading)

Vladimir Prus | 1 Sep 08:46 2008

Re: [boost 1.35] Linking problem with GCC 3.2

Alexander Dong Back Kim wrote:

> Hi members,
> 
> I'm using both GCC 3.2 and 3.4 in different linux machines. The application
> uses a number of BOOST libraries such as program_options, iosterams, thread
> and system. When I compiled the application with GCC 3.4 (of course linking
> correct library files like "libboost_program_options-gcc34-mt"), it compiled
> well and works well. I did "ldd" to see what library files are linked... and
> it says...
> 
>     libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0048a000)
>     libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x005e8000)
>     libm.so.6 => /lib/tls/libm.so.6 (0x00372000)
>     libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00555000)
>     libc.so.6 => /lib/tls/libc.so.6 (0x0023e000)
>     /lib/ld-linux.so.2 (0x00224000)

To be pedantic, the above output has no indication that boost libraries are found,
it only says that the system libraries are found, which is hardly a surprise.

> Now, I compiled the same application and link different gcc version of boost
> library files because it uses GCC 3.2 instead. I compiled it and there was
> no compile-time error but it cannot be executed because it can't find the
> target library files. I did "ldd" for the application and now it has all the
> boost library files...
> 
>     libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0038d000)
>     libboost_system-gcc32-mt-1_35.so.1.35.0 => not found
>     libboost_thread-gcc32-mt-1_35.so.1.35.0 => not found
(Continue reading)

Christian Larsen | 1 Sep 08:50 2008
Picon

Re: [boost 1.35] Linking problem with GCC 3.2

Alexander Dong Back Kim skrev:
> Now, I compiled the same application and link different gcc version of boost
> library files because it uses GCC 3.2 instead. I compiled it and there was
> no compile-time error but it cannot be executed because it can't find the
> target library files. I did "ldd" for the application and now it has all the
> boost library files...
> 
>     libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0038d000)
>     libboost_system-gcc32-mt-1_35.so.1.35.0 => not found
>     libboost_thread-gcc32-mt-1_35.so.1.35.0 => not found
>     libboost_serialization-gcc32-mt-1_35.so.1.35.0 => not found
>     libboost_program_options-gcc32-mt-1_35.so.1.35.0 => not found
>     libboost_iostreams-gcc32-mt-1_35.so.1.35.0 => not found
>     libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00b8e000)
>     libm.so.6 => /lib/tls/libm.so.6 (0x007a6000)
>     libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00179000)
>     libc.so.6 => /lib/tls/libc.so.6 (0x00182000)
>     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00d66000)
> 

Maybe this can help: http://prefetch.net/articles/linkers.badldlibrary.html

Best regards,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Arno Schödl | 1 Sep 08:57 2008

Re: lifetime of ranges vs. iterators

> > If we subscribe to the rule that ranges must stay valid for their
> > iterators to be valid,

> I don't.  I do subscribe to the rule that generic code cannot afford to
> destroy an arbitrary range while its iterators are still in use.

Isn't that what I said? There may be iterators that work without their ranges, but in general they don't.

> > the adapted_range::iterator can use the common data stored in the
> > range, while the adapted_iterator stores the common data itself. Both
> > could even be derived from the same source code. 

> Yeah, that's still a lot of coding effort.

I think you could write it generically, a la iterator_facade/adaptor, so it is a one-time fixed cost.

> > Do you then still need a factored iterator?

> You need to be able to take two adapted iterators and turn them into a
> range.  Do you want that range to contain redundant data?  I don't.

> > Or do you want to avoid people having to use the range abstraction? 

> I certainly don't want to force it on them.

Ok, now I understand. The debate is about primacy of ranges or iterators. You propose that iterators stay
the primary vehicle and to convert them to/from ranges by stripping the common information. But that
would mean that there is no "lean" iterator, all iterators would contain the redundant information. 

When stacking N difference_ranges, the size difference between "fat" and "lean" iterators is 2^N. Thus in
(Continue reading)

Dean Michael Berris | 1 Sep 09:25 2008
Picon

Boost 1.36.0 release notes missing Circular Buffer changes

Hi,

I took a look at the code in trunk and in 1.36.0, and I notice the
release notes don't mention the change in behavior of
Boost.Circular_Buffer WRT the default constructor.

Should we add:

Circular Buffer:
* default constructor now doesn't allocate memory, and sets the
capacity of the buffer to 0

To the 1.36 release notes?

--

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Gmane