Re: Classes and Structs, Memory management questions
On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote: Since garbage collection is a very nice feature that I wouldn't wanna miss for certain scenarios I think D should give us the opportunity to determine how an object is allocated. In the example above putting it on the stack is probably a good idea. Having a self managed reference to the heap can be good too if manual memory management is wanted. Or of course let the GC manage it ( i love it for prototyping code and also as a D beginner it is beneficial that i just dont need to care about memory management). Could somebody explain to me if this is seen as a problem why/whynot and how I should address that kind of issues in my code? You can allocate class instance on stack: https://dlang.org/phobos/std_typecons.html#.scoped
Re: Using OpenGL
On Friday, 2 September 2016 at 20:38:15 UTC, Darren wrote: I'm trying to teach myself OpenGL but I'm not sure how to set it up exactly. I used "dub init" to create a project, I downloaded glew32.dll and glfw.dll and put them in this folder. I added "derelict-gl3": "~>1.0.19" and "derelict-glfw3": "~>3.1.0" to dependencies, and imported them in the app.d file. I add the load() and reload() functions where appropriate (I assume). You don't need GLEW. It's a library for C and C++ that loads all of the OpenGL functions and extensions available in the context you create. DerelictGL3 does that for you in D. DerelictGl3.load loads the OpenGL DLL and the functions up to OGL 1.1, and DerelictGL3.reload loads all the functions and extensions available in the current context. I can run a simple window program and it seems to work fine, but I notice that's when all the functions begin with "glfw". Yes, GLFW is a simple windowing toolkit for creating windows & OpenGL contexts and managing window & input events in a cross-platform manner. Without it, you would need to use the system APIs yourself (such as Win32 on Windows) or another cross-platform library like SDL or SFML. If I try to follow a tutorial for loading a triangle, I get errors when trying to build. Do I need to link an opengl.dll file, too? No, you do not need to link to OpenGL. By default, Derelict loads shared libraries at runtime so you will never have a link-time dependency on the C libraries Derelict binds to. Please post the errors you are seeing.
Using OpenGL
I'm trying to teach myself OpenGL but I'm not sure how to set it up exactly. I used "dub init" to create a project, I downloaded glew32.dll and glfw.dll and put them in this folder. I added "derelict-gl3": "~>1.0.19" and "derelict-glfw3": "~>3.1.0" to dependencies, and imported them in the app.d file. I add the load() and reload() functions where appropriate (I assume). I can run a simple window program and it seems to work fine, but I notice that's when all the functions begin with "glfw". If I try to follow a tutorial for loading a triangle, I get errors when trying to build. Do I need to link an opengl.dll file, too?
Re: Hash table element existence check
On 9/2/16 3:38 PM, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. You mean you are writing your own hash table, or you want to use a D hash table (associative array)? I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way? I'm not sure I understand the question. Hash tables have many many many different ways to implement. Obviously, marking empty buckets somehow is necessary. -Steve
Hash table element existence check
I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way?
Re: opAssign return type
On Friday, 2 September 2016 at 17:33:22 UTC, Steven Schveighoffer wrote: On 9/2/16 1:18 PM, Q. Schroll wrote: When overloading assignment, I've been taught in my C++ course to return a reference to the lvalue being assigned to. This is easily possible in D, but in Phobos it is used rarely and in Ali Çehreli's Book it is neither taught to do so. Sure, you can do this. Is there any reason to it? To me it seems very obvious to do it like in C++. I can imagine a reason is to avoid issues with lifetime. It's dangerous to return this as a reference in most cases, because this is implicitly passed by reference even for rvalues. However, for opAssign, you generally are sure you don't have an rvalue. Interestingly the compiler does not allow rvalue = expr but it does however allow rvalue.opAssign(expr). In any case, there's nothing wrong with it technically, it should work. -Steve There is no possibility to enforce some method is only available for lvalue this?
Re: opAssign return type
On 9/2/16 1:18 PM, Q. Schroll wrote: When overloading assignment, I've been taught in my C++ course to return a reference to the lvalue being assigned to. This is easily possible in D, but in Phobos it is used rarely and in Ali Çehreli's Book it is neither taught to do so. Sure, you can do this. Is there any reason to it? To me it seems very obvious to do it like in C++. I can imagine a reason is to avoid issues with lifetime. It's dangerous to return this as a reference in most cases, because this is implicitly passed by reference even for rvalues. However, for opAssign, you generally are sure you don't have an rvalue. In any case, there's nothing wrong with it technically, it should work. -Steve
opAssign return type
When overloading assignment, I've been taught in my C++ course to return a reference to the lvalue being assigned to. This is easily possible in D, but in Phobos it is used rarely and in Ali Çehreli's Book it is neither taught to do so. Is there any reason to it? To me it seems very obvious to do it like in C++. The question came up in the discussion of a PR: https://github.com/dlang/dlang.org/pull/1466
Re: Classes and Structs, Memory management questions
On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote: from what i got Classes are always reference types and structs are value types in D. i am wondering why that is. for me the main difference between classes and structs is not how they are allocated, but that one has inhertiance, and the other hasn't. It depends by language you're using. In C++, for example you can inherit both! The only difference AFAIK is that c++ structs has public default inheritance vs private for classes. Andrea
Re: Equivalent of FirstOrDefault with ranges
On Friday, 2 September 2016 at 06:56:07 UTC, Lutger wrote:
I was looking for something like FirstOrDefault* from .NET in
phobos. For example, I have this piece of code:
string findBobOrReturnNull(string[] names)
{
auto r = names.find("bob");
if(r.empty) return null;
return r.front;
}
assert(findBobOrReturnNull(["alice", "bob"]) == "bob");
assert(findBobOrReturnNull(["alice"]) is null);
How can I turn that into something like this, or is there
another idiomatic way to write it as a single expression?
string findBobOrReturnNull(string[] names)
{
return names.find("bob").firstOrDefault;
}
*
https://msdn.microsoft.com/en-us/library/bb340482%28v=vs.110%29.aspx
ElementType!R firstOrDefault(R)(R r, ElementType!R def =
(ElementType!R).init)
if(isInputRange!R)
{
if(r.empty) return def;
return r.front;
}
Re: Classes and Structs, Memory management questions
On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
from what i got Classes are always reference types and structs
are value types in D. i am wondering why that is. for me the
main difference between classes and structs is not how they are
allocated, but that one has inhertiance, and the other hasn't.
Supporting inheritance has some overhead, so at least the split
between classes and structs makes sense to me.
How instances in an inheritance tree are allocated is actually an
important consideration, particularly when it comes to object
slicing. In C++, this can be a problem:
```
class Foo {};
class Bar : public Foo {};
Bar bar;
Foo foo = bar;
```
All of the information about the type Bar is lost in the
assignment to foo. The same thing is going to happen when passing
bar to a function that takes a Foo by value as a parameter. The
only way to avoid the problem is to pass by reference (or
pointer). In Modern C++, with move semantics being a thing,
passing by value is much more common than it used to be, but this
is the sort of thing it's easy either not to know or to forget
about. In D, you don't have to worry about it.
I read somewhere (in old forum discussions or an old article)
that object slicing is one of the motivations behind the
distinction in D.
Re: Classes and Structs, Memory management questions
On Friday, 2 September 2016 at 08:59:38 UTC, Andrea Fontana wrote:
On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
i haven't read it fully yet, but i think this DIP contains
some or all of my concerns
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Check this:
https://dlang.org/phobos/std_experimental_allocator.html
thx that is very interesting. it seems like that can cover very
complex allocation schemes with a general interface!
i have also found this to allocate a class on the stack
http://dlang.org/phobos/std_typecons.html#.scoped
class A { ... }
auto instance = scoped!A();
that has even quite a nice syntax!
Re: Classes and Structs, Memory management questions
On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote: i haven't read it fully yet, but i think this DIP contains some or all of my concerns https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md Check this: https://dlang.org/phobos/std_experimental_allocator.html
Re: Classes and Structs, Memory management questions
i haven't read it fully yet, but i think this DIP contains some or all of my concerns https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Re: Equivalent of FirstOrDefault with ranges
On Friday, 2 September 2016 at 06:56:07 UTC, Lutger wrote:
You could do:
names.find("bob").chain(only(``)).front;
It's not very expressive though.
Classes and Structs, Memory management questions
from what i got Classes are always reference types and structs
are value types in D. i am wondering why that is. for me the main
difference between classes and structs is not how they are
allocated, but that one has inhertiance, and the other hasn't.
Supporting inheritance has some overhead, so at least the split
between classes and structs makes sense to me.
I like garbage collection, but in many cases it's just
unnecessary (like in the example below) or hurts performance on a
bigger scale.
{
FileReader reader = new // Annoy the garbage collector for
no reason?
auto blob = reader.read();
delete reader;
}
Since garbage collection is a very nice feature that I wouldn't
wanna miss for certain scenarios I think D should give us the
opportunity to determine how an object is allocated. In the
example above putting it on the stack is probably a good idea.
Having a self managed reference to the heap can be good too if
manual memory management is wanted. Or of course let the GC
manage it ( i love it for prototyping code and also as a D
beginner it is beneficial that i just dont need to care about
memory management).
Could somebody explain to me if this is seen as a problem
why/whynot and how I should address that kind of issues in my
code?
Re: DUB, link automatically right object for platform and archi
On Friday, 2 September 2016 at 03:24:58 UTC, rikki cattermole wrote: On 02/09/2016 6:01 AM, Basile B. wrote: [...] What's wrong in my description ? For starters Ouch... buildSettings is just a name given to a group of properties. It doesn't actually go INTO the dub file. Thx much, this explains why the JSON object was missing. dflags is valid in top level config, subPackage and of course configuration.
Equivalent of FirstOrDefault with ranges
I was looking for something like FirstOrDefault* from .NET in
phobos. For example, I have this piece of code:
string findBobOrReturnNull(string[] names)
{
auto r = names.find("bob");
if(r.empty) return null;
return r.front;
}
assert(findBobOrReturnNull(["alice", "bob"]) == "bob");
assert(findBobOrReturnNull(["alice"]) is null);
How can I turn that into something like this, or is there another
idiomatic way to write it as a single expression?
string findBobOrReturnNull(string[] names)
{
return names.find("bob").firstOrDefault;
}
*
https://msdn.microsoft.com/en-us/library/bb340482%28v=vs.110%29.aspx
Re: Different array rotation algorithms benchmark
On Thursday, 1 September 2016 at 13:16:19 UTC, Johan Engelen wrote: On Thursday, 1 September 2016 at 10:37:18 UTC, Miguel L wrote: Also, forgot to specify I am using LDC with -05. And the version of LDC too please ;-) LDC version is: ldc2-1.1.0-beta2-win64-msvc
