On Mon, Aug 27, 2012 at 5:46 AM, Paolo Carlini 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 __generate functions
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 08/27/2012 02:44 AM, Ulrich Drepper wrote:
On Sun, Aug 26, 2012 at 1:36 PM, Jonathan Wakely 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
function. This required in
On Sun, 26 Aug 2012, Ulrich Drepper wrote:
On Sun, Aug 26, 2012 at 1:36 PM, Jonathan Wakely 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
function. This required in
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
Hi,
On 08/26/2012 07:19 PM, Ulrich Drepper wrote:
On Sun, Aug 26, 2012 at 10:27 AM, Paolo Carlini
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 name to __generate. I f
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 complicati
On Sun, Aug 26, 2012 at 10:04 AM, Daniel Krügler
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.
2012/8/26 Paolo Carlini :
> 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.
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.
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 initi
2012/8/26 Ulrich Drepper :
> On Sun, Aug 26, 2012 at 7:20 AM, Ulrich Drepper 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 distribution.
>
> How about the fol
Adding Daniel's correct address (Daniel, the thread started at
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01752.html)
On 26 August 2012 14:38, Jonathan Wakely wrote:
> On 26 August 2012 14:08, Ulrich Drepper wrote:
>>
>> If people agree this is acceptable and the consensus is that
>> generate_n(
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 work can be submitted. Still ways to go...
Unless you're thinking of changing the interface to take a poi
On Sun, Aug 26, 2012 at 4:52 AM, Marc Glisse 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.
> If the goal is
On Sat, 25 Aug 2012, Ulrich Drepper wrote:
On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini 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:
template
class normal_distribution
{
On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini 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:
template
class normal_distribution
{
template
void
fil
On 08/25/2012 07:39 PM, Ulrich Drepper wrote:
On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely 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_ins
Ulrich Drepper 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 functions
template
On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely 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 this is already t
On 26 August 2012 00:33, Ulrich Drepper wrote:
> On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini
> 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 prelimi
On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini 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 iterators to specify
> thos
.. 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.
Hi,
(please remember to CC libstdc++ for discussions involving the library)
On 08/25/2012 10:31 PM, Ulrich Drepper wrote:
The current 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.
The current 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 instance,
25 matches
Mail list logo
