Delay allocating class instance in stack.
Hello! I read documentation about memory management and can't
find description about delay allocation of instance. I have a
method marked by @nogc. This method takes boolean variable. If
this variable is true I want to construct object with one set of
parameters else I want to construct object with another set of
parameters. Take a look at code for clearance.
void method(bool flag) @nogc
{
scope MyClass obj;
if(flag) {
obj = new MyClass(1);
} else {
obj = new MyClass(2);
}
// using obj
}
But this code CAN'T be compiled. How should I declare object for
delay construction.
Thanks.
Re: Delay allocating class instance in stack.
You probably want[0] to allocate a class on the stack instead of doing this. [0] http://dlang.org/phobos/std_typecons.html#.scoped
Re: Delay allocating class instance in stack.
On Tuesday, 21 March 2017 at 08:12:36 UTC, rikki cattermole wrote: You probably want[0] to allocate a class on the stack instead of doing this. [0] http://dlang.org/phobos/std_typecons.html#.scoped If I will use it I won't use @nogc. Is the only one case?
Re: Delay allocating class instance in stack.
On 03/21/2017 01:08 AM, ANtlord wrote:
void method(bool flag) @nogc
{
scope MyClass obj;
if(flag) {
obj = new MyClass(1);
} else {
obj = new MyClass(2);
}
// using obj
}
Another option is std.conv.emplace:
import std.conv : emplace;
class MyClass {
this(int) @nogc {
}
~this() @nogc {
}
}
void method(bool flag) @nogc
{
void[__traits(classInstanceSize, MyClass)] buffer = void;
MyClass obj;
if(flag) {
obj = emplace!MyClass(buffer, 1);
} else {
obj = emplace!MyClass(buffer, 2);
}
// Unfortunately, destroy() is not @nogc
// scope(exit) destroy(obj);
}
void main() {
method(false);
method(true);
}
Ali
Re: Any full-text search library
On Friday, 3 February 2017 at 14:30:01 UTC, Soolayman wrote: Is there any usable full-text search library? for D I couldn't find any except the Elasticsearch client called elasticsearch-d in the package registry a very old Lucene port for D1 called dlucene. This is it or did I miss something? Hi I have started to work on one about a week ago. I will give you a github link once I am in alpha phase, I guess about 1-2 months as I have daytime work as well. The work is based on Lucene 6 but I am trying to use standard D language techniques, etc.
Re: Delay allocating class instance in stack.
On Tuesday, 21 March 2017 at 08:08:24 UTC, ANtlord wrote:
Hello! I read documentation about memory management and can't
find description about delay allocation of instance. I have a
method marked by @nogc. This method takes boolean variable. If
this variable is true I want to construct object with one set
of parameters else I want to construct object with another set
of parameters. Take a look at code for clearance.
void method(bool flag) @nogc
{
scope MyClass obj;
if(flag) {
obj = new MyClass(1);
} else {
obj = new MyClass(2);
}
// using obj
}
But this code CAN'T be compiled. How should I declare object
for delay construction.
Thanks.
Try scope obj = new MyClass(flag ? 1 : 2);
In essence you should never need to delay construction.
Just construct the object as soon as you have everything to
construct it.
which includes conditions.
Derelict SDL segfaulting on ubuntu?
I've been working on a small game of tic tac toe using Derelict SDL, and development has been going along great... Until I tried to develop on my Ubuntu laptop. I uploaded the code to github, downloaded it on my laptop, installed the prequesites and... The program crashed with error -11 -- a segmentation fault. Two days of fix attempt laters, here I am. I tried reinstalling and recompiling SDL from source (since the version from apt-get was only 2.0.4 and the one Derelict uses seems to be 2.0.5), and it continues segfaulting at seemingly random places. I have a function which fills the screen with black using SDL_FillRect... Then, this same function calls another helper function... Which segfaults, at SDL_FillRect. That is, the same function is both working and crashing, when given the exact same arguments, just in different contexts. And I have no idea why. I'll put a link to the repo. It is a slightly more updated version than the one I've been trying to compile, but it segfaults anyway. I'm continuing to develop just fine on Windows, but Derelict on Ubuntu has proven to be a nightmare. TL;DR: Same code runs on Windows but not Ubuntu, tried to update and recompile all I could, segmentation faults on seemingly random places. http://www.github.com/robly18/sdltest/
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: I've been working on a small game of tic tac toe using Derelict SDL, and development has been going along great... Until I tried to develop on my Ubuntu laptop. [...] Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote: On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: I've been working on a small game of tic tac toe using Derelict SDL, and development has been going along great... Until I tried to develop on my Ubuntu laptop. [...] Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu Wow, I wasn't expecting such a swift response! Unfortunately, this seems not to have worked. I did the change you told me to on dub.json, did dub upgrade and dub --force, and... Nothing, still segfaulted. I had to comment out some lines, such as SDL_PointInRect, but it still segfaults at SDL_FillRect.
Re: Derelict SDL segfaulting on ubuntu?
21.03.2017 16:04, Robly18 пишет: On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote: On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: I've been working on a small game of tic tac toe using Derelict SDL, and development has been going along great... Until I tried to develop on my Ubuntu laptop. [...] Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu Wow, I wasn't expecting such a swift response! Unfortunately, this seems not to have worked. I did the change you told me to on dub.json, did dub upgrade and dub --force, and... Nothing, still segfaulted. I had to comment out some lines, such as SDL_PointInRect, but it still segfaults at SDL_FillRect. wrong version of derelict-sdl2 may be in dub.selection.json. check it too.
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 13:04:29 UTC, Robly18 wrote: On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote: On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: I've been working on a small game of tic tac toe using Derelict SDL, and development has been going along great... Until I tried to develop on my Ubuntu laptop. [...] Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu Wow, I wasn't expecting such a swift response! Unfortunately, this seems not to have worked. I did the change you told me to on dub.json, did dub upgrade and dub --force, and... Nothing, still segfaulted. I had to comment out some lines, such as SDL_PointInRect, but it still segfaults at SDL_FillRect. Hm on my machine with ArchLinux the project runs fine, do you have both libsdl2-2.0 and libsdl2-dev installed? Try running it with gdb and post the backtrace (bt) + error messages in here when it segfaults
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: Two days of fix attempt laters, here I am. I tried reinstalling and recompiling SDL from source (since the version from apt-get was only 2.0.4 and the one Derelict uses seems to be 2.0.5), and it continues segfaulting at seemingly random places. Mismatched versions wouldn't be causing a segfault out of the box. You'd be getting exceptions instead. The only way Derelict would be the cause of the segfault is if one of the function pointers is null or one of the function declarations has the wrong signature. This isn't related to your problem, but beginning with DerelictSDL2 2.0, you can specify the version of SDL you'd like to target, like say 2.0.2: import derelict.sdl2.sdl; DerelictSDL2.load(SharedLibVersion(2, 0, 2)); With this, the loader will not throw any exceptions unless the library version is lower than the one requested. In that case, there is a potential to see segfaults. For example, you request at least 2.0.2, the user has 2.0.4, but the binding supports 2.0.5. The 2.0.5 functions will never be loaded, so the function pointers will be null. If I ever get around to finishing up the documentation, it will recommend that you always specify the version you actually want and do not attempt to call any functions from later versions unless you have a good reason to do so, but always check for null first. I have a function which fills the screen with black using SDL_FillRect... Then, this same function calls another helper function... Which segfaults, at SDL_FillRect. That is, the same function is both working and crashing, when given the exact same arguments, just in different contexts. And I have no idea why. Looking over your code, I see you aren't doing any error checking. Validate all of your return values and call SDL_GetError when one of them shows an error (in SDL, that's either null or a number < 0, depending on the function). Add some asserts or debug code to check the state of the pointers you're passing to SDL functions. Given that the program works elsewhere, I wouldn't expect this to show the issue, but it's still something you should be doing anyway. I'll put a link to the repo. It is a slightly more updated version than the one I've been trying to compile, but it segfaults anyway. I'm continuing to develop just fine on Windows, but Derelict on Ubuntu has proven to be a nightmare. Derelict has worked on Ubuntu for years. It doesn't do anything special there that it doesn't do on Windows. I'm not able to check it at the moment, but I have an Ubuntu laptop I'll try your code on when I get the chance (if you don't resolve the issue first). TL;DR: Same code runs on Windows but not Ubuntu, tried to update and recompile all I could, segmentation faults on seemingly random places. http://www.github.com/robly18/sdltest/
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote: On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: I've been working on a small game of tic tac toe using Derelict SDL, and development has been going along great... Until I tried to develop on my Ubuntu laptop. [...] Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu See the bit in my reply to the OP about SharedLibVersion. You really shouldn't be using the 1.9 series -- that was the 2.0 beta. 2.0.x supports up to 2.0.4 by default, 2.1.x supports 2.0.5 by default, but both can load older versions just fine using SharedLibVersion. Also, I've been trying to get in touch with you to discuss workspace-d, but the email keeps bouncing! If you don't mind, please send me a message at aldac...@gmail.com.
Re: Issue with typeof
On 03/20/2017 05:55 PM, StarGrazer wrote:
typeof(&method) fails unless method is static. Says & requires this.
Works for me:
class C
{
void method() {}
typeof(&method) x;
}
typeof(&C.method) y;
Tested with dmd 2.073.2.
Note that the type of x and y is `void function()`, not `void
delegate()`. That's quite awful. In my opinion, `&method` shouldn't work
like this, but it does.
But for typeof, it shouldn't matter and should pass.
I disagree. `typeof(foo)` should only work when `foo` works. And
`&method` shouldn't work when there's no `this`.
So how to get a function pointer to a non static member function(of an
interface)?
I've tried creating the type like
T t;
typeof(&t.method) fptr;
but same issue. It may be because T is an interface, but again, it
shouldn't matter. I just want the function pointer declaration.
Works with an interface, too:
interface T { void method(); }
T t;
typeof(&t.method) fptr1;
typeof(&T.method) fptr2;
Here, fptr1 has type `void delegate()` which is ok, but fptr2 has type
`void function()` which is pretty bad. So, what you tried compiles for
me and should work.
To keep it more hygienic, you can put the `T t;` and `typeof(&t.method)`
in an immediately called function literal:
typeof(() { T t; return &t.method; } ()) fptr3;
e.g., `void function();` for `void foo();`
Really should be `void delegate()`. With the `function` type you're
losing the `this` pointer.
Re: Issue with typeof
On Tuesday, 21 March 2017 at 15:01:43 UTC, ag0aep6g wrote:
On 03/20/2017 05:55 PM, StarGrazer wrote:
typeof(&method) fails unless method is static. Says & requires
this.
Works for me:
class C
{
void method() {}
typeof(&method) x;
}
typeof(&C.method) y;
Tested with dmd 2.073.2.
Yes, but you changed it. I didn't have C. Initially this wasn't a
problem.
typeof(() { T t; return &t.method; } ()) fptr3;
e.g., `void function();` for `void foo();`
Really should be `void delegate()`. With the `function` type
you're losing the `this` pointer.
You are making assumptions... my functions where static and I was
trying to convert them to non-static methods and this is where
the trouble started creeping in.
Re: Issue with typeof
On 03/21/2017 04:09 PM, StarGrazer wrote:
On Tuesday, 21 March 2017 at 15:01:43 UTC, ag0aep6g wrote:
On 03/20/2017 05:55 PM, StarGrazer wrote:
typeof(&method) fails unless method is static. Says & requires this.
Works for me:
class C
{
void method() {}
typeof(&method) x;
}
typeof(&C.method) y;
Tested with dmd 2.073.2.
Yes, but you changed it. I didn't have C. Initially this wasn't a problem.
I just filled the blanks you left. Note that my snippet still includes
`typeof(&method)` verbatim. The added `typeof(&C.method)` is just bonus.
If you have code that fails unexpectedly, please feel free to post it.
[...]
You are making assumptions... my functions where static and I was trying
to convert them to non-static methods and this is where the trouble
started creeping in.
Going from static to non-static means going from `function` to
`delegate`. I don't think there's a way around that. You can get a
`function` type from a method, but it won't be useful with actual methods.
Re: bug in foreach continue
On Friday, 17 March 2017 at 19:05:20 UTC, H. S. Teoh wrote: There are actually (at least) TWO distinct phases of compilation that are conventionally labelled "compile time": 1) Template expansion / AST manipulation, and: 2) CTFE (compile-time function evaluation). [ ... ] Template expansion / AST manipulation must be completed *before* CTFE can run. Only the templates that the ctfe relies on. [ ... ] This is because it makes no sense to generate code on an incomplete / partial AST. This is not exactly true whenever you use ctfe to generate a source string that you later mix-in. You are working with a partial ast. Furthermore, once a piece of code has made it to the CTFE stage, its AST has already been processed, and it's now compiled into an internal representation (analogous to bytecode), so AST-manipulating constructs no longer make any sense. Yes. In the CTFE stage, there is no such thing as an AST anymore. There is an AST. It's just already processed.
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 14:21:30 UTC, Mike Parker wrote: On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote: Two days of fix attempt laters, here I am. I tried reinstalling and recompiling SDL from source (since the version from apt-get was only 2.0.4 and the one Derelict uses seems to be 2.0.5), and it continues segfaulting at seemingly random places. Mismatched versions wouldn't be causing a segfault out of the box. You'd be getting exceptions instead. The only way Derelict would be the cause of the segfault is if one of the function pointers is null or one of the function declarations has the wrong signature. Oh! Right, I forgot to mention that, my bad. The earliest errors were, as you said, mismatched version exceptions. However, to fix them, what I did was, at first, do the 2,0,2 version thing you said. Later, however, I decided to compile SDL 2.0.5 myself, and I believe the exceptions stopped occurring. The segfaults, however, did not. Looking over your code, I see you aren't doing any error checking. Validate all of your return values and call SDL_GetError when one of them shows an error (in SDL, that's either null or a number < 0, depending on the function). Add some asserts or debug code to check the state of the pointers you're passing to SDL functions. Given that the program works elsewhere, I wouldn't expect this to show the issue, but it's still something you should be doing anyway. Just filled my code with asserts, and nothing. That doesn't seem to be it. You said something about null function pointers... Is this something I should be checking for? I know when I did the version downgrade I got dub complaining about some undefined functions, but should I be on the lookout for more? Thanks in advance.
questions about dub
Hi, I have questions regarding the usage of 'dub'. I'm learning D under Win7. I have installed VisualD for the community edition of Visual Studio and got some file i/o working. Next I would like to continue with the mir-tools for matrix manipulation. I understood that I have to build them first using dub. But I didn't succeed: C:\..\AppData\Roaming\dub>dub fetch mir-algorithm Fetching mir-algorithm 0.1.1... Please note that you need to use `dub run ` or add it to dependencies of your package to actually use/run it. dub does not do actual installation of packages outside of its own ecosystem. C:\..\AppData\Roaming\dub>dub run mir-algorithm Building package mir-algorithm in C:\..\AppData\Roaming\dub\packages\mir-algorithm-0.1.1\mir-algorithm\ Fetching mir-internal 0.0.5 (getting selected version)... Main package must have a binary target type, not sourceLibrary. Cannot build. Thats where I stuck. Beside my specific problem of how to start with the mir-tools I wonder how and for what purpose 'dub' is applied when building projects in connection with Visual Studio? Or is it just a more light-weight command line build tool? Thanks for shedding some light! Thorstein
Re: questions about dub
On Tuesday, 21 March 2017 at 21:01:31 UTC, thorstein wrote: Hi, I have questions regarding the usage of 'dub'. I'm learning D under Win7. I have installed VisualD for the community edition of Visual Studio and got some file i/o working. Next I would like to continue with the mir-tools for matrix manipulation. I understood that I have to build them first using dub. But I didn't succeed: C:\..\AppData\Roaming\dub>dub fetch mir-algorithm Fetching mir-algorithm 0.1.1... Please note that you need to use `dub run ` or add it to dependencies of your package to actually use/run it. dub does not do actual installation of packages outside of its own ecosystem. C:\..\AppData\Roaming\dub>dub run mir-algorithm Building package mir-algorithm in C:\..\AppData\Roaming\dub\packages\mir-algorithm-0.1.1\mir-algorithm\ Fetching mir-internal 0.0.5 (getting selected version)... Main package must have a binary target type, not sourceLibrary. Cannot build. Thats where I stuck. Beside my specific problem of how to start with the mir-tools I wonder how and for what purpose 'dub' is applied when building projects in connection with Visual Studio? Or is it just a more light-weight command line build tool? Thanks for shedding some light! Thorstein Generally if your dub.json or dub.sdl is configured correctly then all you need is to run "dub build" which will invoke package fetching etc. and then your desired compiler. Dependencies are defined in dub.json / dub.sdl using "dependencies" which takes values as "packagename" and then "version". Example: "vibe-d" "~>0.7.28" I don't know if that helps. I'm not familiar with Visual-D and don't use it at all, so I don't know if dub has to be used in specific ways. I compile though command line only, so.
Re: questions about dub
On Tuesday, 21 March 2017 at 21:01:31 UTC, thorstein wrote: C:\..\AppData\Roaming\dub>dub run mir-algorithm Building package mir-algorithm in C:\..\AppData\Roaming\dub\packages\mir-algorithm-0.1.1\mir-algorithm\ Fetching mir-internal 0.0.5 (getting selected version)... Main package must have a binary target type, not sourceLibrary. Cannot build. Thats where I stuck. mir is a library, not a program, and dub handles this dependency (and its dependencies) for you if you are going to use it in your program. Check out the official mir docs about how to get up & running with dub: https://github.com/libmir/mir#fast-setup-with-the-dub-package-manager
Re: questions about dub
On Tuesday, 21 March 2017 at 21:01:31 UTC, thorstein wrote: Beside my specific problem of how to start with the mir-tools I wonder how and for what purpose 'dub' is applied when building projects in connection with Visual Studio? Or is it just a more light-weight command line build tool? Thanks for shedding some light! Thorstein Hello Thorstein, actually mir-algorithm is a library, and can't be run. A good entry point for dub is https://code.dlang.org/getting_started The overall workflow of dub is something like: 1. Create your own project in a empty folder ( dub init ... ) (this will generate several files) 2. Add your dependencies to "dub.json" (https://code.dlang.org/package-format?lang=json) or "dub.sdl" (https://code.dlang.org/package-format?lang=sdl) Yes, there exist two equivalent file formats that dub can understand. But you don't have to remember the whole syntax to add a few dependencies. The package homepages contain simple snippets you can simply copy/paste into your dub.json or dub.sdl file https://code.dlang.org/packages/mir-algorithm 3. Write code... :) To build and run your application, execute "dub" in the folder where the dub.json / dub.sdl file is located Dub manages downloading the dependencies and building the right version of them.. Very handy! If you want to develop with visual-d you can generate a visual-d project file out of your dub project... ( dub generate visuald ) ~togrue
Re: questions about dub
Thanks to all, I got it! I created a new dub package and copied my code there. Compiles. So I guess I get the rest working as well. Still will have to figure out later the procedure to do the same for a VisualD project, if it is possible. Thorstein
Re: Derelict SDL segfaulting on ubuntu?
On Tuesday, 21 March 2017 at 19:26:47 UTC, Robly18 wrote: Oh! Right, I forgot to mention that, my bad. The earliest errors were, as you said, mismatched version exceptions. However, to fix them, what I did was, at first, do the 2,0,2 version thing you said. Later, however, I decided to compile SDL 2.0.5 myself, and I believe the exceptions stopped occurring. The segfaults, however, did not. When you compiled SDL 2.0.5, did you also install it? The Derelict loader will load the shared library from the system path, so if you didn't redirect the symlink on the system path from the old library to your newer one, then the Derelict would still be loading the old one. And then if you're calling any 2.0.5 functions, they wouldn't be loaded so you'd see the segfault. You said something about null function pointers... Is this something I should be checking for? Not generally, no. However, if you are specifying one version as the minimum you require, then using functions from a later version, then yes. Example: You call DerelictSDL2.load(SharedLibVersion(2,0,2)). Then later in your code, you have a call to SDL_GetWindowBorderSize. This is a function that was added in SDL 2.0.5. If you run your program on a system that has SDL 2.0.5, then no problem. But you requested 2.0.2 as a minimum, so your program will still load successfully with no exceptions if the user has SDL 2.0.2, 2.0.3, or 2.0.4. But in all three of those cases, SDL_GetWindowBorderSize will never be loaded, so it will be null when you call it and you will get a segfault. If you truly want to use that function only if it's available, then you need to check for null first (or call SDL_GetVersion to see which version si actually loaded). It's like checking if an extension is loaded in OpenGL. But that kind of usage is rare with SDL, and *I strongly recommend against it*. Generally if you need functions from a specific version, then that should be the minimum version you request. DerelictSDL2 2.1.x will load SDL 2.0.5 by default when no SharedLibVersion is specified. So if you need any function from 2.0.5, then just use the default. However, that means the user will need 2.0.5 on their system and anything lower will cause an exception to be thrown during load. I know when I did the version downgrade I got dub complaining about some undefined functions, but should I be on the lookout for more? That's the compiler complaining, not dub. DerelictSDL2 2.0.x (and 1.9.x, since that was 2.0 beta) supports up to SDL 2.0.4. No functions from SDL 2.0.5 are declared anywhere. So given what I know so far, my guess is you're using functions from 2.0.5 with a 2.0.4 version of the library. You can call SDL_GetVersion [1] to verify. In that case, you need to use DerelictSDL2 2.1.x and do no use SharedLibVersion -- just let it load the default. http://wiki.libsdl.org/SDL_GetVersion?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29
Re: questions about dub
On Tuesday, 21 March 2017 at 22:51:41 UTC, thorstein wrote: Thanks to all, I got it! I created a new dub package and copied my code there. Compiles. So I guess I get the rest working as well. Still will have to figure out later the procedure to do the same for a VisualD project, if it is possible. Thorstein As togrue said, you can generate a VisualD project from the dub project you created. Normally, you could also just run 'dub build' on any library that has a dub package and copy the resulting binary to a place where you can configure VisualD to find it (and do that for debug/release builds and, if you need both, 32-/64-bit). Unfortunately, mir-algorithm has a target type of "sourceLibrary". It needs to be "library", "staticLibrary", or "dynamicLibrary", in order to build by itself. Using "sourceLibrary" means it can only be built as a dependency to another project. BTW, here's a tip: dub fetch --cache=local mir-algorithm Using --cache=local will put the package in the current directory instead of the AppData path. When you aren't using dub to manage your own projects, that makes it easier to deal with (e.g. cd C:\dev\dub\package-name). You can cd to the package's root directory and run dub build, then add the path to the resultant library to your IDE, or copy the library to a common path.
Re: questions about dub
On Wednesday, 22 March 2017 at 04:06:50 UTC, Mike Parker wrote: dub fetch --cache=local mir-algorithm Using --cache=local will put the package in the current directory instead of the AppData path. When you aren't using dub to manage your own projects, that makes it easier to deal with (e.g. cd C:\dev\dub\package-name). You can cd to the package's root directory and run dub build, then add the path to the resultant library to your IDE, or copy the library to a common path. Sorry, forgot to mention. With this approach, you also have to build any dependencies and link them in. And you'll want to specify where to find the dependencies if they aren't in the global cache. I have examples of doing this in the Derelict documentation: http://derelictorg.github.io/building/without-dub/
Re: Delay allocating class instance in stack.
On Tuesday, 21 March 2017 at 08:46:43 UTC, Ali Çehreli wrote:
Another option is std.conv.emplace:
import std.conv : emplace;
class MyClass {
this(int) @nogc {
}
~this() @nogc {
}
}
void method(bool flag) @nogc
{
void[__traits(classInstanceSize, MyClass)] buffer = void;
MyClass obj;
if(flag) {
obj = emplace!MyClass(buffer, 1);
} else {
obj = emplace!MyClass(buffer, 2);
}
// Unfortunately, destroy() is not @nogc
// scope(exit) destroy(obj);
Thank you for clarification. But I have one more question. Do I
have to use destroy for deallocating object from stack?
Re: Delay allocating class instance in stack.
On Tuesday, 21 March 2017 at 12:30:57 UTC, Stefan Koch wrote: Try scope obj = new MyClass(flag ? 1 : 2); In essence you should never need to delay construction. Just construct the object as soon as you have everything to construct it. which includes conditions. Yes I know it. I prepare all input variables before construction of object usually. I just want to know possibilty of the case described above.
Re: questions about dub
Ups, somehow overread the last sentence of tourge :) Thanks for the detailed insights!
Re: GDC options
On Monday, 13 March 2017 at 11:06:53 UTC, Russel Winder wrote: It is a shame that dmd and ldc do not just use the standard GCC option set. Totally agreed. Moreover, funny stuff like "dmd -of" (instead of standard "-o ") breaks automatic Msys path conversion hack (the code translates Unix paths from the command line to Windows paths before the invocation of a non-msys program), which makes it impossible to use dmd under Msys without wrapping it first. pkg-config also is a real pain to use with dmd (the pkg-config's output needs to be post-processed so it has the form "-L-lstuff" instead of "-lstuff"). This is an issue, because it makes it very hard to use write portable makefiles for programs containing D code. Too bad, because the D code is actually platform-independent, and there's been a lot of work in Phobos to make it easy to write such code. D was designed to be binary compatible with the C ABI ; however, having a compiler whose command-line behaves so different from gcc makes it harder to actually work with existing C libs. This is actually the main reason why I almost exclusively use gdc: to have one Makefile, for all platforms, allowing native and cross-compilation with no platform-specific special cases.
Re: Delay allocating class instance in stack.
On 03/21/2017 09:57 PM, ANtlord wrote:
> On Tuesday, 21 March 2017 at 08:46:43 UTC, Ali Çehreli wrote:
>> Another option is std.conv.emplace:
>>
>> import std.conv : emplace;
>>
>> class MyClass {
>> this(int) @nogc {
>> }
>>
>> ~this() @nogc {
>> }
>> }
>>
>> void method(bool flag) @nogc
>> {
>> void[__traits(classInstanceSize, MyClass)] buffer = void;
>> MyClass obj;
>>
>> if(flag) {
>> obj = emplace!MyClass(buffer, 1);
>> } else {
>> obj = emplace!MyClass(buffer, 2);
>> }
>>
>> // Unfortunately, destroy() is not @nogc
>> // scope(exit) destroy(obj);
>
> Thank you for clarification. But I have one more question. Do I have to
> use destroy for deallocating object from stack?
Yes because what is going out of scope are two things:
- A buffer
- A MyClass reference
Neither of those have destructors. (emplace is just a library function
that does something with that buffer but the compiler cannot know that
there is an object that we want destructed.)
Here is a hack that defines a destroyNoGC() that allows one to call the
destructor is a @nogc context:
import std.stdio;
import std.conv : emplace;
class MyClass {
this(int) @nogc {
}
~this() @nogc {
printf("~this\n");
}
}
// Adapted from std.traits.SetFunctionAttributes documentation
import std.traits;
auto assumeNoGC(T)(T t)
if (isFunctionPointer!T || isDelegate!T)
{
enum attrs = functionAttributes!T | FunctionAttribute.nogc;
return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
}
@nogc void function(Object) destroyNoGC;
static this() {
destroyNoGC = assumeNoGC((Object obj) {
destroy(obj);
});
}
void method(bool flag) @nogc
{
void[__traits(classInstanceSize, MyClass)] buffer = void;
MyClass obj;
if(flag) {
obj = emplace!MyClass(buffer, 1);
} else {
obj = emplace!MyClass(buffer, 2);
}
scope(exit) {
destroyNoGC(obj);
}
}
void main() {
method(false);
method(true);
}
Gotta love D for allowing such code but it comes with surprises. Why do
we suddenly get two destructor calls?
~this
~this
Ali
Re: Delay allocating class instance in stack.
On 03/21/2017 11:47 PM, Ali Çehreli wrote: > method(false); > method(true); > } > > Gotta love D for allowing such code but it comes with surprises. Why do > we suddenly get two destructor calls? > > ~this > ~this Answering own question: There are two destructor calls because I call method() twice. Ali
