Re: [convert] Now with Boost.Parameter interface.

on Mon Jun 29 2009, "Stewart, Robert" <Robert.Stewart-AT-sig.com> wrote:

>> 3. I only managed to figure out how to supply only one
>> Boost.Parameter at a time like
>>
>>    int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>>
>> I understand how to achieve
>>
>>    int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true));
>>
>> (with double quotes) but do not want to go there as it looks somewhat
>> unorthodox. I cannot figure out how to achieve the following
>
> The doubled parentheses are, indeed, rare outside Boost.Preprocessor type code.
>
>>    int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true);
>
> That is certainly preferable syntax.

It's not hard to achieve, but I don't think you'd like the effect: 

   convert<int>::from(str, 0)

would have to return a function object rather than an int.  What's wrong
with

  int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

Re: [gil] gcc 4.4.0 namespace fix

on Thu Jun 25 2009, Philipp Schwaha <philipp-AT-gsse.at> wrote:

> Hi!
>
> I hope this is an appropriate place (and time ;) ) for this.

Hi Philipp,

The best place for such things is in Trac tickets
(http://svn.boost.org).  Patches posted to mailing lists tend to get
dropped if the maintainer isn't watching when you post.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

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

Re: Universal user interface based only on C++ standard libraries

on Thu Jun 25 2009, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:

> Jonathan Enders wrote:
>> One feature I am always missing when programming in a non-interpreted language like
>> C is the ability to interactively execute the program without writing an entire
>> mechanism for that. This "interpreted when typed"-feature proves itself very useful
>> in python for instance.
>
> You mean something like geordi?
> http://www.xs4all.nl/~weegen/eelis/geordi/

_That_ is cool.  On which IRC channels does geordi lurk?

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

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

Re: Universal user interface based only on C++ standard libraries

2009/6/30 David Abrahams <dave <at> boostpro.com>:
>
> on Thu Jun 25 2009, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
>>
>> You mean something like geordi?
>> http://www.xs4all.nl/~weegen/eelis/geordi/
>
> _That_ is cool.  On which IRC channels does geordi lurk?
>

##iso-c++, ##c++, and #geordi on Freenode.  (Same server as #boost,
conveniently.)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Universal user interface based only on C++ standard libraries

2009/6/26 Jonathan Enders <jenders <at> stud.uni-frankfurt.de>
>
> <snip>
>
> As I don't know if any of that is of any relevance to the boost community I will leave it at that. It just seems
like a big lack to me that the boost-libraries still have no means of user interaction. If there is any
interest in the above I have a working sample which demonstrates what words can only poorly describe.
>

I think it has great relevance.  One of the founding idea's behind
boost was to make great libraries available as C++ was getting stomped
on by neat and consistent Java functionality in its libraries.   That
is, in my mind at least, part of the original guiding principle from
boost and Beman seemed to be to make C++ more useful / productive /
elegant / habitable.  Making it more interactive / script-like is an
interesting idea with all the good that comes from productivity and
quickness of idea to action versus the dangers of loose expressionism
(loose design sinks ships ).

We got an internal tool here we've been ummming and ahhhing about open
sourcing.  We call it "bofh" as it started as a "bunch of file
headers" but does cpps now too to keep is compiling fast.  The idea
was that we do a lot of computation in R because it is convenient and
but some of our data sets are many terabytes and, thus, as some of our
stats in R were tediously slow, we wanted to make C++, our favourite
religion, like a scripting language.  So we did a python shell that
feels like R but compiles with gcc/ccache/distcc in the back ground,
integrates gnuplot.  We've been striving to keep the hit enter,
compile and link cycle, do useful stuff _and_ put it on the screen, to
less than a second to keep it comfortable. Write C++ on the command

Re: Universal user interface based only on C++ standard libraries

Scott McMurray wrote:
> 2009/6/30 David Abrahams <dave <at> boostpro.com>:
>> on Thu Jun 25 2009, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
>>> You mean something like geordi?
>>> http://www.xs4all.nl/~weegen/eelis/geordi/
>> _That_ is cool.  On which IRC channels does geordi lurk?
>>
> 
> ##iso-c++, ##c++, and #geordi on Freenode.  (Same server as #boost,
> conveniently.)

You might want to steer clear of #boost. Some suspicious characters in
there (just kidding but that's the kind of stuff you can look forward to.)

--

-- 
Sohail Somani
http://uint32t.blogspot.com

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

Re: [convert] Now with Boost.Parameter interface.

From: "David Abrahams" <dave <at> boostpro.com>
> ...  What's wrong with
>
>  int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

I personally to not feel there is anything wrong per se with the above. The 
reason I did not pursue it was that it introduces a limit on the number of 
the parameters and I did not see it offering any major advantages to balance 
that shortcoming over the supported

int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);

On the other hand the supported interface seems to scale considerably better 
and is no longer to type:

int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

V. 

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

Re: [serialization] Memoryleak invoid_caster::recursive_register

Thanks! I only trusted the memory leak report from the program :(
The memory detection is done when the destructor on a static class i 
called, but it is not possible to decide which destructor is called 
first. So I wonder if it is any function I could call to manually free 
the memory. Then I could call this function in debug build before my 
code check for memory leaks.

- Runar

Robert Ramey wrote:
> This create objects which register themselves in a global table.  The table 
> and objects persist until the execution module ends.  Some methods of 
> checking for memory leaks might check before the table
> and it's members are destroyed so it might look like they are leaks - but 
> they're not.  This can be seen
> by setting a debugger break point on the destructor of voice_cast_shortcut.
>
> Robert Ramey
>
> Runar Undheim wrote:
>   
>> // implementation of void caster base class
>> BOOST_SERIALIZATION_DECL(void)
>> void_caster::recursive_register(bool includes_virtual_base) const {
>>    void_cast_detail::set_type & s
>>        =
>> void_cast_detail::void_caster_registry::get_mutable_instance();
>>    s.insert(this);
>>
>>    // generate all implied void_casts.

boost::interprocess - lnk2005 error due to compiler/linker bug in msvc8

when using boost::interprocess under win32, i ran into the following  
problem:
in boost/interprocess/detail/win32_api.hpp several static inline  
functions have a function local class
for releasing resources, like 'unlink_file', which defines 2 classes:
handle_closer, and auto_ptr

due to a compiler bug, as discussed here: http://www.eggheadcafe.com/conversation.aspx?messageid=32706692&threadid=32706692

you get a LNK2005 error  <symbol> already defined in <object>

when using boost::interprocess from multiple .cpp files

a solution is to use boost::shared_ptr instead of local classes in  
win32_api.hpp, like this:

   boost::shared_ptr<void> hiPSAPI =  
boost::shared_ptr<void>(load_library("PSAPI.DLL"), free_library);

attached is the complete patch

willem

_______________________________________________

Re: [config] problem with sys/select.h on Linux/Unix

>> It doesn't: at least not deliberately, my guess it's included by 
>> something
>> else like <unistd.h> which we really do need.
>>
>
> Thanks for the reply, but unistd.h is not the culprit either directly or
> indirectly. Two possible candidates are sys/time.h and sys/types.h. Are
> either of these used directly or indirectly in boost config?

Nope, just unistd.h limits.h and stdint.h as far as I can tell.

> Other boost libs document their dependencies. It would be useful if
> boost config documented the headers it includes, particularly as the C
> headers pollute the global namespace.
>
> Do you have any thoughts on a work around? It is awkward trying to write
> a library intended for submission to boost and not being able to use
> either config or the unit test framework.

OK here's the thing, it looks to me as though that header is very likely to 
be included even if it's by the users own code based on what you're saying?

If so, then it's going to be important for you code and these system headers 
to happily live together, can you give an indication of what you're trying 
to do?

Cheers, John.

PS select.h appear to be pulled in via <cstddef> in 
select_stdlib_config.hpp.