But D isn't like Ada. It's more like C++ and there Heap
allocations is often used too.
It would be really cool if we had allocators already.
Something like:
with (AllocatorX) { /// will use malloc and free instead of
calling the GC
float[] arr;
arr ~= 42;
}
And I still don't
On Sunday, July 21, 2013 05:17:03 Carl Sturtivant wrote:
> On Saturday, 20 July 2013 at 22:33:00 UTC, bearophile wrote:
> > Carl Sturtivant:
> >> What is the conflict exactly?
> >
> > Perhaps it's a bug fixed in GIT head. As workaround try:
> >
> > this()(string s)
>
> OK, but now I don't know h
On 07/20/2013 06:04 PM, Alex Horvat wrote:
> On Saturday, 20 July 2013 at 20:36:29 UTC, Ali Çehreli wrote:
>> thread_joinAll();
> What happens if I don't call thread join? (My thread is just a timer to
> hide a bit of text, so I just create it, forget about it and continue
> with the main t
I am experimenting with user defined attributes, but am wondering
if a list of all objects with a specified UDA could be generated?
If not, is there a workaround for getting these objects without a
direct reference?
On Saturday, 20 July 2013 at 20:36:29 UTC, Ali Çehreli wrote:
On 07/20/2013 12:34 PM, Alex Horvat wrote:
> If I use core.thread.Thread to create a new thread associated
to a
> function like this:
>
> Thread testThread = new Thread(&DoSomething);
>
> Will the testThread dispose of itself after Do
On Sunday, July 21, 2013 00:10:40 Carl Sturtivant wrote:
> struct A {
> string s;
> int n;
> this( string s) { this.s = s; }
> this( int k)( int n) { this.n = n - k; }
> }
>
> compiled with dmd gives an error message as follows.
>
> constr_conflict.d(5): Error: template
>
Namespace:
So, you would never allocate with float[]?
Generally in D I allocate on the heap with new, and once in a
while with minimallyInitializedArray. Stack-allocation is left
for situations where max performance is needed. Like you have to
build a tree of string distances, and you use a
On Saturday, 20 July 2013 at 21:39:31 UTC, bearophile wrote:
Namespace:
Yeah, but aren't 4000 elements a bit much for a stack
allocated array?
4000 floats take about 16 KB. If your function is not recursive
and it's not much transitively recursive, then I think it's
acceptable. But how much
Carl Sturtivant:
What is the conflict exactly?
Perhaps it's a bug fixed in GIT head. As workaround try:
this()(string s)
Bye,
bearophile
struct A {
string s;
int n;
this( string s) { this.s = s; }
this( int k)( int n) { this.n = n - k; }
}
compiled with dmd gives an error message as follows.
constr_conflict.d(5): Error: template
constr_conflict.A.__ctor(int k)(int n) conflicts with constructor
co
Namespace:
Yeah, but aren't 4000 elements a bit much for a stack allocated
array?
4000 floats take about 16 KB. If your function is not recursive
and it's not much transitively recursive, then I think it's
acceptable. But how much stack are your other functions using?
You have to estimate i
On Friday, 19 July 2013 at 22:18:54 UTC, Gary Willoughby wrote:
The problem with that though is that with size arguments >
int.max will wrap when being cast to int (T)? i.e.:
I see. The only way to guarantee there's no wraparound with a
literal is to use a string which messes up the arithm
On Saturday, 20 July 2013 at 20:34:50 UTC, bearophile wrote:
Namespace:
But I want to hear other opinions. :)
D also supports alloca(), that for 1D arrays is almost bearable.
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=9832
Bye,
bearophile
Yeah, but aren't 4000 elements a bit
On Saturday, 20 July 2013 at 20:22:56 UTC, Dmitry Olshansky wrote:
21-Jul-2013 00:19, Namespace пишет:
Let us assume we have a method of a class which is used often
and the
method is called periodically and must allocate every time a
array
between 100 and 4000 elements. What would you do?
1.
On 07/20/2013 01:22 PM, Dmitry Olshansky wrote:
> 21-Jul-2013 00:19, Namespace пишет:
>> Let us assume we have a method of a class which is used often and the
>> method is called periodically and must allocate every time a array
>> between 100 and 4000 elements. What would you do?
> 5. Keep a TL
On 07/20/2013 12:34 PM, Alex Horvat wrote:
> If I use core.thread.Thread to create a new thread associated to a
> function like this:
>
> Thread testThread = new Thread(&DoSomething);
>
> Will the testThread dispose of itself after DoSomething() completes, or
> do I need to join/destroy/something
Namespace:
But I want to hear other opinions. :)
D also supports alloca(), that for 1D arrays is almost bearable.
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=9832
Bye,
bearophile
21-Jul-2013 00:19, Namespace пишет:
Let us assume we have a method of a class which is used often and the
method is called periodically and must allocate every time a array
between 100 and 4000 elements. What would you do?
1. Simple: float[] array;
2. Reserve: float[] array; array.reserve(N); //
Let us assume we have a method of a class which is used often and
the method is called periodically and must allocate every time a
array between 100 and 4000 elements. What would you do?
1. Simple: float[] array;
2. Reserve: float[] array; array.reserve(N); /// N is a parameter
value
3. Use ma
If I use core.thread.Thread to create a new thread associated to
a function like this:
Thread testThread = new Thread(&DoSomething);
Will the testThread dispose of itself after DoSomething()
completes, or do I need to join/destroy/somethingelse testThread?
On Saturday, 20 July 2013 at 18:53:44 UTC, JS wrote:
if they want to allow the same op in there class, which they
probably do, they have to override the long hand anyways and
redirect.
Nope, that is why you make the template final and forwards, all
derived classes will be able to instantiate
On Saturday, 20 July 2013 at 18:27:23 UTC, JS wrote:
is there any way to pass t directly to A?
template A(T...) doesn't seem work nor does using an alias. (or
at least, when I try to foreach over it, it doesn't work).
template A(size_t L) {
enum A = L;
}
template B(T...) {
void B(T b) {
On Saturday, 20 July 2013 at 18:34:30 UTC, Jesse Phillips wrote:
On Saturday, 20 July 2013 at 16:46:52 UTC, JS wrote:
class MyClass {
auto opBinary(string op : "|" T : int)(T t) { }
// opBinary is completely specialized and is no
different than a regular f
On Saturday, 20 July 2013 at 16:46:52 UTC, JS wrote:
class MyClass {
auto opBinary(string op : "|" T : int)(T t) { }
// opBinary is completely specialized and is no
different than a regular function, it can be overridden
directly in children without havin
On Saturday, 20 July 2013 at 17:39:59 UTC, bearophile wrote:
JS:
variadic parameters are suppose to make life easier but it
seems those don't work with templates.
template A(int L) { ... }
void foo(T)(string s, T t...)
{
A!(t.length);
}
Try this:
template A(size_t L) {
enum A = L;
On Saturday, 20 July 2013 at 17:39:59 UTC, bearophile wrote:
JS:
variadic parameters are suppose to make life easier but it
seems those don't work with templates.
template A(int L) { ... }
void foo(T)(string s, T t...)
{
A!(t.length);
}
Try this:
template A(size_t L) {
enum A = L;
JS:
variadic parameters are suppose to make life easier but it
seems those don't work with templates.
template A(int L) { ... }
void foo(T)(string s, T t...)
{
A!(t.length);
}
Try this:
template A(size_t L) {
enum A = L;
}
void foo(T...)(string s, T t) {
auto n = A!(t.length)
On Saturday, 20 July 2013 at 13:27:03 UTC, H. S. Teoh wrote:
On Sat, Jul 20, 2013 at 12:13:49PM +0200, JS wrote:
On Saturday, 20 July 2013 at 01:37:13 UTC, Jesse Phillips
wrote:
>The relevant blog post:
>
>http://3d.benjamin-thaut.de/?p=94
>
>What you should understand is template functions are
variadic parameters are suppose to make life easier but it seems
those don't work with templates.
template A(int L) { ... }
void foo(T)(string s, T t...)
{
A!(t.length);
}
gives error t can't be read at compile time.
I understand in general why this works BUT I will only ever use
foo whe
On Saturday, 20 July 2013 at 04:26:45 UTC, evilrat wrote:
with libglfw.dylib it works for me
evilrat$ dmd test.d
-L-L/Users/evilrat/Documents/prog/glfwbuild/osx/_install/lib
-L-lglfw
note that first -L is dmd flag to pass linker options, but if
you linking just single lib you can simply ad
On Sat, Jul 20, 2013 at 12:13:49PM +0200, JS wrote:
> On Saturday, 20 July 2013 at 01:37:13 UTC, Jesse Phillips wrote:
> >The relevant blog post:
> >
> >http://3d.benjamin-thaut.de/?p=94
> >
> >What you should understand is template functions are not/can not
> >be virtual. They do not exist until t
On Friday, 19 July 2013 at 17:51:29 UTC, Jonathan M Davis wrote:
On Friday, July 19, 2013 19:23:50 JS wrote:
On Friday, 19 July 2013 at 15:32:25 UTC, Jonathan M Davis
wrote:
> On Friday, July 19, 2013 11:06:26 JS wrote:
>> I would like to pass to all my templates the file and module
>> location
I am trying to write a simple template expansion of boolean
relations between values.
I've tried various ways but this is the only way I can get to
work without a compile time error:
template A(string, T, R...)
{
string A(string op, string s, T t, R r)
{
string
On Friday, 19 July 2013 at 19:05:27 UTC, Ali Çehreli wrote:
This seems to be a problem with any template that has to work
with pointers. The following template cannot work with a
pointer:
...
val.type returns a TypeInfo and it seems like there is no
TypeInfo special for pointers to incomple
On Saturday, 20 July 2013 at 10:46:44 UTC, Jacob Carlborg wrote:
On 2013-07-19 00:47, JS wrote:
Is there a way to get only the overridden implemented methods?
https://github.com/D-Programming-Language/dmd/pull/2366
Cool...
Gary Willoughby:
Are associative arrays stable in D?
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=4179
Bye,
bearophile
On 2013-07-19 00:47, JS wrote:
Is there a way to get only the overridden implemented methods?
https://github.com/D-Programming-Language/dmd/pull/2366
--
/Jacob Carlborg
JS:
A warning should be thrown for this type of behavior... it can
result in pretty serious and hard to find bugs.
Implementing _well_ such warning in D is hard...
Bye,
bearophile
On Saturday, 20 July 2013 at 01:37:13 UTC, Jesse Phillips wrote:
The relevant blog post:
http://3d.benjamin-thaut.de/?p=94
What you should understand is template functions are not/can
not be virtual. They do not exist until they are instantiated.
Thus you can not require that they be overload
On Friday, 19 July 2013 at 22:18:54 UTC, Gary Willoughby wrote:
The way I'd do the inBounds is to just use T size instead of
size_t size.
template inBounds(T, T size) { snip same stuff }
then
writefln("%s", inBounds!(int, 10).result); // true as
expected
The problem with that though
40 matches
Mail list logo
