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:
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
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
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
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;
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.
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
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
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
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?
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
le 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 s
hat'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 f
;
}
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
* 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
;
}
}
But that is obviously not going to work. Does anyone know the
right way
to handle nested C structs of that form.
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
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
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
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
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.
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.
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
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
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
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
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
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~
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)
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
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
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.
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
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
34 matches
Mail list logo
