Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 02:54:47 UTC, Joe wrote: Now I fixed this by changing the import to core.stdc.stdio. I guess the problem is if you import std.stdio (which brings in the other one), there are two slightly incompatible stdout's and the D takes precedence. If you import both modules (or even I think if just the D std.stdio, since it publicly imports the other), you can specify the C one by using its full name: core.stdc.stdio.stdout where you use it. of course you can also alias it to something shorter.
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 02:16:00 UTC, Seb wrote:
Hmm, calling e.g. fprintf with stdout should just work:
---
void main()
{
import core.stdc.stdio;
fprintf(stdout, "Hello %s", "world".ptr);
}
---
Could you maybe provide your whole code?
This short test program shows the error:
---
import std.stdio;
void main()
{
extern (C) void list(FILE *fd);
list(stdout);
}
---
Now I fixed this by changing the import to core.stdc.stdio. I
guess the problem is if you import std.stdio (which brings in the
other one), there are two slightly incompatible stdout's and the
D takes precedence.
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 02:08:11 UTC, Joe wrote:
On Wednesday, 4 July 2018 at 01:58:15 UTC, Seb wrote:
So just add the declaration to your D file:
---
extern(C) void myCfunction(FILE* stream);
---
I do have a similar declaration in D. It appears the problem
is that the C program I'm trying to convert passes stdout as
the argument and the D compiler complains somewhat like the
following:
Error: function foo.main.myCfunction (shared(_IO_FILE)* stream)
is not callable using argument types (File)
So I guess the question is what to pass instead of stdout.
Hmm, calling e.g. fprintf with stdout should just work:
---
void main()
{
import core.stdc.stdio;
fprintf(stdout, "Hello %s", "world".ptr);
}
---
Could you maybe provide your whole code?
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 01:58:15 UTC, Seb wrote: So just add the declaration to your D file: --- extern(C) void myCfunction(FILE* stream); --- I do have a similar declaration in D. It appears the problem is that the C program I'm trying to convert passes stdout as the argument and the D compiler complains somewhat like the following: Error: function foo.main.myCfunction (shared(_IO_FILE)* stream) is not callable using argument types (File) So I guess the question is what to pass instead of stdout.
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 01:06:36 UTC, Joe wrote:
The subject basically says it all. The C function uses the
argument to call fprintf and also passes it to other functions
where it's used to call fileno, fprintf or putc.
Like you would with C's fprintf
(https://dlang.org/phobos/core_stdc_stdio.html#.fprintf).
For example, this is a valid D program:
---
void main(string[] args)
{
import core.stdc.stdio;
FILE* pFile;
int n;
char[100] name;
pFile = fopen ("myfile.txt","w"); // string literals are
zero-terminated
for (n=0 ; n<3 ; n++)
{
puts("please, enter a name: ");
gets(name.ptr);
fprintf pFile, "Name %d [%-10.10s]\n",n+1,name.ptr);
}
fclose(pFile);
}
---
(example from http://www.cplusplus.com/reference/cstdio/fprintf)
So just add the declaration to your D file:
---
extern(C) void myCfunction(FILE* stream);
---
and as long as you link your program into the D binary, you
should be good to go.
For larger C bases, tools like dstep or dpp can help translating
C/C++ header files to D.
How to call a C function from D that takes a FILE * as an argument?
The subject basically says it all. The C function uses the argument to call fprintf and also passes it to other functions where it's used to call fileno, fprintf or putc.
Re: Help using lubeck on Windows
On Wednesday, 4 July 2018 at 00:23:36 UTC, 9il wrote: On Sunday, 25 February 2018 at 14:26:24 UTC, Arredondo wrote: On Friday, 23 February 2018 at 18:29:09 UTC, Ilya Yaroshenko wrote: [...] It is not working my friend. I've been at this for nearly two full days now. All the .lib/.a files I have tried for BLAS and LAPACK just fail to link, including those from openblas.net. rdmd insists on: Error 42: Symbol Undefined _cblas_dgemm Error 42: Symbol Undefined _cblas_dger Error: linker exited with status 2 Am I missing something? Thank you. CBLAS. Lubeck uses its API. Intel MKL do have it. Just pick required libs (there multiple variants plus core and thread libs). Openblas also has cblas api, but it may need explicitly included into the project. See its command line config param.
Re: Help using lubeck on Windows
On Sunday, 25 February 2018 at 14:26:24 UTC, Arredondo wrote: On Friday, 23 February 2018 at 18:29:09 UTC, Ilya Yaroshenko wrote: openblas.net contains precompiled openblas library for Windows. It may not be optimised well for exactly your CPU but it is fast enought to start. Put the library files into your prodject and add openblas library to your project dub configuration. A .dll files are dinamic, you need also a .lib /.a to link with. OpenBLAS contains both cblas and lapack api by default. We defenetely need to add an example for Windows Best Ilya It is not working my friend. I've been at this for nearly two full days now. All the .lib/.a files I have tried for BLAS and LAPACK just fail to link, including those from openblas.net. rdmd insists on: Error 42: Symbol Undefined _cblas_dgemm Error 42: Symbol Undefined _cblas_dger Error: linker exited with status 2 Am I missing something? Thank you. CBLAS. Lubeck uses its API. Intel MKL do have it. Just pick required libs (there multiple variants plus core and thread libs).
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote: BTW in case someone has a bit of time to look at the MinGW headers. They are built as part of the `build-mingw-libs` branch at the installer repo: https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat This is automated via AppVeyor: https://github.com/dlang/installer/blob/build-mingw-libs/appveyor.yml And it's added to the zip here: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L505 I think the installer detects whether Visual Studio is installed or nor, but I'm not sure on this (I don't use Windows). AFAICT, the issue is that MinGW is used, as opposed to MinGW-w64 (a confusingly separate project unfortunately AFAIK). There's no SetWindowLongPtr for Win32, it's #defined as SetWindowLong. The 64-bit user32.def of MinGW-w64 contains it [1], while it's missing in the MinGW .def file [3] and the 32-bit MinGW-w64 one [2]. [1] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib64/user32.def [2] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib32/user32.def [3] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/w32api/lib/user32.def
Re: Issues with undefined symbols when using Vibe on Windows
On 04/07/2018 6:24 AM, Chris M. wrote: Looks like there's a user32.def file in the src package that does not have these two functions defined. Not too sure how this vcvars64.bat file builds the 64-bit libraries from this, but I think I'll have to open a ticket with the mingw devs to have them be added (or see if they have a good explanation). Those files are for 32bit only. See[0] for 64bit versions under the directory mingw-w64-crt/lib64. [0] https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v5.0.4.zip/download
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 18:24:47 UTC, Chris M. wrote: On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote: [...] https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-5.0.2/ Looks like there's a user32.def file in the src package that does not have these two functions defined. Not too sure how this vcvars64.bat file builds the 64-bit libraries from this, but I think I'll have to open a ticket with the mingw devs to have them be added (or see if they have a good explanation). Sorry, looks buildsdk.d does the actual building, not vcvars64.bat
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote: On Tuesday, 3 July 2018 at 15:10:34 UTC, Chris M. wrote: On Tuesday, 3 July 2018 at 14:38:53 UTC, Mike Parker wrote: On Tuesday, 3 July 2018 at 13:32:21 UTC, Chris M. wrote: After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions. https://issues.dlang.org/show_bug.cgi?id=19051 So are the mingw libs only shipped in the zip file? I don't have them with the installer version of 2.080.0, nor lld for that matter. But I see them in the zip for the 2.081.0 RC. Seems to be an option in the 2.080.1 installer (which I ignored before since I wasn't entirely sure how things worked on Windows), not sure about previous versions though. BTW in case someone has a bit of time to look at the MinGW headers. They are built as part of the `build-mingw-libs` branch at the installer repo: https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat This is automated via AppVeyor: https://github.com/dlang/installer/blob/build-mingw-libs/appveyor.yml And it's added to the zip here: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L505 I think the installer detects whether Visual Studio is installed or nor, but I'm not sure on this (I don't use Windows). https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-5.0.2/ Looks like there's a user32.def file in the src package that does not have these two functions defined. Not too sure how this vcvars64.bat file builds the 64-bit libraries from this, but I think I'll have to open a ticket with the mingw devs to have them be added (or see if they have a good explanation).
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 15:10:34 UTC, Chris M. wrote: On Tuesday, 3 July 2018 at 14:38:53 UTC, Mike Parker wrote: On Tuesday, 3 July 2018 at 13:32:21 UTC, Chris M. wrote: After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions. https://issues.dlang.org/show_bug.cgi?id=19051 So are the mingw libs only shipped in the zip file? I don't have them with the installer version of 2.080.0, nor lld for that matter. But I see them in the zip for the 2.081.0 RC. Seems to be an option in the 2.080.1 installer (which I ignored before since I wasn't entirely sure how things worked on Windows), not sure about previous versions though. BTW in case someone has a bit of time to look at the MinGW headers. They are built as part of the `build-mingw-libs` branch at the installer repo: https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat This is automated via AppVeyor: https://github.com/dlang/installer/blob/build-mingw-libs/appveyor.yml And it's added to the zip here: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L505 I think the installer detects whether Visual Studio is installed or nor, but I'm not sure on this (I don't use Windows).
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 15:06:28 UTC, Mike Parker wrote: .. That said, the GC in D runs when main exits anyway, so the destructor in your example will be called. That's why I warned earlier about it being nondeterministic. For example, if you have a Texture instance that depends on the context of the RenderWindow, but the RenderWindow's destructor runs first, you could potentially see a crash on exit depending on the implementation of DSFML, SFML, and the system graphics driver. I see, so that's what you meant, thank you
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 14:38:53 UTC, Mike Parker wrote: On Tuesday, 3 July 2018 at 13:32:21 UTC, Chris M. wrote: After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions. https://issues.dlang.org/show_bug.cgi?id=19051 So are the mingw libs only shipped in the zip file? I don't have them with the installer version of 2.080.0, nor lld for that matter. But I see them in the zip for the 2.081.0 RC. Seems to be an option in the 2.080.1 installer (which I ignored before since I wasn't entirely sure how things worked on Windows), not sure about previous versions though.
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 14:42:58 UTC, Flaze07 wrote: On Tuesday, 3 July 2018 at 14:32:01 UTC, Mike Parker wrote: Resources allocated for the process will be released on exit. I see...but it is dependant on the OS right ? because I have seen other stuff relating to malloc as well, there are some out there that said that there is no need to free any more because the OS ( in this case windows ) will handle it As far as I know, this is true on every operating system and has always been true as long as I've been programming. The OS allocates resources for the process and doles them out when you request them, so of course it cleans it all up when you're done. Things can get buggy when you're doing multithreading, or spawning new processes (with e.g. fork()), as you can sometimes wind up with zombie threads that cause the process to not actually exit, or zombie processes that keep going in the background, taking up resources. But in general, yes, the OS will clean up behind you. You only have to worry about leaks when your application is long-lived, e.g. servers, text editors, games. If you're making a game and you aren't releasing resources when they're no longer needed, then your memory usage will keep going up the longer the game runs. DMD is a good example, too, even though it's a short-lived program. It actually never releases any memory it allocates, which is one part of its compilation speed story. That's just fine, until you start compiling template/CTFE/mixin-heavy code. Then it becomes a disadvantage as memory usage can ratchet up real quick. When I was learning C, it actually was drilled into my head that every resource allocation must have a corresponding deallocation, from the beginning to the end, and I faithfully implemented things that way for years to the extent that early versions of Derelict actually unloaded shared libraries in static destructors. However, the reason that was pushed so strongly is because it's so easy to forget to free resources during runtime in C, causing leaks and other bugs to crop up, that it's best to be religious about it so that you don't forget. But it's absolutely not necessary to go through and release every single allocated resource *at shutdown*. That said, the GC in D runs when main exits anyway, so the destructor in your example will be called. That's why I warned earlier about it being nondeterministic. For example, if you have a Texture instance that depends on the context of the RenderWindow, but the RenderWindow's destructor runs first, you could potentially see a crash on exit depending on the implementation of DSFML, SFML, and the system graphics driver.
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On 7/3/18 10:37 AM, ag0aep6g wrote:
On Tuesday, 3 July 2018 at 13:32:52 UTC, aliak wrote:
foreach (c; "️") {
writeln(c);
}
So basically the above just doesn't work. Prints gibberish.
Because you're printing one UTF-8 code unit (`char`) per line.
So I figured, std.uni.byGrapheme would help, since that's what they
are, but I can't get it to print them back out? Is there a way?
foreach (c; "️".byGrapheme) {
writeln(c.);
}
You're looking for `c[]`. But that won't work, because std.uni
apparently doesn't recognize those as grapheme clusters. The emojis may
be too new. std.uni is based on Unicode version 6.2, which is a couple
years old.
Oops! I didn't realize this, ignore my message about reporting a bug.
I still think it's very odd for printing a grapheme to print the data
structure.
-Steve
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 14:32:01 UTC, Mike Parker wrote: Resources allocated for the process will be released on exit. I see...but it is dependant on the OS right ? because I have seen other stuff relating to malloc as well, there are some out there that said that there is no need to free any more because the OS ( in this case windows ) will handle it
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 13:32:52 UTC, aliak wrote:
So basically the above just doesn't work. Prints gibberish.
What system are you on? Successfully printing this stuff depends
on a lot of display details too, like writeln goes to a
terminal/console and they are rarely configured to support such
characters by default.
You might actually be better off printing it to a file instead of
to a display, then opening that file in your browser or
something, just to confirm the code printed is correctly
displayed by the other program.
foreach (c; "️".byGrapheme) {
writeln(c.);
prolly just printing `c` itself would work and if not try `c[]`
but then again it might see it as multiple graphemes, idk if it
is even implemented.
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 13:32:21 UTC, Chris M. wrote: After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions. https://issues.dlang.org/show_bug.cgi?id=19051 So are the mingw libs only shipped in the zip file? I don't have them with the installer version of 2.080.0, nor lld for that matter. But I see them in the zip for the 2.081.0 RC.
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 13:36:56 UTC, aliak wrote: Hehe I guess the forum really is using D :p The two graphemes I'm talking about (which seem to not be rendered correctly above) are: family emoji: https://emojipedia.org/family-woman-woman-boy-boy/ rainbow flag: https://emojipedia.org/rainbow-flag/ Looks like forum.dlang.org has a problem when they appear side by-side. Works (in the preview): ️ Doesn't work: ️
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 13:32:52 UTC, aliak wrote:
foreach (c; "️") {
writeln(c);
}
So basically the above just doesn't work. Prints gibberish.
Because you're printing one UTF-8 code unit (`char`) per line.
So I figured, std.uni.byGrapheme would help, since that's what
they are, but I can't get it to print them back out? Is there a
way?
foreach (c; "️".byGrapheme) {
writeln(c.);
}
You're looking for `c[]`. But that won't work, because std.uni
apparently doesn't recognize those as grapheme clusters. The
emojis may be too new. std.uni is based on Unicode version 6.2,
which is a couple years old.
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 10:56:26 UTC, Flaze07 wrote:
hmm, I assume you know about DSFML, so... i.e
void main( string args[] ) {
auto win = new RenderWindow( VideoMode( 400, 400 ),
"resource leak ?" );
win.close();
}
//in this context, is there any memory leak ? because I saw
from the source that the render window is freed during the
destructor calls
Even if the destructor doesn't run, there's no memory leak.
Resources allocated for the process will be released on exit.
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On 7/3/18 9:32 AM, aliak wrote:
Hi, trying to figure out how to loop through a string of characters and
then spit them back out.
Eg:
foreach (c; "️") {
writeln(c);
}
So basically the above just doesn't work. Prints gibberish.
So I figured, std.uni.byGrapheme would help, since that's what they are,
but I can't get it to print them back out? Is there a way?
foreach (c; "️".byGrapheme) {
writeln(c.);
}
And then if I type the loop variable as dchar, then it seems that the
family empji is printed out as 4 faces - so the code points I guess -
and the rainbow flag is other stuff (also its code points I assume)
Yeah, it appears that you can't actually print a grapheme. I would have
assumed writeln(c) works. It does work, it just prints the struct data
instead of converting back to utf.
Is there a type that I can use to store graphemes and then output them
as a grapheme as well? Or do I have to use like lib ICU maybe or
something similar?
I honestly can't figure it out. I think directly writing graphemes as
viewable UTF was not something that was considered.
Definitely needs a bugzilla issue.
-Steve
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 13:32:52 UTC, aliak wrote:
Hi, trying to figure out how to loop through a string of
characters and then spit them back out.
Eg:
foreach (c; "️") {
writeln(c);
}
So basically the above just doesn't work. Prints gibberish.
So I figured, std.uni.byGrapheme would help, since that's what
they are, but I can't get it to print them back out? Is there a
way?
foreach (c; "️".byGrapheme) {
writeln(c.);
}
And then if I type the loop variable as dchar, then it seems
that the family empji is printed out as 4 faces - so the code
points I guess - and the rainbow flag is other stuff (also its
code points I assume)
Is there a type that I can use to store graphemes and then
output them as a grapheme as well? Or do I have to use like lib
ICU maybe or something similar?
Cheers,
- Ali
Hehe I guess the forum really is using D :p
The two graphemes I'm talking about (which seem to not be
rendered correctly above) are:
family emoji: https://emojipedia.org/family-woman-woman-boy-boy/
rainbow flag: https://emojipedia.org/rainbow-flag/
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 05:36:12 UTC, Seb wrote: On Monday, 2 July 2018 at 23:00:08 UTC, Chris M. wrote: On Monday, 2 July 2018 at 21:20:26 UTC, Seb wrote: On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: [...] Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far. I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC? Ah, okay. I'm mostly on Linux so I generally miss anything Windows-related. I was using the following link and figured I'd install DMC as well. https://dlang.org/dmd-windows.html#requirements BTW have you tried using LDC? They might ship a newer version of LLD. After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions. https://issues.dlang.org/show_bug.cgi?id=19051
what's the correct way to handle unicode? - trying to print out graphemes here.
Hi, trying to figure out how to loop through a string of
characters and then spit them back out.
Eg:
foreach (c; "️") {
writeln(c);
}
So basically the above just doesn't work. Prints gibberish.
So I figured, std.uni.byGrapheme would help, since that's what
they are, but I can't get it to print them back out? Is there a
way?
foreach (c; "️".byGrapheme) {
writeln(c.);
}
And then if I type the loop variable as dchar, then it seems
that the family empji is printed out as 4 faces - so the code
points I guess - and the rainbow flag is other stuff (also its
code points I assume)
Is there a type that I can use to store graphemes and then output
them as a grapheme as well? Or do I have to use like lib ICU
maybe or something similar?
Cheers,
- Ali
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 10:00:00 UTC, Mike Parker wrote:
The only way you're going to be leaking resources is if the app
is long running and the resource objects are never collected.
I'd be more concerned about the nondeterministic nature of the
destructor calls, particularly what happens at app shut down if
the render window destructor is called before any thing that
depends on the graphics context. If the library doesn't account
for that, you'll get random crashes when the app exits.
If you need to release resources while the app is running, just
use resource.destroy(). This will make sure the destructor is
called and the object is reset to its init state, and you can
maintain determinism.
hmm, I assume you know about DSFML, so... i.e
void main( string args[] ) {
auto win = new RenderWindow( VideoMode( 400, 400 ), "resource
leak ?" );
win.close();
}
//in this context, is there any memory leak ? because I saw from
the source that the render window is freed during the destructor
calls
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 07:29:12 UTC, Flaze07 wrote:
class RenderWindow {
private sfRenderWindow* _window;
public {
this() {
_window = sfRenderWindow_create(/*parameters*/);
}
//couple of other functions
~this() {
sfRenderWindow_destroy( window );
}
}
}
//not a very accurate representation, but should get the
message pretty clear
which I am very concerned about leaking resources, the tutorial
did just not use scoped!, instead it directly use new, but what
about leaking resources ?
The only way you're going to be leaking resources is if the app
is long running and the resource objects are never collected. I'd
be more concerned about the nondeterministic nature of the
destructor calls, particularly what happens at app shut down if
the render window destructor is called before any thing that
depends on the graphics context. If the library doesn't account
for that, you'll get random crashes when the app exits.
If you need to release resources while the app is running, just
use resource.destroy(). This will make sure the destructor is
called and the object is reset to its init state, and you can
maintain determinism.
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 07:03:43 UTC, vit wrote:
On Tuesday, 3 July 2018 at 02:13:21 UTC, Flaze07 wrote:
e.g A is a class that emits output during destruction
{
auto a = scoped!A();
}
how do I contain it in a container, in the Array struct ?
{
auto a = scoped!A();
Array!( typeof( a ) ) arr;
foreach( i ; 0..3 ) {
arr.insertBack( scoped!A );
}
}
is that how you do it ?
Copying/moving scoped!Class is very unsafe. scoped!Class is
struct and have all of limitations of structs like no internal
pointers to itself...
That's why it is not copyable.
that's interesting, but I am using dsfml by jebbs( not derelict
), and I checked the code, it appears that the most of the class
allocates resource and then freeing it in Destructor i.e
class RenderWindow {
private sfRenderWindow* _window;
public {
this() {
_window = sfRenderWindow_create(/*parameters*/);
}
//couple of other functions
~this() {
sfRenderWindow_destroy( window );
}
}
}
//not a very accurate representation, but should get the message
pretty clear
which I am very concerned about leaking resources, the tutorial
did just not use scoped!, instead it directly use new, but what
about leaking resources ?
Re: how to create an array of scoped objects ?
On Tuesday, 3 July 2018 at 02:13:21 UTC, Flaze07 wrote:
e.g A is a class that emits output during destruction
{
auto a = scoped!A();
}
how do I contain it in a container, in the Array struct ?
{
auto a = scoped!A();
Array!( typeof( a ) ) arr;
foreach( i ; 0..3 ) {
arr.insertBack( scoped!A );
}
}
is that how you do it ?
Copying/moving scoped!Class is very unsafe. scoped!Class is
struct and have all of limitations of structs like no internal
pointers to itself...
That's why it is not copyable.
