[multi_array] Undocumented boost::copy_n in multi_array/algorithm.hpp

In a project of mine I use a (global) copy_n function template (that copies the 
first n elements of one sequence to another). When I tried using my copy_n with 
an iterator returned by multi_array<..>::begin, I got some unexpected argument 
mismatches. It turned out that multi_array/algorithm.hpp defines an undocumented 
boost::copy_n function template (with a different argument order than my own 
copy_n), which was selected instead of my own copy_n due to ADL.

I'm not sure this is a "bug", but it seems to me that this boost::copy_n should 
either be documented, or placed in boost::detail so it won't conflict with user 
defined copy_n's (like it did in my case).

Regards,

Eelis

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

Re: Re: Re: Re: Re: [gui] GUI Taxonomy

"Alan Gutierrez" <alan-boost <at> engrm.com> wrote
>* Andy Little <andy <at> servocomm.freeserve.co.uk> [2004-12-31 13:36]:

>> Hmm  I see what you are saying ... The os privately owns the draw 
>> function
>> for some (system) elements. So it doesnt need to be part of the interface
>> except for user drawn elements
>
>    Or library drawn elements (a nit).

Yes.... on reflection the draw() function in the previous post was a red 
herring, and is closer to implementation as you say though IMO could also be 
classified as a particular type of graphics_element based on who owns its 
graphics real-estate. Nevertheles Who does the drawing is probably a key 
part of the make up of a particular graphics_element,  and presumably it 
should be possible in an ideal world to change an element at run_time, from 
say a dumb rectangle ( explicitly drawn), to a window (drawn by the OS) to 
an embedded curses application (though see final paragraph),.

The  main idea behind the graphics_elements is to provide a single mechanism 
to express the spatial relationship between diverse entities in some 2D 
space(s).There is also something like a 3rd dimension  (the Z-order) to 
consider in this ( as has been mentioned in another post) . I conjecture 
that there should be some common framework to express this. One needs surely 
to be able to measure distances and know extents of graphics_elements, 
regardless of their darker purpose, in order to implement a layout manager 
for example.

>    Also, I'm not creating boundries across applications, or

Re: Re: Re: Re: Re: Re: [gui] GUI Taxonomy

* Andy Little <andy <at> servocomm.freeserve.co.uk> [2005-01-01 05:41]:
> 
> "Alan Gutierrez" <alan-boost <at> engrm.com> wrote
> >* Andy Little <andy <at> servocomm.freeserve.co.uk> [2004-12-31 13:36]:
> 
> >> Hmm  I see what you are saying ... The os privately owns the draw 
> >> function
> >> for some (system) elements. So it doesnt need to be part of the interface
> >> except for user drawn elements
> >
> >    Or library drawn elements (a nit).

> Yes.... on reflection the draw() function in the previous post was
> a red herring, and is closer to implementation as you say though
> IMO could also be classified as a particular type of
> graphics_element based on who owns its graphics real-estate.

> Nevertheles Who does the drawing is probably a key part of the
> make up of a particular graphics_element,  and presumably it
> should be possible in an ideal world to change an element at
> run_time, from say a dumb rectangle ( explicitly drawn), to a
> window (drawn by the OS) to an embedded curses application (though
> see final paragraph),.

    Consider a draw method for a spread sheet. Is there a graphics
    element for each cell? If I load 100x10,000 workbook, do I
    create 1,000,000 cell objects so that each of them can draw
    themselves? No. The grid draws the cells.

    Even if you had a grid flyweight, and create a cache of cell

Re: [gui] The Big Picture [and wxWidgets]

Heya Rene,

That all sounds great; perhaps we should be helping out the wx guys 
rather than come up with our own library...?

Does anyone else have any good reason why we should create a completely 
new library assuming that those issues are addressed?  (License could be 
one problem quite aside from the technical issues.)

Keep in mind that starting a GUI library from scratch is going to take 
*significant* time.

And is wxWindows our "best bet"?  It's certainly going to be easier than 
trying to convince the Qt folks to get rid of their preprocessor...  ;)

It'd be fantastic if all the issues I brought up with wxWidgets were 
addressed and we ensured that it worked well with the other boost libraries.

Is there anything anyone else wants or needs that wxWidgets couldn't 
supply?

Cheers,
Matt

PS I've started looking through the wx developer archives.  Interesting. 
  They seem to be very much in the 'early days' and moving quite slowly 
(one guy mentioned that he expected wxTNG (aka wxWidgets 3.x) to be 
delivered in 2-3 years!) but they do appear to be interested in working 
alongside boost - there was even a tongue-in-cheek suggestion that they 
submit the next revision as "boost-gui"!  Check out the following threads:

Re: [type_traits] request for decayed<T>::type

"Thorsten Ottosen" wrote:

> The following trait is supposed to make it easier to forward
> arguments in generic code and in particular string literals. For example, 
> I
> will use it when I update boost.assign
> to use const T& arguments instead of T arguments. It could also be used to
> make a better version of std::make_pair():
>
>  template< class F, class S >
>    inline std::pair< typename decayed<F>::type,
>                      typename decayed<S>::type >
>    make_pair( const F& f, const S& s )
>    {
>        return std::pair< typename decayed<F>::type,
>                          typename decayed<S>::type >( f, s );
>    }
>
> Any thoughts from the type_traits authors?
> Do anybody mind if I add this to the cvs and make some docs for the
> type-traits library?
>
Attached is file which works on VC6 / Intel 7 / BCB6.4.
Only tiny changes were needed.

This boost::make_pair would be very useful.

Questions:

Re: Re: Object Hierarchies using Interface Types with the BIL

Hi, 
So the boost interface library implements something like the gnu gcc
signatures? You create proxy classes that forward to non-virtual
methods? 

Regards 
Andreas Pokorny

On Fri, Dec 31, 2004 at 11:09:14AM -0500, christopher diggins <cdiggins <at> videotron.ca> wrote:
> ----- Original Message ----- 
> From: "Reece Dunn" <msclrhd <at> hotmail.com>
> To: <boost <at> lists.boost.org>
> Sent: Friday, December 31, 2004 4:26 AM
> Subject: [boost] Re: Object Hierarchies using Interface Types with the BIL
> 
> 
> >christopher diggins wrote:
> >>On the subject of GUI object hierarchies, I wanted to bring to everyone's 
> >>attention the Boost Interfaces Library (BIL) currently being developed by 
> >>Jonathan Turkanis which could be an excellent tool for building a 
> >>flexible and efficient GUI library. There is a brief introduction to the 
> >>library on the Boost wiki ( 
> >>http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Interfaces )
> >>
> >>The code for declaring the interfaces would look like this:
> >>
> >>BOOST_IDL_BEGIN(ILabel)
> >> BOOST_IDL_CONST_FN0(GetText, string)
> >> BOOST_IDL_CONST_FN0(GetAlignment, align_T)
> >>BOOST_IDL_END(ILabel)

Re: [type_traits] request for decayed<T>::type

On Dec 22, 2004, at 8:29 AM, Thorsten Ottosen wrote:

> The following trait is supposed to make it easier to forward
> arguments in generic code and in particular string literals. For 
> example, I
> will use it when I update boost.assign
> to use const T& arguments instead of T arguments. It could also be 
> used to
> make a better version of std::make_pair():
>
>   template< class F, class S >
>     inline std::pair< typename decayed<F>::type,
>                       typename decayed<S>::type >
>     make_pair( const F& f, const S& s )
>     {
>         return std::pair< typename decayed<F>::type,
>                           typename decayed<S>::type >( f, s );
>     }
>
> Any thoughts from the type_traits authors?

I think decayed is an excellent trait.  Your implementation should be 
modified to also take care of functions converting into function 
pointers though.  It's a shame about the const qaulifier in your 
example make_pair messing up the int[10] conversion to int*.  But with 
an eye towards the future, I think decayed will still eventually 
improve make_pair:

template <class T, class U>
inline

Re: Re: Object Hierarchies using Interface Types with the BIL

----- Original Message ----- 
From: "Andreas Pokorny" <andreas.pokorny <at> gmx.de>
To: <boost <at> lists.boost.org>
Sent: Saturday, January 01, 2005 11:22 AM
Subject: Re: [boost] Re: Object Hierarchies using Interface Types with the 
BIL

>Hi,
>So the boost interface library implements something like the gnu gcc
>signatures? You create proxy classes that forward to non-virtual
>methods?
>
>Regards
>Andreas Pokorny

That is close, but the method forwarded to may or may not be virtual. I 
don't know how the gnu gcc signatures worked, I have only heard second-hand 
that it was a similar technique. There is an article at
http://www.codeproject.com/cpp/retrofitpolymorphism2.asp which explains how 
the technique works using double-width pointers. There was also an article 
on it, in the September 2004 issue of the C/C++ Users Journal.

Christopher Diggins
http://www.cdiggins.com

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

Re: Re: Re: Re: Re: Re: [gui] GUI Taxonomy

"Alan Gutierrez" <alan-boost <at> engrm.com> wrote in message
news:20050101122432.GA24017 <at> maribor.izzy.net...
>* Andy Little <andy <at> servocomm.freeserve.co.uk> [2005-01-01 05:41]:
>>
>> "Alan Gutierrez" <alan-boost <at> engrm.com> wrote
>> >* Andy Little <andy <at> servocomm.freeserve.co.uk> [2004-12-31 13:36]:
>>
>> >> Hmm  I see what you are saying ... The os privately owns the draw
>> >> function
>> >> for some (system) elements. So it doesnt need to be part of the
>> >> interface
>> >> except for user drawn elements
>> >
>> >    Or library drawn elements (a nit).
>
>> Yes.... on reflection the draw() function in the previous post was
>> a red herring, and is closer to implementation as you say though
>> IMO could also be classified as a particular type of
>> graphics_element based on who owns its graphics real-estate.
>
>> Nevertheles Who does the drawing is probably a key part of the
>> make up of a particular graphics_element,  and presumably it
>> should be possible in an ideal world to change an element at
>> run_time, from say a dumb rectangle ( explicitly drawn), to a
>> window (drawn by the OS) to an embedded curses application (though
>> see final paragraph),.
>
>    Consider a draw method for a spread sheet. Is there a graphics
>    element for each cell? If I load 100x10,000 workbook, do I

Re: Re: feature wish for boost 1.32.1 or 1.33.0: pkg-config support

On Sun, Dec 26, 2004 at 09:27:04PM -0600, "Marcelo E. Magallon" <mmagallo <at> debian.org> wrote:
> On Thu, Dec 16, 2004 at 10:19:36AM +0000, Jonathan Wakely wrote:
> 
>  > I though that emits the flags that /should/be/ used to compile
>  > against Boost, not the flags the /were/ used to compile Boost itself.
> 
>  You can store arbitrary variables in .pc files and retrieve them using
>  pkg-config --variable=name.  The only trick here is to define the name
>  of the package or packages and make that consistent across all systems.
Thats not enough, the return values of pkg-config must be dependant on 
the toolset setting, and a few flags like debug, multithreaded.. 

>  It's no use to have boost-redhat.pc and boost-darwin.pc because that's
>  precisely the point of pkg-config.  boost.pc and boost-signals.pc and
>  boost-regex.pc are all fine.
Sure boost has to provide these files. The current situation is
unbearable.

Regards Andreas Pokorny

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