On Sun, 26 Aug 2012, Ulrich Drepper wrote:
On Sun, Aug 26, 2012 at 1:36 PM, Jonathan Wakely jwakely@gmail.com wrote:
But I've just seen Paolo's suggestion for a __generate_impl that both
use, and I prefer that idea.
How about the following. I introduced a __generate_impl() member
On 08/27/2012 02:44 AM, Ulrich Drepper wrote:
On Sun, Aug 26, 2012 at 1:36 PM, Jonathan Wakely jwakely@gmail.com wrote:
But I've just seen Paolo's suggestion for a __generate_impl that both
use, and I prefer that idea.
How about the following. I introduced a __generate_impl() member
On 08/27/2012 11:46 AM, Paolo Carlini wrote:
(the advance patch is also pending, I guess).
I meant discard of course.
Paolo.
On Mon, Aug 27, 2012 at 5:46 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
One last observation from me: I think we are being a little inconsistent in
terms of inlining. I see some __generate_impl with a non-trivial body inline
whereas other, with a tad smaller body, in random.tcc.
For the
On Sat, 25 Aug 2012, Ulrich Drepper wrote:
On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Understood, but you do *not* loose performance by having those fill functions
templates,
Let's see. The prototypes will then be something like this:
templatetypename
On Sun, Aug 26, 2012 at 4:52 AM, Marc Glisse marc.gli...@inria.fr wrote:
The std::generate(_n) function seems closer than std::fill. Not sure if
overloading that function (std::generate_n) would make sense, it avoids
changing the interface.
I'm not wedded to fill. generate_n is fine as well.
On 26 August 2012 14:08, Ulrich Drepper wrote:
If people agree this is acceptable and the consensus is that
generate_n() is the better name I can submit a patch so that the
remaining random work can be submitted. Still ways to go...
Unless you're thinking of changing the interface to take a
2012/8/26 Ulrich Drepper drep...@gmail.com:
On Sun, Aug 26, 2012 at 7:20 AM, Ulrich Drepper drep...@gmail.com wrote:
What I could imagine working is that the iterator fill/generate_n
functions are defined and in addition the special versions which use
pointers of the result_type of the
Hi,
On 08/26/2012 04:04 PM, Daniel Krügler wrote:
Personally I consider it as very unfortunate that an overload for
pointers should be necessary here. To solve the specialization problem
I'm in favour to provide free function templates instead (I also think
that they should better get an
On 08/26/2012 04:04 PM, Daniel Krügler wrote:
The function really should have a different name, as mentioned by
others. I also agree with others that generate would be a better name
than fill.
Thus, all in all, for the time being I would go with __generate.
Paolo.
On Sun, Aug 26, 2012 at 10:04 AM, Daniel Krügler
daniel.krueg...@gmail.com wrote:
The typedef pointer should be removed, because it is not used at all.
That 'pointer' type is needed for the __normal_iterator use. Unfortunately.
On 26 August 2012 18:19, Ulrich Drepper wrote:
Also, I consider the interface clean and now very C++-y. Iterators
are used and transparently all kinds of overloads are possible. Only
the iterator variants need to be documented, making the extensions
easy to use. The only minor complication
Hi,
On 08/26/2012 07:19 PM, Ulrich Drepper wrote:
On Sun, Aug 26, 2012 at 10:27 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
Thus, all in all, for the time being I would go with __generate.
OK, here's a version of the patch with the patch for 54376 already assumed.
I changed to function
On 26 August 2012 18:34, Jonathan Wakely wrote:
On 26 August 2012 18:19, Ulrich Drepper wrote:
Also, I consider the interface clean and now very C++-y. Iterators
are used and transparently all kinds of overloads are possible. Only
the iterator variants need to be documented, making the
The current random interface as defined in the standard is not well
suited for heavy users such as simulations. The only way to get a
number is using the operator() one-by-one. This can lead to
significant overhead and, perhaps more importantly, prevents
optimizations from being applied. For
Hi,
(please remember to CC libstdc++ for discussions involving the library)
On 08/25/2012 10:31 PM, Ulrich Drepper wrote:
The current random interface as defined in the standard is not well
suited for heavy users such as simulations. The only way to get a
number is using the operator()
.. another preliminary comment of mine: why not using iterators to
specify those ranges, instead of plain pointers? Aren't the forward
iterators generally Ok, like for std::fill itself?
Paolo.
On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Personally, assuming the name itself is already reserved / used elsewhere,
That was my thinking as well. There shouldn't be any further namespace problem.
.. another preliminary comment of mine: why not using
On 26 August 2012 00:33, Ulrich Drepper drep...@gmail.com wrote:
On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini paolo.carl...@oracle.com
wrote:
Personally, assuming the name itself is already reserved / used elsewhere,
That was my thinking as well. There shouldn't be any further namespace
On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely jwakely@gmail.com wrote:
But iterators don't have to imply non-sequential storage. Using
iterators instead of pointers would allow you to store them in a
std::deque, for example, or in a std::vector using
std::back_insert_iterator.
Yes, and
Ulrich Drepper drep...@gmail.com ha scritto:
Yes, and this is already trivial to do with the operator() interface.
The fill() interface is needed for performance, everything else is
taken care by the operator() interface.
Understood, but you do *not* loose performance by having those fill
On 08/25/2012 07:39 PM, Ulrich Drepper wrote:
On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely jwakely@gmail.com wrote:
But iterators don't have to imply non-sequential storage. Using
iterators instead of pointers would allow you to store them in a
std::deque, for example, or in a
On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Understood, but you do *not* loose performance by having those fill functions
templates,
Let's see. The prototypes will then be something like this:
templatetypename _RealType = double
class
23 matches
Mail list logo
