On Sunday, 3 February 2013 at 00:34:48 UTC, Namespace wrote:
On Saturday, 2 February 2013 at 22:39:58 UTC, monarch_dodra
wrote:
On Saturday, 2 February 2013 at 22:15:56 UTC, Namespace wrote:
My real question was: will we ever have fixed size arrays at
runtime?
I see no reason why we
On Sunday, 3 February 2013 at 06:02:04 UTC, Ali Çehreli wrote:
Its output is different in that the number of allocations is
less than C++ but the total number of elements that get moved
are more:
[SNIP]
Ali
Note that dynamic arrays are generic containers, so they aren't
exactly
Note that dynamic arrays are generic containers, so they aren't
exactly optimized for anything. You could try that test with
the made for appending std.array.appender: It always tries to
extend without reallocating, and only relocates when the
current memory segment is 100% full.
Sure, but alloca has the same ugly interface as malloc. :/
On Sunday, 3 February 2013 at 08:53:11 UTC, timotheecour wrote:
Note that dynamic arrays are generic containers, so they
aren't exactly optimized for anything. You could try that test
with the made for appending std.array.appender: It always
tries to extend without reallocating, and only
One more: Did you try using std.container.Array?
Even if appender is more optimized than naked array appending,
it still has to work with the underlying system.
std.container.Array should be able to do just as well as
vector, or better (D move semnantics).
it's a bit better (see below for
Am 02.02.2013 18:40, schrieb Namespace:
No one said that this is a problem, or? (;
But why should I generate an array with size 4 if an append of me resize
it to 5?
That's what reserve is for.
auto bla = new ubate[4];
bla[3] = 1; // valid
ubyte[] bla;
bla.reserve(4);
bla[3] = 1; // invalid
On Sun, 03 Feb 2013 03:53:10 -0500, timotheecour
thelastmamm...@gmail.com wrote:
Note that dynamic arrays are generic containers, so they aren't exactly
optimized for anything. You could try that test with the made for
appending std.array.appender: It always tries to extend without
On Sat, 02 Feb 2013 23:37:10 -0500, Ali Çehreli acehr...@yahoo.com wrote:
Rather, a better growth factor is 150%. It has been shown that 150%
growth factor works much better with memory allocators.
in fact, D's appender uses something more than doubling. I did not write
that part (though
On Sunday, 3 February 2013 at 10:32:10 UTC, timotheecour wrote:
One more: Did you try using std.container.Array?
Even if appender is more optimized than naked array appending,
it still has to work with the underlying system.
std.container.Array should be able to do just as well as
vector,
On Sunday, 3 February 2013 at 11:47:21 UTC, Steven Schveighoffer
wrote:
On Sun, 03 Feb 2013 03:53:10 -0500, timotheecour
thelastmamm...@gmail.com wrote:
Note that dynamic arrays are generic containers, so they
aren't exactly optimized for anything. You could try that
test with the made for
On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
Sure, but alloca has the same ugly interface as malloc. :/
You mean that you have to specify how many raw bytes you want,
then cast it to what you need? I never thought alloca or malloc
were that ugly.
Era Scarecrow:
On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
Sure, but alloca has the same ugly interface as malloc. :/
You mean that you have to specify how many raw bytes you want,
then cast it to what you need? I never thought alloca or malloc
were that ugly.
The
In bugzilla there is a preliminary request for better and less
bug-prone VLAs for D.
Bye,
bearophile
Can you link it here?
Namespace:
In bugzilla there is a preliminary request for better and less
bug-prone VLAs for D.
...
Can you link it here?
http://d.puremagic.com/issues/show_bug.cgi?id=5348
Bye,
bearophile
On 02/03/2013 02:32 AM, timotheecour wrote:
I'm curious whether you have a reference explaining why
3/2 works better than 2x (as in std::vector) in resizing?
I had heard about this years ago first on comp.lang.c++.moderated. I am
pretty sure it is common practice in modern libraries.
This
On 02/03/2013 03:57 AM, Steven Schveighoffer wrote:
On Sat, 02 Feb 2013 23:37:10 -0500, Ali Çehreli acehr...@yahoo.com
wrote:
Rather, a better growth factor is 150%. It has been shown that 150%
growth factor works much better with memory allocators.
in fact, D's appender uses something
On 02/02/2013 03:41 AM, Gor Gyolchanyan wrote:
How can I set my local envoronment variables so that further calls to
std.process.system can pick it up?
std.process has the nice AA-like 'environment':
import std.process;
void main()
{
environment[MY_ENV_VAR] = 42;
system(echo
On 02/03/13 16:53, SaltySugar wrote:
GTKD. Can someone explain me how to change button size in vbox, hbox?
setSizeRequest (70, 50); doesn't work. Thanks.
Try playing with an interactive gui tool, such as glade. The fill, expand and
size request interactions will be immediately visible.
artur
On Sunday, 3 February 2013 at 13:22:53 UTC, bearophile wrote:
The interface of alloca() is bug-prone. And it's not handy if
you want to create a 2D or nD array on the stack :-) In
bugzilla there is a preliminary request for better and less
bug-prone VLAs for D.
Maybe. I barely have ever
Era Scarecrow:
I barely have ever used alloca myself,
I have used alloca less than 10 times in D with DMD, but the
performance improvement was well visible.
Maybe a possible use for a template instead?
I don't know.
Bye,
bearophile
21 matches
Mail list logo
