[multi_array] typed subarray from raw memory

Hi,

While using multi_array, I found I frequently need a way to view some memory
which is a multi-dimensional array and I don't know the type of the element, but
I know its size and I know that this element has a member of the type I need
(and I know the offset).
So I need to be able to write something like

  struct A { double x, y; };

  void* p = mmap(...);
  size_t el_size = size_of_element_in_p;
  size_t offset  = offset_of_A_inside_element;

  boost::multi_array_typed_view<A, NumDims>
      my_view(p, extents, el_size, offset );

and have a standard multi_array-compatible interface.

Also, with existing multi_arrays of known types, this feature will give a way to
create views of element's members (the closest we have now is a strided view but
it only works if the element size is a multiple of the member size).

I filed a Feature Request for multi_array
(https://svn.boost.org/trac/boost/ticket/6073), but I wonder if there are any
other possibilities around, and I'd also like to know what the community think
of necessity of this feature.

Thanks,
Maxim

Re: [config] clang.hpp is not up-to-date

Attached a patch for updating clang's config.
With this patch, Boost works fluently with clang-3.0!

Regards,
Michel

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

Re: Interest in bounded (Top-Bounded) Range adaptor.

Hi, Fernando

2011/11/1 Fernando Pelliccioni <fpelliccioni <at> gmail.com>:
>> There exists an effort to port  the P-stade Oven library to Boost, called
>> OvenToBoost: https://github.com/faithandbrave/OvenToBoost.
>> If you are interested in seeing functionality like this in Boost, perhaps
>> you can consider contributing to this effort.
>
>
> "taken" is what I was looking for.
> I will contact the project owners to offer my help.

I'm OvenToBoost author and Oven mantainer.
OvenToBoost now status:
- code : complete
- documentation : incomplete. remain document is range-access,
algorithm, regular operator(operator|+) rationale.

Delay reason is weak my English and busy.
I'm going documentation to help with some Japan members.

I will to submit to Boost for review when document creation is complete.

>>========================
Akira Takahashi
mailto:faithandbrave <at> gmail.com
Blog: http://d.hatena.ne.jp/faith_and_brave/

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

Re: [atomic] comments

On Monday 31 October 2011 22:18:16 Andrey Semashev wrote:
> On Monday, October 31, 2011 21:33:19 Helge Bahmann wrote:
> > > I have to disagree. Atomics may be used to communicate processes just
> > > as well as threads, if not better.
> >
> > the question is not whether they *can* be used, but which case is more
> > common -- and considering the enormous amount of simple atomic
> > counters, "init-once" atomic pointers etc. found in typical applications
> > make me doubtful that inter-process coordination accounts for more than
> > 1% of use cases
>
> But that doesn't make the inter-process use case a second class citizen,
> does it? The implementation should support it just as well as intra-process
> cases.

If adding support for one use case penalizes another one, it is a balancing 
question and you have to answer "which one is more frequent", it's as simple 
as that.

> > > I want to be able to write atomic< index_t > so that it compiles and
> > > works on any platform, even without 64-bit CAS support in hardware. It
> > > may work slower, yes, but it will.
> >
> > what's wrong with just implementing a platform-specific "ipc queue"?
>
> Lots of reasons. I may not have access to all platforms, to begin with. I
> may not have enough knowledge about hardware capabilities of all of the
> platforms. Manual porting to multitude platforms may be expensive.

This is ridiculous. May I invite you to have a look at socket communication 

Re: [atomic] comments

On Monday 31 October 2011 23:30:19 Tim Blechmann wrote:
> > > > I think, having a mutex per atomic instance is an overkill. However,
> > > > a
> > > > spinlock per instance might just be the silver bullet. The size
> > > > overhead should be quite modest (1 to 4 bytes, I presume) and the
> > > > performance would still be decent. After all, atomic<> is intended
> > > > to be used with relatively small types with simple operations, such
> > > > as copying and arithmetics. In other cases it is natural to use
> > > > explicit mutexes, and we could emphasise it in the docs.
> > >
> > > might be possible, the problem is that this assumes that there is
> > > atomic<something> available -- as soon as you hit a platform where
> > > everything hits the fallback, you just have to use a mutex and the cost
> > > becomes unbearable
> >
> > True. But are there realistic platforms without any support of atomic ops
> > whatsoever today? If there are, I'm not sure the library should support
> > these platforms in the first place.
>
> well, it is quite a chicken-and-egg problem, we need atomics to implement
> atomics to implement atomics, when atomics are not available. but in the
> real world i guess all platforms will provide some kind of atomic
> operations, which are sufficient to implement basic spinlocks.
>
> it would also be fine with me to delegate the implementation to
> boost::detail::spinlock in the smart_ptr library (assuming that it will
> never be implemented via atomic<>)

I think that it might long-term be worthwhile to consider formulating 

Re: [atomic] comments

> > might be possible, the problem is that this assumes that there is
> > atomic<something> available -- as soon as you hit a platform where
> > everything hits the fallback, you just have to use a mutex and the cost
> > becomes unbearable
>
> True. But are there realistic platforms without any support of atomic ops
> whatsoever today? If there are, I'm not sure the library should support
> these platforms in the first place.

there is PA-RISC which only supports LDCW which must be cacheline-aligned -- 
as a result, each atomic value would have the size of one cacheline

(whether PA-RISC should be supported is another question)

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

Re: [unordered] 1.48 beta1 fails to compile with MSVC 2010 SP 1, error C2027: use of undefined type 'boost::type'

On Mon, Oct 31, 2011 at 10:21 PM, Daniel James <dnljms <at> gmail.com> wrote:
> On Monday, 31 October 2011, Johan Lindvall wrote:
>
>>
>> It would be great if this fix could be rolled into 1.48.
>>
>
> It should be, I'm waiting for the tests to run on the trunk testers. There
> are a couple of other changes to be merged and only one windows tester has
> run since the last change.

Thankyou, much appreciated.

--

-- 
/Johan.

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

[locale] Premission to merge clang bugfix changeset to release tree

Hello,

I'd like to ask a permission to merge a changeset 75174 from trunk to release tree.
It is a fix of build issue under clang-2.9 and clang-3.0.

See: https://svn.boost.org/trac/boost/changeset/75174

The changeset itself:

-------------------------
Index: /trunk/libs/locale/src/posix/codecvt.cpp
===================================================================
--- /trunk/libs/locale/src/posix/codecvt.cpp    (revision 73382)
+++ /trunk/libs/locale/src/posix/codecvt.cpp    (revision 75174)
 <at>  <at>  -135,5 +135,5  <at>  <at> 
             // maybe illegal or may be double byte

-            char inseq[3] = {seq0 , begin[1], 0};
+            char inseq[3] = { static_cast<char>(seq0) , begin[1], 0};
             char *inbuf = inseq;
             size_t insize = 3;
-------------------------

It solves build issues as I can see at trunk tests.

Thanks,

Artyom Beilis
--------------
CppCMS - C++ Web Framework:   http://cppcms.sf.net/

Re: [atomic] comments

> > Lots of reasons. I may not have access to all platforms, to begin with.
> > I
> > may not have enough knowledge about hardware capabilities of all of the
> > platforms. Manual porting to multitude platforms may be expensive.
> 
> This is ridiculous. May I invite you to have a look at socket communication
> via boost.asio?

socket communication and shared memory have quite different performance 
characteristics. e.g. i would not trust on accessing sockets from a real-time 
thread.

> > True. But are there realistic platforms without any support of atomic
> > ops
> > whatsoever today? If there are, I'm not sure the library should support
> > these platforms in the first place.
> 
> if it is not ported to the platform then nothing is avaialble. I have only
> recently finished sparcv9 implementation, itanium and mips still missing, so
> they would suffer immediately.

well, the spinlock pool uses boost::detail::spinlock (i hope no platform will 
rely on the fallback implementation in spinlock_nt.hpp, which seems to be 
simply wrong). imo, associating one with each emulated atomic<> would not be a 
huge memory overhead.

iac, if we want boost::atomic<> to behave similar to std::atomic<> so that it 
works a drop-in replacement, the implementation should follow the standard as 
closely as possibe.
in the end it would be great if someone could simply use a different namespace 

Re: [atomic] comments

On Tuesday 01 November 2011 10:49:55 Tim Blechmann wrote:
> > > Lots of reasons. I may not have access to all platforms, to begin with.
> > > I
> > > may not have enough knowledge about hardware capabilities of all of the
> > > platforms. Manual porting to multitude platforms may be expensive.
> >
> > This is ridiculous. May I invite you to have a look at socket
> > communication via boost.asio?
>
> socket communication and shared memory have quite different performance
> characteristics.

is there some semantic ambiguity to the word "fallback" that escapes me? or do 
you expect the "fallback" to have the same performance characteristic as 
the "optimized" implementation, always? then please explain to me how a 
fallback for atomic variables using locks is going to preserve your expected 
performance characteristics

> e.g. i would not trust on accessing sockets from a 
> real-time thread.

what makes you believe that message channels in real-time systems were 
designed so dumb as to make them unusable for real-time purposes?

> > > True. But are there realistic platforms without any support of atomic
> > > ops
> > > whatsoever today? If there are, I'm not sure the library should support
> > > these platforms in the first place.
> >
> > if it is not ported to the platform then nothing is avaialble. I have