Iterator facade example could use some changes/documentation adjustments

My example here:
http://codepad.org/pH3pXAvb

As mentioned in the comment block at the codepad page:
http://www.boost.org/doc/libs/1_41_0/libs/iterator/doc/iterator_facade.html#wrap-up

The above link demonstrates in a linked-list scenario, using
is_convertible to handle
the conversion from non-const iterators to const iterators.  This
works fine in the
example's linked list scenario, but it's likely than many users of
iterator_facade
will more generally copy this usage to their own container, from the example.

However, as my example demonstrates, in the case where the data lives
in contiguous
memory locations, or perhaps other scenarios, using is_convertible is very bad
for this purpose.  It lets you convert from a derived class pointer to
a base class
pointer, and this is problematic if sizeof(base) is less than sizeof(derived)

See the below, very minimal example to illustrate my point.

Look at CFixedTest for my proposed replacement for is_convertible to
prevent this
undesirable behavior.

Seems to me that noting such behavior, or simply changing the example
code to not
allow the conversion (as my example does), would remedy the
misunderstanding/problem.

Just thought I'd contribute that - thanks,
nacitar
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[transact] code in sandbox

Hi,

I haven't had much time lately, and that's not going to change to next  
couple of weeks, so I've uploaded what I have so far to the sandbox:

https://svn.boost.org/svn/boost/sandbox/transaction/boost/transact/

what's new:

*** basic_transaction_manager:
  - now supports all kinds of combinations of commits, like we've  
discussed, including one-phase/transient two-phase, persistent  
two-phase. no logging/recovery yet.
  - lazy and non-lazy transaction construction, user-configurable

*** simple_transaction_manager:
a transaction manager supporting only one resource.  
basic_tranaction_manager includes a lot of MPL/fusion and the logging  
infrastrucure, none of which is needed for only one resource.
this is intended to be the default transaction manager when one of our  
libraries is used on its own.

*** logging infrastructure:
to be used by basic_transaction_manager for its distributed  
transaction log, and optionally by resource managers that need logging  
(so it is part of the public interface!)

  - olog_files: maintaining log files without knowing its contents,  
manual log rolling
  - otransaction_log_files: same as olog_files, but automatic log  
rolling based on transactions
  - olog: writes to olog_files, aware of log entries
  - olog_buffer: same interface as olog, but buffers log entries  
locally and only accesses the log when the internal buffer overflows.
  - TODO: ilog_files/ilog to read/recover from logs. code is there,  
but not migrated to "transact".
  - TODO: interleaved_ologs/..., providing multiple olog interfaces so  
different resource managers can share a log, as we've discussed.

*** new syntax for transaction scopes:
syntax changed from:
atomic{
   ...
}retry;

to

do atomic{

}commit();

I prefer that syntax because it resembles the do{}while(...) syntax.
downside is that it conflicts with transaction::commit() if the user  
chooses to define BOOST_TRANSACT_COMMIT to "commit" (as is done above).

*** TODO object_access
not migrated to "transact" yet. utility functions for resource  
managers to serialize/clone/compare/... objects.

regards,

Stefan

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

[1.3.9][thread]:nm: libboost_thread-gcc40-mt-1_39.sl: no symbols

Hi
   I have built the boost thread library locally in hpux 11.23 system. But
when I try to check the symbol in the library using nm it displays the
following message.
nm:  libboost_thread-gcc40-mt-1_39.sl:  no symbols.
Please let me know how to check the symbols in boost library.

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

Re: [1.3.9][thread]:nm: libboost_thread-gcc40-mt-1_39.sl: no symbols

*

gopal haldar wrote:

> Hi
>    I have built the boost thread library locally in hpux 11.23 system. But
> when I try to check the symbol in the library using nm it displays the
> following message.
> nm:  libboost_thread-gcc40-mt-1_39.sl:  no symbols.
> Please let me know how to check the symbols in boost library.

What do you mean by 'check symbols'? Do you have 'readelf'?

- Volodya

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

Re: [1.3.9][thread]:nm: libboost_thread-gcc40-mt-1_39.sl: no symbols

Vladimir Prus wrote:
*

> gopal haldar wrote:
>
>   
>> Hi
>>    I have built the boost thread library locally in hpux 11.23 system. But
>> when I try to check the symbol in the library using nm it displays the
>> following message.
>> nm:  libboost_thread-gcc40-mt-1_39.sl:  no symbols.
>> Please let me know how to check the symbols in boost library.
>>     
>
> What do you mean by 'check symbols'? Do you have 'readelf'?
>
> - Volodya
>
>
>   
Try nm -D
BR, Dmitry

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

TMP runtime access problem

Hi, I wonder that how to access metadata in runtime.
If I pre-compute something and save them into a template ARRAY<int N>,
how can I random access the metadatas in runtime?
What I can only do is binary searching. Is it possible to do in
constant time, or there exist some functions in MPL doing this?

#include<cstdio>

using namespace std;
template<int N>
struct ARRAY
{
       static const int a = ARRAY<N - 1>::a * 2;
};
template<>
struct ARRAY<0>
{
       static const int a = 1;
};
template<int LOWER, int UPPER>
struct BS
{
       static const int MID = UPPER + LOWER >> 1;
       typedef BS<MID + 1, UPPER> GREATER;
       typedef BS<LOWER, MID> LESS;
       static inline int binary_search(int n)
       {
               if(n > MID)
                       return GREATER::binary_search(n);
               else return LESS::binary_search(n);
       }
};
template<int N>
struct BS<N, N>
{
       static const int MID = N;
       typedef ARRAY<MID> result;
       static inline int binary_search(int n)
       {
               return result::a;
       }
};
int main()
{
       int n;
       printf("2^n n:");
       scanf("%d", &n);
       printf("ARRAY<%d>::a = %d\n", n, BS<0, 30>::binary_search(n));
       main();
       return 0;
}
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: TMP runtime access problem

Willy Liu a écrit :
*

> Hi, I wonder that how to access metadata in runtime.
> If I pre-compute something and save them into a template ARRAY<int N>,
> how can I random access the metadatas in runtime?
> What I can only do is binary searching. Is it possible to do in
> constant time, or there exist some functions in MPL doing this?

Just copy the data to an array, for example using mpl::for_each.

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

[rfc] sized_array

hi all,

i have a small class, something between std::vector and boost::array. if
others find it useful, i could submit it as an extension to the
boost.array libray.

it basically implements a dynamically sized array, similar to
boost::array, but its size can be defined at run-time, rather than
compile-time. in contrary to std::vector, which is only required to
support random-access iterators (which are implementation-defined), my
class guaranties to allocate the data in one consecutive memory area. it
can basically be used like boost::array, the only difference is its
constructor, which takes either an integer size or a container.

boost::array<float, 5> ba;
sized_array<float> sa(5);       // initialize to size 5
assert(sa.size() == ba.size()); // container size
ba.assign(pi);
sa.assign(pi);                  // assignment
sized_array<float> sa2(ba);     // construct from container

the code is available at [1], would be interested to hear, if other
people find it useful ..

thanks, tim

[1]
http://tim.klingt.org/git?p=nova-server.git;a=blob;f=source/utilities/sized_array.hpp;hb=HEAD

--

-- 
tim <at> klingt.org
http://tim.klingt.org

Art is either a complaint or do something else
  John Cage quoting Jasper Johns

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

Re: [rfc] sized_array

*

On 8 February 2010 19:09, Tim Blechmann <tim <at> klingt.org> wrote:
> [...] in contrary to std::vector, which is only required to
> support random-access iterators (which are implementation-defined), my
> class guaranties to allocate the data in one consecutive memory area. [...]
>

As of C++03, std::vector is contiguous, so I'm not convinced by the
utility of this.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [rfc] sized_array

*

>> [...] in contrary to std::vector, which is only required to
>> support random-access iterators (which are implementation-defined), my
>> class guaranties to allocate the data in one consecutive memory area. [...]
>>
> 
> As of C++03, std::vector is contiguous, so I'm not convinced by the
> utility of this.

interesting ... it seems, my assumption was based on c++98 ... i guess,
my class is pretty useless then :)

thanks for clearing this up!

tim

--

-- 
tim <at> klingt.org
http://tim.klingt.org

It is better to make a piece of music than to perform one, better to
perform one than to listen to one, better to listen to one than to
misuse it as a means of distraction, entertainment, or acquisition of
'culture'.
  John Cage

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

embedded_vector (was: Re: [rfc] sized_array)

Zitat von Tim Blechmann <tim <at> klingt.org>:

*

>>> [...] in contrary to std::vector, which is only required to
>>> support random-access iterators (which are implementation-defined), my
>>> class guaranties to allocate the data in one consecutive memory area. [...]
>>>
>>
>> As of C++03, std::vector is contiguous, so I'm not convinced by the
>> utility of this.
>
> interesting ... it seems, my assumption was based on c++98

I don't think that was changed from 98 to 03.
but your description reminded me of something I do think would be a  
useful addition to Boost.Array.

a vector that resides on the stack as long as it fits in there(like a  
boost::array) but still supports dynamic allocation in case the vector  
size exceeds the reserved space.

my implementation of this:

template<class T,std::size_t EmbeddedSize,bool Expand=true>
class embedded_vector;

embedded_vector<T,Size,false> should be equivalent to  
boost::array<T,Size>, but if Expand==true max_size() is unlimited,  
with no allocation as long as size() <= EmbeddedSize

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