headers
OvermindDL1 | 1 Feb 01:50
Picon

Re: boost any questions and praise

On Sun, Jan 31, 2010 at 10:09 AM, Alan Tennant <alan2here <at> gmail.com> wrote:
> and std::vector is even more type safe, but even less useful.
>
> I think the term "type safe" having the word "safe" in it was created by
> it's supporters, it's as biased as a term as "strongly typed".
>
> If some code is getting an object then that code already knows why it is
> requesting that object and what it will do with the object, what methods it
> would make sense to call on the object, what methods might not be available
> and the such.
>
> If there were no recursive functions, or objects, no flow control like "for"
> or "while" available, nothing like a code type either that would allow you
> to abstract a loop, then your program would be guaranteed "loop safe" and
> "lockup safe".
>
> Maybe there should be a fixed number of types, like in the original C with
> no objects, then it would be totally safe.

Variant is superior to Any in a few ways:

Speed:  Variant does a switch lookup, very fast, inlined visitors.
Any requires RTTI which has a *VERY* slow lookup, plus a virtual
function call.
Memory:  Variant does not allocate memory unless your variant is
recursive, Any tends to allocate memory in general.
Permalink | Reply | 0 comments |
headers
OvermindDL1 | 1 Feb 01:53
Picon

Re: boost serialization stream error question

On Sun, Jan 31, 2010 at 10:34 AM, Robert Ramey <ramey <at> rrsd.com> wrote:
>> The problem is caused by double values less than DBL_MIN.
>> Apparently, streaming such values in causes the input stream fail_bit
>> to be set, which causes the serialization lib to throw an exception.
>
> The standard stream library writes out NaN values as text, but cannot read
> them.
>
> It shows up in various places besides the serialization library - e.g.
> lexical_cast.
>
> Work has been done on this.  I believe that there is code in vault which
> deals with this.

Why not just memcpy the double into the stream? (or bitcast it to long
long or so?)
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 4 comments |
headers
Robert Ramey | 1 Feb 02:11

Re: boost serialization stream error question

OvermindDL1 wrote:
> On Sun, Jan 31, 2010 at 10:34 AM, Robert Ramey <ramey <at> rrsd.com> wrote:
>>> The problem is caused by double values less than DBL_MIN.
>>> Apparently, streaming such values in causes the input stream
>>> fail_bit to be set, which causes the serialization lib to throw an
>>> exception.
>>
>> The standard stream library writes out NaN values as text, but
>> cannot read them.
>>
>> It shows up in various places besides the serialization library -
>> e.g. lexical_cast.
>>
>> Work has been done on this. I believe that there is code in vault
>> which deals with this.
>
> Why not just memcpy the double into the stream? (or bitcast it to long
> long or so?)

text and xml archives are meant to be portable.  This would conflict
with that requirement.  Then there is the fact that putting binary data
into the text stream might create some conflicts depending on the
characterset etc.  In general, one cannot put binary data into a text
stream and be able to count on getting it back.

So here are a couple of options in order of my personal preference.

a) Just avoid saving and restoring NaN's.  They just waste space
in the archive anyway. There a number ways to do this.
b) find the fixup for floating point stream in either the vault and/or
(Continue reading)

Permalink | Reply | 3 comments |
headers
Emil Dotchevski | 1 Feb 02:14
Picon

Re: Strange output from boost::exception diagnostic_information

On Sun, Jan 31, 2010 at 12:01 PM, Ravi <lists_ravi <at> lavabit.com> wrote:
> On Sunday 31 January 2010 13:37:08 Emil Dotchevski wrote:
>> Note that by design, the diagnostic_information message is not
>> intended to be user-friendly. However I will accept any patches that
>> improve the output from diagnostic_information, not only in terms of
>> prettifying the mangled names but also including more diagnostic
>> information, even if it is platform-specific.
>
> Is there a reason not use the following directly?
>  http://www.boost.org/doc/libs/1_41_0/boost/units/detail/utility.hpp

OK, trunk revision 59398 uses boost/units/detail/utility.hpp for
demangling type names used in diagnostic_information (except under
rtti=off).

We should probably do a mini-review and make this an official utility function.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
Permalink | Reply | 0 comments |
headers
OvermindDL1 | 1 Feb 02:39
Picon

Re: boost serialization stream error question

On Sun, Jan 31, 2010 at 6:11 PM, Robert Ramey <ramey <at> rrsd.com> wrote:
> OvermindDL1 wrote:
>> On Sun, Jan 31, 2010 at 10:34 AM, Robert Ramey <ramey <at> rrsd.com> wrote:
>>>> The problem is caused by double values less than DBL_MIN.
>>>> Apparently, streaming such values in causes the input stream
>>>> fail_bit to be set, which causes the serialization lib to throw an
>>>> exception.
>>>
>>> The standard stream library writes out NaN values as text, but
>>> cannot read them.
>>>
>>> It shows up in various places besides the serialization library -
>>> e.g. lexical_cast.
>>>
>>> Work has been done on this. I believe that there is code in vault
>>> which deals with this.
>>
>> Why not just memcpy the double into the stream? (or bitcast it to long
>> long or so?)
>
> text and xml archives are meant to be portable.  This would conflict
> with that requirement.  Then there is the fact that putting binary data
> into the text stream might create some conflicts depending on the
> characterset etc.  In general, one cannot put binary data into a text
> stream and be able to count on getting it back.
>
> So here are a couple of options in order of my personal preference.
>
> a) Just avoid saving and restoring NaN's.  They just waste space
> in the archive anyway. There a number ways to do this.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hicham Mouline | 1 Feb 06:09

Re: generate structs with all combinations of members from a given struct

----- Original Message -----
From: "Larry Evans" <cppljevans <at> suddenlink.net>
Sent: Monday, February 01, 2010 1:03 AM
Subject: Re: [Boost-users] generate structs with all combinations of members from a given struct
 
Hello,
Larry thanks for all the answers.
 
I have a little trouble following your trail of thoughts, especially step 2, but let me reread your posts a couple of times more to get it right.
 
I think your solution is rather build more solutions than required then remove those which are not a "combination" in the mathematical sense. It may cause problems when my structs have more than 15 members in which case we may be working with 15! to get back to 2^15 -1
again, let me reread your posts first.
 
In the meantime, I have written the pure runtime version of the problem which is in fact like a tree recursive descent problem.(I think), this builds and runs correctly but doesn't deal with the identical types and member names.
 
#include <iostream>
#include <list>
 
typedef std::list< std::list<size_t> > main_list_t;
 
void combinations(main_list_t& m, const size_t* arr, size_t arrsize)
{
  if (arrsize==0)
    return;
 
  if (m.empty()) {
    std::list<size_t> l;
    l.push_back( arr[0] );
    m.push_back(l);
  }
  else {
    std::list<size_t> l( m.back() );
    l.push_back( arr[0] );
    m.push_back( l );
  }
 
  combinations(m, arr+1, arrsize-1); 
}
 

int main()
{
  const size_t arr[] = { 1, 2, 3, 4, 5 };
  const size_t arrsize = sizeof(arr)/sizeof(size_t);
 
  main_list_t m[arrsize];
  for (size_t s=0; s<arrsize; ++s)
    combinations(m[s], &arr[s], arrsize-s);
 
  main_list_t mm;
  for (size_t s=0; s<arrsize; ++s)
    mm.insert(mm.end(), m[s].begin(), m[s].end());
 
  for (main_list_t::const_iterator i = mm.begin(); i!=mm.end(); ++i) {
    const std::list<size_t>& l = *i;
    for (std::list<size_t>::const_iterator ii = l.begin(); ii!=l.end(); ++ii) {
      std::cout<< *ii << '\t';
    }
    std::cout<<std::endl;
  }
}
I will try to build a Boost.PP version of this runtime, with PP lists I think,
 
and finally I will have your mpl version to compare the 2.
 
Unfortunately, I'll have to use MSVC2008 so I don't think variadic templates are usable, but I'm sure your solution can work without variadic templates.
 
Again, thank you very much,
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 0 comments |
headers
Robert Ramey | 1 Feb 06:25

Re: boost serialization stream error question

OvermindDL1 wrote:
> On Sun, Jan 31, 2010 at 6:11 PM, Robert Ramey <ramey <at> rrsd.com> wrote:
>> OvermindDL1 wrote:
>>> On Sun, Jan 31, 2010 at 10:34 AM, Robert Ramey <ramey <at> rrsd.com>
>>> wrote:
>>>>> The problem is caused by double values less than DBL_MIN.
>>>>> Apparently, streaming such values in causes the input stream
>>>>> fail_bit to be set, which causes the serialization lib to throw an
>>>>> exception.
>>>>
>>>> The standard stream library writes out NaN values as text, but
>>>> cannot read them.
>>>>
>>>> It shows up in various places besides the serialization library -
>>>> e.g. lexical_cast.
>>>>
>>>> Work has been done on this. I believe that there is code in vault
>>>> which deals with this.
>>>
>>> Why not just memcpy the double into the stream? (or bitcast it to
>>> long long or so?)
>>
>> text and xml archives are meant to be portable. This would conflict
>> with that requirement. Then there is the fact that putting binary
>> data into the text stream might create some conflicts depending on
>> the characterset etc. In general, one cannot put binary data into a
>> text stream and be able to count on getting it back.
>>
>> So here are a couple of options in order of my personal preference.
>>
>> a) Just avoid saving and restoring NaN's. They just waste space
>> in the archive anyway. There a number ways to do this.
>> b) find the fixup for floating point stream in either the vault
>> and/or sand box and install that.
>> b) wrap the double in a binary_wrapper and serialize that. This
>> would also break portability.
>
> What about for text archives print/read it out in the completely
> portable C99 Hex floating point constant?  It encodes all possible
> floating point values with no loss (including NaNs and such).  It is
> basically just a hex representation of the memory, see the C99 hex
> floating point standard for how it works.

This is the first I've heard of this.  I couldn't find any documentation
on it either.  I know some people have been working on addressing
this and it has been found to be non-trivial.  In any case, it's not
something that would be in the serialization library but rather in
the standard stream or some extension of it.  I am surprised to
hear about something like this in C99 which hasn't been included
in standard stream C++ library.  Makes me think I'm missing
something here.

Robert Ramey

> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 1 comment |
headers
OvermindDL1 | 1 Feb 06:49
Picon

Re: boost serialization stream error question

On Sun, Jan 31, 2010 at 10:25 PM, Robert Ramey <ramey <at> rrsd.com> wrote:
> OvermindDL1 wrote:
>> On Sun, Jan 31, 2010 at 6:11 PM, Robert Ramey <ramey <at> rrsd.com> wrote:
>>> OvermindDL1 wrote:
>>>> On Sun, Jan 31, 2010 at 10:34 AM, Robert Ramey <ramey <at> rrsd.com>
>>>> wrote:
>>>>>> The problem is caused by double values less than DBL_MIN.
>>>>>> Apparently, streaming such values in causes the input stream
>>>>>> fail_bit to be set, which causes the serialization lib to throw an
>>>>>> exception.
>>>>>
>>>>> The standard stream library writes out NaN values as text, but
>>>>> cannot read them.
>>>>>
>>>>> It shows up in various places besides the serialization library -
>>>>> e.g. lexical_cast.
>>>>>
>>>>> Work has been done on this. I believe that there is code in vault
>>>>> which deals with this.
>>>>
>>>> Why not just memcpy the double into the stream? (or bitcast it to
>>>> long long or so?)
>>>
>>> text and xml archives are meant to be portable. This would conflict
>>> with that requirement. Then there is the fact that putting binary
>>> data into the text stream might create some conflicts depending on
>>> the characterset etc. In general, one cannot put binary data into a
>>> text stream and be able to count on getting it back.
>>>
>>> So here are a couple of options in order of my personal preference.
>>>
>>> a) Just avoid saving and restoring NaN's. They just waste space
>>> in the archive anyway. There a number ways to do this.
>>> b) find the fixup for floating point stream in either the vault
>>> and/or sand box and install that.
>>> b) wrap the double in a binary_wrapper and serialize that. This
>>> would also break portability.
>>
>> What about for text archives print/read it out in the completely
>> portable C99 Hex floating point constant?  It encodes all possible
>> floating point values with no loss (including NaNs and such).  It is
>> basically just a hex representation of the memory, see the C99 hex
>> floating point standard for how it works.
>
> This is the first I've heard of this.  I couldn't find any documentation
> on it either.  I know some people have been working on addressing
> this and it has been found to be non-trivial.  In any case, it's not
> something that would be in the serialization library but rather in
> the standard stream or some extension of it.  I am surprised to
> hear about something like this in C99 which hasn't been included
> in standard stream C++ library.  Makes me think I'm missing
> something here.

The C++98 standard predates the C99 standard, and it does not include
some C99 things (like varadic macros as well as float-hex
representations).  Hopefully it is included in C++1x though.
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 0 comments |
headers
Thomas Mang | 1 Feb 06:56
Picon

[random] present library status and doc

Hi,

What is the present library status of the random library,and in how far 
are the documentation and the code base out-of-sync ?

I just tried a variate_generator with mt19937 as engine and a 
normal_distribution as distribution. IIRC, then some years ago this did 
not work as the normal_distribution requires an input in the [0,1] 
range, but now it seems to work. Looking into the header files I 
concluded under the hood there has been quite some development going on.

Also for uniform_01 things apparently changed quite a lot, there is now 
also for example a new_uniform_01 etc.

My main questions:
Is the library presently under active development ?
Shall I rely on the docs, or not ? For example, is above normal 
distribution now deliberately working, or am I relying on a deliberately 
undocumented feature which might be removed later ?
Because many more distributions now exist I think the docs are just 
totally out of date. Any plans of updating them ?

cheers,
Thomas
Permalink | Reply | 9 comments |
headers
Sebastian Mach | 1 Feb 07:27

Re: boost::random: get same number sequences 32/64 bit?

> Sebastian Mach wrote:
>
> Are you using the same version of Boost for both?
> There were a bunch of bug fixes in uniform_int a few releases
> ago, which change the exact sequence produced.
>
> In Christ,
> Steven Watanabe
>
>

Hello Steven,

This was indeed the problem. The one box had boost 1.35 installed, the
other one 1.41. Thanks for that hint.

I guess this is a) not the right place and b) the interest is probably
low (and let it be because it's not in the consciousness of many
people):
 * I realized that just replacing uniform_int.hpp with the older
version (that is, in a project local directory) and renaming
components was not easily possible
 * hence it might be hard in the future to trust boost::random in the
little corner where I really need portable random number sequences (as
users will literally work with seeds)
 * thus, I (and maybe some other persons) would love if, as with
spirit::classic, backwards compatibility could be provided somehow,
either via a typedef, a #define, or in the future with inline
namespaces

Of course, if there is already a way that "guarantees" (not as in
law), I would be happy (after all, I am already happy to have a small
regression test generator which initially showed me the problem; if
there is interest, it is at
http://gitorious.org/picogen/picogen/trees/master/trunk/kallisto/test
:) ). Otherwise, I must really stick to hand written RNGs, which are
less portable in code, but more portable in sequences, as no RNG-lib I
know seems go have this kind of portability as a guideline.

Many thanks for your help so far,

Sebastian Mach
phresnel <at> gmail.com
Permalink | Reply | 2 comments |

Gmane