Re: Generating struct members from c structs
On Wednesday, 1 July 2020 at 07:26:44 UTC, Anthony wrote: When doing interop with a c library, is there a way to automatically generate the fields that are needed for a struct? [snip] Is there an easier way though? Dstep is probably what you're looking for: https://github.com/jacob-carlborg/dstep It eats C header files and creates appropriate D files from them. -- Simen
Generating struct members from c structs
When doing interop with a c library, is there a way to
automatically generate the fields that are needed for a struct?
For example, when interfacing with the lwan c library:
// lwan.h
struct lwan {
struct lwan_trie url_map_trie;
struct lwan_connection *conns;
struct lwan_strbuf headers;
struct {
pthread_barrier_t barrier;
struct lwan_thread *threads;
unsigned int max_fd;
unsigned int count;
} thread;
struct lwan_config config;
struct coro_switcher switcher;
int main_socket;
unsigned int n_cpus;
};
module lwan;
extern (C) {
struct lwan {
... // <<< How do I populate this without having to write
all the sub structs?
};
void lwan_init(lwan* l);
void lwan_shutdown(lwan* l);
}
import lwan;
void main() {
lwan l; //This is currently not allocating enough memory
lwan_init(&l);
lwan_shutdown(&l);
}
How do I populate the lwan struct without having to write all the
sub structs?
I'm thinking that maybe it'll be best to create a wrapper c
function that initializes the lwan struct and returns a pointer.
That way I don't have to declare any fields.
extern (C) {
struct lwan;
lwan* lwan_make(); //wrapper function (perhaps in wrapper.c)
void lwan_cleanup(lwan* l); //wrapper function
void lwan_init(lwan* l);
void lwan_shutdown(lwan* l);
}
Is there an easier way though?
Re: Linking D with C structs
On Monday, 29 June 2020 at 10:44:16 UTC, kinke wrote: On Monday, 29 June 2020 at 06:29:38 UTC, Anthony wrote: What does "__initZ" refer to? Does this refer to automatic initialization like "this()"? Almost, it's the static initializer for that struct, which is omitted because you apparently don't compile/link the module containing the struct declaration. Initialize the char array with zeros (= 0) to make the struct fully zero-initialized, preventing the need for that symbol. chars in D are initialized with 0xFF, unlike byte and ubyte. Thanks for this! What do you mean by "which is omitted because you apparently don't compile/link the module containing the struct declaration"? Is there a link step that I'm missing that will make things easier for me? Is there a way to have D automatically get the struct from the c files directly?
Re: Linking D with C structs
On Monday, 29 June 2020 at 06:29:38 UTC, Anthony wrote: What does "__initZ" refer to? Does this refer to automatic initialization like "this()"? Almost, it's the static initializer for that struct, which is omitted because you apparently don't compile/link the module containing the struct declaration. Initialize the char array with zeros (= 0) to make the struct fully zero-initialized, preventing the need for that symbol. chars in D are initialized with 0xFF, unlike byte and ubyte.
Linking D with C structs
Hello,
I'm trying to hand write some bindings to mongo-c-driver. (For
learning purposes and to get the latest bindings).
My binding code to convert to mongoc/mongoc.d
is:
= c interop file
module mongoc/mongoc.d;
import core.stdc.stdint;
extern (c) {
struct {
uint domain;
uint code;
char[504] message; //when this exists, the code does not
compile
}
}
===
= build script
export
LD_LIBRARY_PATH=mongo-c-driver/cmake-build/src/libmongoc:mongo-c-driver/cmake-build/src/libbson:$LD_LIBRARY_PATH
dmd hello_mongo.d \
-I=mongo-c-driver/src/libmongoc/src/ \
-I=mongo-c-driver/src/libbson/src/ \
-I=mongo-c-driver/cmake-build/src/libbson/src/bson/ \
-I=mongo-c-driver/cmake-build/src/libmongoc/src/mongoc \
-L=-Lmongo-c-driver/cmake-build/src/libmongoc \
-L=-Lmongo-c-driver/cmake-build/src/libbson \
-L=-lmongoc-1.0 \
-L=-lbson-1.0 \
./hello_mongo
However, when I add the message field in the struct, I cannot
compile the code:
ld: hello_mongo.o: in function `_Dmain':
hello_mongo.d:(.text._Dmain[_Dmain]+0x1a): undefined reference to
`_D6mongoc6mongoc13_bson_error_t6__initZ'
What does "__initZ" refer to?
Does this refer to automatic initialization like "this()"?
Re: link errors when using extern (C) structs
On 28/10/2018 11:11 PM, DanielG wrote: Wait, wut? Do modules that get pulled in from dub's "importPaths" not get compiled in the same way? No. They just get -I'd.
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 08:38:56 UTC, Nicholas Wilson wrote: Oh yeah, I didn't think to mention that you need to compile them for them to fix your missing symbols problem. Wait, wut? Do modules that get pulled in from dub's "importPaths" not get compiled in the same way? The dstep-generated files were working for the most part -- standalone C functions had no problem -- it was only those structs that I was having problems with. But now that they're in the default /source folder, I don't get the linker errors anymore.
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 06:59:31 UTC, DanielG wrote: For the benefit of anybody who encounters a problem like this in the future ... originally I had my C library "header" files (renamed from .di to .d after the feedback from Nicholas) in a special 'headers/' subdir, used as an import path in dub.json. I simply moved those files to the source folder and everything started magically working. And thanks again, Nicholas! Oh yeah, I didn't think to mention that you need to compile them for them to fix your missing symbols problem. No problems.
Re: link errors when using extern (C) structs
For the benefit of anybody who encounters a problem like this in the future ... originally I had my C library "header" files (renamed from .di to .d after the feedback from Nicholas) in a special 'headers/' subdir, used as an import path in dub.json. I simply moved those files to the source folder and everything started magically working. And thanks again, Nicholas!
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 04:23:27 UTC, DanielG wrote:
On Sunday, 28 October 2018 at 03:39:41 UTC, Nicholas Wilson
wrote:
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
Thank you for your response.
Can you elaborate on 'write struct...'? Is that special syntax?
Nope thats me not proofreading my posts properly, sorry.
I also checked to see if you meant "(manually re-write it
as...)", but updating the struct definition in the generated .d
header with field values doesn't seem to solve the __initZ
issue, either.
Hmm thats, odd unless there are other fields with initialisers
that are forcing its emission.
And redefining it in the client .d module just shadows the
header definition, so ...
Try not using the .di files at all. I've never had any use for
them personally. Wrapping a C library, all thats required is
definitions of the functions and types declared by the headers.
this can be done with a .d file.
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 03:39:41 UTC, Nicholas Wilson wrote:
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
Thank you for your response.
Can you elaborate on 'write struct...'? Is that special syntax? I
assumed so, but dmd doesn't like it. I also checked to see if you
meant "(manually re-write it as...)", but updating the struct
definition in the generated .d header with field values doesn't
seem to solve the __initZ issue, either. And redefining it in the
client .d module just shadows the header definition, so ...
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 03:28:20 UTC, DanielG wrote:
I'm wrapping a C library which has a lot of structs defined,
and I keep running into issues where dmd complains that .init
isn't defined ("Symbol Undefined __xxx__initZ" etc).
I'm struggling to narrow it down to a simple example that
demonstrates it - I actually made something that's kind of
minimal, but it goes from working to breaking depending on
whether the file extension is .di or .d, for the file
containing the extern (C)'ed struct definitions. Also it seems
to depend (in the .di case) on whether the C structs use double
vs. int values for their fields. (int fields work with either
file extension)
That is because the default initialiser for double is double.nan
which is non-zero and therefore the default initialiser of a
struct containing a double will have a non-zero default
initialiser. This lives as a __xxx__initZ symbol somewhere
in your program.
The .di or .d is because in the case of .di the compiler assumes
the symbols exist somewhere already and it doesn't need to (and
can't because it would create duplicates) emit them to the object
files.
But simply changing the file extension in my real project, of
the header files translated by dstep, seems to have no effect.
In short, it seems that for certain C structs I cannot use them
as a field in a D struct even with a manually-specified default
value - I get link errors no matter what
(init/toHash/opEquals). How can I get around that?
Am I supposed to be doing something with C structs to avoid
these kinds of errors in my D code? I've searched the forum but
nothing really jumps out at me as relevant.
For the __initZ symbols
struct Foo {
double bar;
}
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
and have only zero initialiser for you structs, which means they
don't need to be stored.
the opEquals stems from the fact that for structs containing
floats equality comparison cannot be implemented with bitwise
compare.
The easiest solution is to just use .d for the extension, very
rarely are .di files useful.
link errors when using extern (C) structs
I'm wrapping a C library which has a lot of structs defined, and
I keep running into issues where dmd complains that .init isn't
defined ("Symbol Undefined __xxx__initZ" etc).
I'm struggling to narrow it down to a simple example that
demonstrates it - I actually made something that's kind of
minimal, but it goes from working to breaking depending on
whether the file extension is .di or .d, for the file containing
the extern (C)'ed struct definitions. Also it seems to depend (in
the .di case) on whether the C structs use double vs. int values
for their fields. (int fields work with either file extension)
But simply changing the file extension in my real project, of the
header files translated by dstep, seems to have no effect.
In short, it seems that for certain C structs I cannot use them
as a field in a D struct even with a manually-specified default
value - I get link errors no matter what (init/toHash/opEquals).
How can I get around that?
Am I supposed to be doing something with C structs to avoid these
kinds of errors in my D code? I've searched the forum but nothing
really jumps out at me as relevant.
Re: Binding Nested C Structs
On 2015-07-10 05:38, Craig Dillabaugh wrote:
I am trying to bind to a C union with a number of nested structs
declared as follows:
typedef union {
int Integer;
struct {
int nCount;
int *paList;
} IntegerList;
struct {
int nCount;
GIntBig *paList;
} Integer64List;
} OGRField;
According to http://wiki.dlang.org/D_binding_for_C#Nested_Structs
I should attempt to write something like (last example shown):
extern(C) union OGRField
{
int Integer;
struct {
int nCount;
int* paList;
}
struct {
int nCount;
GIntBig* paList;
}
}
But that is obviously not going to work. Does anyone know the right way
to handle nested C structs of that form.
I think it will work but the API would be different.
--
/Jacob Carlborg
Re: Binding Nested C Structs
On Friday, 10 July 2015 at 03:38:49 UTC, Craig Dillabaugh wrote:
I am trying to bind to a C union with a number of nested
structs declared as follows:
typedef union {
int Integer;
struct {
int nCount;
int *paList;
} IntegerList;
struct {
int nCount;
GIntBig *paList;
} Integer64List;
} OGRField;
According to
http://wiki.dlang.org/D_binding_for_C#Nested_Structs
I should attempt to write something like (last example shown):
extern(C) union OGRField
{
int Integer;
struct {
int nCount;
int* paList;
}
struct {
int nCount;
GIntBig* paList;
}
}
But that is obviously not going to work. Does anyone know the
right way
to handle nested C structs of that form.
OK Found the answer elsewhere on the same page:
extern(C) union OGRField
{
int Integer;
struct _IntegerList
{
int nCount;
int* paList;
}
_IntegerList IntegerList;
struct _Integer64List
{
int nCount;
GIntBig* paList;
}
_Integer64List Integer64List;
}
Binding Nested C Structs
I am trying to bind to a C union with a number of nested structs
declared as follows:
typedef union {
int Integer;
struct {
int nCount;
int *paList;
} IntegerList;
struct {
int nCount;
GIntBig *paList;
} Integer64List;
} OGRField;
According to http://wiki.dlang.org/D_binding_for_C#Nested_Structs
I should attempt to write something like (last example shown):
extern(C) union OGRField
{
int Integer;
struct {
int nCount;
int* paList;
}
struct {
int nCount;
GIntBig* paList;
}
}
But that is obviously not going to work. Does anyone know the
right way
to handle nested C structs of that form.
Re: Binding non-trivial C++ structs
On 12/17/2014 03:01 AM, Kagamin wrote: > previous thread: > http://forum.dlang.org/post/mailman.1464.1415039051.9932.digitalmar...@puremagic.com > I read that thread. I don't understand if / how it answers this question. -- Paul O'Neil Github / IRC: todayman
Binding non-trivial C++ structs
To make my C++ binding life easier, I wrote a small string structure [1]
in C++ to use instead of std::string and produced the D declarations for
some of it [2]. (It's not that complicated, I promise.) The important
properties of this struct are that it has a non-trivial copy constructor
and a destructor. These properties mean that the ABI for returning a
binding::string are different than just a plain value [3]. Calling a
C++ function from D that returns a string does not obey the changed ABI.
How do I indicate to dmd that the C++ string should have the different
ABI? Well I should add a copy constructor or destructor, right? Copy
constructors on structs don't exist because we have blitting, so I can't
do that. When I add a destructor, linking fails with:
undefined reference to `_D6binding6binding6string6__dtorMFZv'
So that doesn't work either.
Now for the questions:
1) Is this supported?
2) If so, how do I actually do it?
Thanks
Paul O'Neil
[1] C++:
namespace binding {
class string
{
char * buffer;
size_t length;
public:
string();
string(const string& other);
string(string&&);
string(const char * str);
string(const char * str, unsigned long len);
string(const char * start, const char * end);
string(size_t len);
~string();
size_t size();
char * begin();
char * end();
bool operator==(const string& other) const;
bool operator!=(const string& other) const;
const char * c_str();
const char * c_str() const;
string operator+(const string& other) const;
string& operator=(const string& other);
string& operator=(string&& other);
void operator+=(const string& other);
};
}
[2] D:
extern(C++, binding) struct string
{
private char * buffer;
private size_t length;
public size_t size();
public char * begin();
public char * end();
public char * begin();
public char * end();
public char * c_str();
this(ref const(binding.string));
this(const(char)* str);
this(const(char)* str, size_t len);
this(const(char)* start, const(char)* end);
this(size_t len);
this(ref const(binding.string));
~this();
}
[3] http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
--
Paul O'Neil
Github / IRC: todayman
Re: C structs
On 06/20/14 14:42, Dicebot via Digitalmars-d-learn wrote: > On Friday, 20 June 2014 at 12:17:22 UTC, Johann Lermer wrote: >> So, why is there no init routine for the rectangle? There's only one for the >> matrix. > > That needs actually building deimos cairo and checking symbols in object > files so I will do as soon as have a bit more spare time ;) If i were to guess: the compiler optimizes the init-blitting into a memset(-equivalent) when all the members are default initted to zero; D's doubles are initialized to NaN, so this optimization is not happening when a struct contains such fields. artur
Re: C structs
On Friday, 20 June 2014 at 12:17:22 UTC, Johann Lermer wrote: Agreed, but I assumed, that since all definitions in cairo.d are defined as extern (System), (same happens with extern (C), btw.), I would have expected, that D does not implicitly generate initialisation functions. D requires that all variable are default-initialized, extern or not -> T.init is necessary. So, why is there no init routine for the rectangle? There's only one for the matrix. That needs actually building deimos cairo and checking symbols in object files so I will do as soon as have a bit more spare time ;)
Re: C structs
Agreed, but I assumed, that since all definitions in cairo.d are defined as extern (System), (same happens with extern (C), btw.), I would have expected, that D does not implicitly generate initialisation functions. So, why is there no init routine for the rectangle? There's only one for the matrix.
Re: C structs
By D specification you are always required to compiled all imported modules, it does not matter if those contain only definitions. Some of implicitly generated symbols (like T.init) will be in their object files.
Re: C structs
On Friday, 20 June 2014 at 10:51:20 UTC, Johann Lermer wrote: `_D6deimos5cairo5cairo14cairo_matrix_t6__initZ' it's an init value for the struct; in D all data is initialized.
C structs
Hi,
I'm fiddling around with cairo (downloaded
fromhttps://github.com/D-Programming-Deimos/cairo) and I stumbled
over this problem:
(file rectandmatrix.d)
import deimos.cairo.cairo;
void main ()
{
cairo_rectangle_int_t rect;
cairo_matrix_t matrix;
}
Compiling that with 'dmd rectandmatrix' fails with this error:
rectandmatrix.o: In function `_Dmain':
rectandmatrix.d:(.text._Dmain+0x18): undefined reference to
`_D6deimos5cairo5cairo14cairo_matrix_t6__initZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1
The rectangle is OK - no error there. The matrix however,
produces the error. The difference between both is that
cairo_rectangle_int_t is a struct containing integers, and
cairo_matrix_t contains doubles.
I can, however, compile like that:
'dmd rectandmatrix deimos/cairo/cairo.d' (deimos being in a
subdir of the working directory)
then cairo.d is compiled as well and linked to the code.
So, my questions are:
1) Why do I have to compile and link cairo.d - it's only an
definition file for C code and IMHO there shouldn't be any need
to compile cairo.d at all.
2) Why ist a struct containing only integers handled so
differently from a struct holding doubles?
Thanks
Re: Creating an array of C structs
On Monday, 27 January 2014 at 13:08:28 UTC, Colin Grogan wrote: In my defense, I believe C initializes arrays with the curly brackets Can I keep making excuses? Yes you can... And don't worry, I mess up initialization too. Lots of time. Especially when I tried initializing an array of structs made of 2 structs. I think I wasted at least 15 minutes before giving up :D
Re: Creating an array of C structs
On Monday, 27 January 2014 at 10:39:28 UTC, Francesco Cattoglio wrote: On Monday, 27 January 2014 at 10:13:08 UTC, Colin Grogan wrote: On Monday, 27 January 2014 at 09:34:04 UTC, Namespace wrote: Arrays are enclosed in [] ;) I'm an idiot. Can I delete this thread to save further embarrassment? :) HA-HA! (read it with Nelson voice, ofc) In my defense, I believe C initializes arrays with the curly brackets Can I keep making excuses?
Re: Creating an array of C structs
On Monday, 27 January 2014 at 10:13:08 UTC, Colin Grogan wrote: On Monday, 27 January 2014 at 09:34:04 UTC, Namespace wrote: Arrays are enclosed in [] ;) I'm an idiot. Can I delete this thread to save further embarrassment? :) HA-HA! (read it with Nelson voice, ofc)
Re: Creating an array of C structs
On Monday, 27 January 2014 at 10:13:08 UTC, Colin Grogan wrote: Arrays are enclosed in [] ;) I'm an idiot. Can I delete this thread to save further embarrassment? :) No! Evenryone will see this! >:E~
Re: Creating an array of C structs
On Monday, 27 January 2014 at 09:34:04 UTC, Namespace wrote:
On Monday, 27 January 2014 at 09:06:17 UTC, Colin Grogan wrote:
Why wont the following code compile?
import std.stdio;
void main()
{
myStruct[] mystructs = {
{1, 1.1f},
{2, 2.2f}
};
}
extern(C){
struct myStruct{
int x;
float y;
}
}
It fails with the (unhelpful imo) error message:
source/app.d(7): Error: a struct is not a valid initializer
for a myStruct[]
The reason I need a C struct is because I'm interfacing to a C
library that expects an array of myStructs.
myStruct[] mystructs = [
{1, 1.1f},
{2, 2.2f}
];
Arrays are enclosed in [] ;)
I'm an idiot.
Can I delete this thread to save further embarrassment? :)
Re: Creating an array of C structs
On Monday, 27 January 2014 at 09:06:17 UTC, Colin Grogan wrote:
Why wont the following code compile?
import std.stdio;
void main()
{
myStruct[] mystructs = {
{1, 1.1f},
{2, 2.2f}
};
}
extern(C){
struct myStruct{
int x;
float y;
}
}
It fails with the (unhelpful imo) error message:
source/app.d(7): Error: a struct is not a valid initializer for
a myStruct[]
The reason I need a C struct is because I'm interfacing to a C
library that expects an array of myStructs.
myStruct[] mystructs = [
{1, 1.1f},
{2, 2.2f}
];
Arrays are enclosed in [] ;)
Creating an array of C structs
Why wont the following code compile?
import std.stdio;
void main()
{
myStruct[] mystructs = {
{1, 1.1f},
{2, 2.2f}
};
}
extern(C){
struct myStruct{
int x;
float y;
}
}
It fails with the (unhelpful imo) error message:
source/app.d(7): Error: a struct is not a valid initializer for a
myStruct[]
The reason I need a C struct is because I'm interfacing to a C
library that expects an array of myStructs.
Re: C structs
20.10.2010 14:35, Mafi wrote: Am 19.10.2010 23:39, schrieb Stanislav Blinov: Have you tried Derelict? (dsource.org/projects/derelict). There is a branch called Derelict2 which is D2-compatible. Derelict does not require import libraries, only DLLs/SOs - it does run-time dynamic linking (i.e. loads dynamic library and binds function pointers at runtime). The only major caveat with Derelict at the moment is lack of proper support for 'shared' directive, which leads to chaos in multithreaded applications. Some work has been done to fix that, but much is to be done still. I've tried Derelict2 first. I'm using D2 so Dererelict1 was no option. After svn checkout (I know it could be broken but I found no 'stable'-link) I tried to compile and got a bunch of immutability errors. I thought that it must be an yet uncomplete port so I went with static linking but I tried to write everything so I could use Derelict in some future. Hm, I remember checking out trunk not so long ago. I had no trouble building it (though I did that on Linux). Were those errors, by chance, string-related? Before we completely go off-topic: you might try posting to Derelict forum on dsource, I'm sure this is not something that would be hard to fix. Hurray! Now I'm going to write a wrapper for SDL_Surface. I will only use surface poiters so my questions is if I can safely put these pointers into class instances which on destruction free the surface (iff it's no display)? Some caveats apply: iirc with SDL you typically initialize and close down the different subsystems. With the GC finalizing surfaces will be freed after sdl shutdown, dunno if that's legal. Generally, it's not. Mafi, if you really want to wrap up SDL handles into classes, I'd advise you to either: 1) Rethink your design. For example, you could store references to all objects that are bound to SDL handles and free resources before SDL_Quit()/SDL_QuitSubSystem() call. That sounds good. It isn't even reference counting. Sort of, actually :) 2) Manually 'tell' classes they should free SDL resources via some method. Even in C++ you'd delete all your heap-allocated objects anyway, so there's no difference, except that instead of calling delete you'd call some custom method. Yea, I didn't want to prevent people from using from using some close moethod but D has a GC included so why don't use it? Now I know it's a horrible idea. Things get even worse if you plan to use Derelict when it's stable, because the whole SDL DLL/SO may get unloaded before GC starts calling destructors, and you end up calling no-longer-existing functions thus having a (not quite so) fun time tracing bugs. Pretty much anything that concerns video in SDL should go into one and only thread, so you should "be doubly careful, for all manner of stupid mousetraps await our toes in the dark" if you think of multithreaded application. This means that lazy SDL resource management is in no way an option. [...] I very much like the design decision made by Eric Poggel in Yage (yage3d.net). This mostly concerns OpenGL resources, but generalization is clear enough: GL resources are allocated and initialized on demand (i.e. when first used) and freed if not used in some time. Similar approach may be taken with SDL as well, I think. I think you can't do it with sdl. If I understood this bit right, you want to free resources when not used and reload them later again. A problem with this is that loaded-and-then-manipulated surfaces would loose their change and completely code generated surfaces would be completly lost. That's a matter of implementation, I think. For example, when 'freeing' surfaces that may be called upon later, you might fetch surface (meta)data, compress it (zlib/tga/png come to mind) and store it till it's required again.
Re: C structs
Am 19.10.2010 23:39, schrieb Stanislav Blinov: Lutger wrote: Mafi wrote: Hello, I'm trying to write some SDL wrapper. After a long fight against objconv, implib and optlink I finally got SDL loading. Have you tried Derelict? (dsource.org/projects/derelict). There is a branch called Derelict2 which is D2-compatible. Derelict does not require import libraries, only DLLs/SOs - it does run-time dynamic linking (i.e. loads dynamic library and binds function pointers at runtime). The only major caveat with Derelict at the moment is lack of proper support for 'shared' directive, which leads to chaos in multithreaded applications. Some work has been done to fix that, but much is to be done still. I've tried Derelict2 first. I'm using D2 so Dererelict1 was no option. After svn checkout (I know it could be broken but I found no 'stable'-link) I tried to compile and got a bunch of immutability errors. I thought that it must be an yet uncomplete port so I went with static linking but I tried to write everything so I could use Derelict in some future. Hurray! Now I'm going to write a wrapper for SDL_Surface. I will only use surface poiters so my questions is if I can safely put these pointers into class instances which on destruction free the surface (iff it's no display)? Some caveats apply: iirc with SDL you typically initialize and close down the different subsystems. With the GC finalizing surfaces will be freed after sdl shutdown, dunno if that's legal. Generally, it's not. Mafi, if you really want to wrap up SDL handles into classes, I'd advise you to either: 1) Rethink your design. For example, you could store references to all objects that are bound to SDL handles and free resources before SDL_Quit()/SDL_QuitSubSystem() call. That sounds good. It isn't even reference counting. 2) Manually 'tell' classes they should free SDL resources via some method. Even in C++ you'd delete all your heap-allocated objects anyway, so there's no difference, except that instead of calling delete you'd call some custom method. Yea, I didn't want to prevent people from using from using some close moethod but D has a GC included so why don't use it? Now I know it's a horrible idea. Pretty much anything that concerns video in SDL should go into one and only thread, so you should "be doubly careful, for all manner of stupid mousetraps await our toes in the dark" if you think of multithreaded application. This means that lazy SDL resource management is in no way an option. [...] I very much like the design decision made by Eric Poggel in Yage (yage3d.net). This mostly concerns OpenGL resources, but generalization is clear enough: GL resources are allocated and initialized on demand (i.e. when first used) and freed if not used in some time. Similar approach may be taken with SDL as well, I think. I think you can't do it with sdl. If I understood this bit right, you want to free resources when not used and reload them later again. A problem with this is that loaded-and-then-manipulated surfaces would loose their change and completely code generated surfaces would be completly lost.
Re: C structs
Lutger wrote: Mafi wrote: Hello, I'm trying to write some SDL wrapper. After a long fight against objconv, implib and optlink I finally got SDL loading. Have you tried Derelict? (dsource.org/projects/derelict). There is a branch called Derelict2 which is D2-compatible. Derelict does not require import libraries, only DLLs/SOs - it does run-time dynamic linking (i.e. loads dynamic library and binds function pointers at runtime). The only major caveat with Derelict at the moment is lack of proper support for 'shared' directive, which leads to chaos in multithreaded applications. Some work has been done to fix that, but much is to be done still. Hurray! Now I'm going to write a wrapper for SDL_Surface. I will only use surface poiters so my questions is if I can safely put these pointers into class instances which on destruction free the surface (iff it's no display)? Some caveats apply: iirc with SDL you typically initialize and close down the different subsystems. With the GC finalizing surfaces will be freed after sdl shutdown, dunno if that's legal. Generally, it's not. Mafi, if you really want to wrap up SDL handles into classes, I'd advise you to either: 1) Rethink your design. For example, you could store references to all objects that are bound to SDL handles and free resources before SDL_Quit()/SDL_QuitSubSystem() call. 2) Manually 'tell' classes they should free SDL resources via some method. Even in C++ you'd delete all your heap-allocated objects anyway, so there's no difference, except that instead of calling delete you'd call some custom method. Pretty much anything that concerns video in SDL should go into one and only thread, so you should "be doubly careful, for all manner of stupid mousetraps await our toes in the dark" if you think of multithreaded application. This means that lazy SDL resource management is in no way an option. Also, sdl surfaces may take lots of space, so if possible I would free them when no longer in use. The GC may not collect at all, or late. But this may or may not be a problem. I very much like the design decision made by Eric Poggel in Yage (yage3d.net). This mostly concerns OpenGL resources, but generalization is clear enough: GL resources are allocated and initialized on demand (i.e. when first used) and freed if not used in some time. Similar approach may be taken with SDL as well, I think.
Re: C structs
Mafi wrote: > Hello, > I'm trying to write some SDL wrapper. After a long fight against > objconv, implib and optlink I finally got SDL loading. Hurray! Now I'm > going to write a wrapper for SDL_Surface. I will only use surface > poiters so my questions is if I can safely put these pointers into class > instances which on destruction free the surface (iff it's no display)? Some caveats apply: iirc with SDL you typically initialize and close down the different subsystems. With the GC finalizing surfaces will be freed after sdl shutdown, dunno if that's legal. Also, sdl surfaces may take lots of space, so if possible I would free them when no longer in use. The GC may not collect at all, or late. But this may or may not be a problem.
C structs
Hello, I'm trying to write some SDL wrapper. After a long fight against objconv, implib and optlink I finally got SDL loading. Hurray! Now I'm going to write a wrapper for SDL_Surface. I will only use surface poiters so my questions is if I can safely put these pointers into class instances which on destruction free the surface (iff it's no display)?
