On Monday, 20 December 2021 at 11:58:03 UTC, Tim wrote:
On Monday, 20 December 2021 at 10:24:00 UTC, Jan wrote:
Is this a known issue, or is there a way to instruct DMD to
use a specific calling convention for a given type?
This looks like a bug. It seems to work without constructor in
C++,
On Monday, 20 December 2021 at 11:58:03 UTC, Tim wrote:
On Monday, 20 December 2021 at 10:24:00 UTC, Jan wrote:
Is this a known issue, or is there a way to instruct DMD to
use a specific calling convention for a given type?
This looks like a bug. It seems to work without constructor in
C++,
On Monday, 20 December 2021 at 10:24:00 UTC, Jan wrote:
Is this a known issue, or is there a way to instruct DMD to use
a specific calling convention for a given type?
This looks like a bug. It seems to work without constructor in
C++, but still crashes with a constructor in D. It also seems
I have a small struct that I'm trying to interface to.
C++
```cpp
struct __declspec(dllexport) SmallStruct
{
float value = 0;
//float value2 = 0;
//float value3 = 0;
SmallStruct(float val)
: value(val)
{
}
static SmallStruct GetValue(float input)
{
return
On Friday, 10 December 2021 at 16:42:33 UTC, Tim wrote:
All virtual methods have to match exactly including order. If a
virtual method is missing or added, then calling this or a
later virtual method could call the wrong method or generate a
segmentation fault. Non-virtual methods have to be
On Friday, 10 December 2021 at 12:46:07 UTC, rempas wrote:
On Thursday, 9 December 2021 at 21:35:14 UTC, Tim wrote:
Methods, which are not virtual in C++, also have to be marked
final in D, because C++ and D use a different default.
Is this a must or just good practices?
All virtual methods
On Thursday, 9 December 2021 at 21:35:14 UTC, Tim wrote:
The referenced methods like Fl_Widget::_clear_fullscreen are
implemented directly in the header, so the D code also needs
the implementation, because it is not included in the compiled
library.
What is funny about that is that I
On Thursday, 9 December 2021 at 19:05:08 UTC, rempas wrote:
Anyone has an idea?
The referenced methods like Fl_Widget::_clear_fullscreen are
implemented directly in the header, so the D code also needs the
implementation, because it is not included in the compiled
library.
Methods, which
I would like to interface with a C++ library called
[FLTK](https://www.fltk.org/). I'm trying to implement the
binding for the classes based to what I've read
[here](https://dlang.org/spec/cpp_interface.html#classes) but it
seems that It doesn't work as expected for me. I want to
implement
On Wednesday, 10 June 2020 at 08:31:47 UTC, Mathias LANG wrote:
On Wednesday, 10 June 2020 at 06:43:24 UTC, Andre Pany wrote:
[...]
Depending on your needs, it might be trivial. We use this, and
it works accross all 3 platforms:
On Wednesday, 10 June 2020 at 06:43:24 UTC, Andre Pany wrote:
Hi,
I would like to interface with the library
https://github.com/NTNU-IHB/FMI4cpp
and have following class definitions in the header file:
``` c++
namespace fmi4cpp {
template
class fmu_base {
public:
const
On Wednesday, 10 June 2020 at 06:43:24 UTC, Andre Pany wrote:
Also, the C++ classes make use of templates. Is it still
possible to call these
classes from D?
It should be, I did something similar and it worked. But it was
quite some time ago so I don't remember exact situation and any
Hi,
I would like to interface with the library
https://github.com/NTNU-IHB/FMI4cpp
and have following class definitions in the header file:
``` c++
namespace fmi4cpp {
template
class fmu_base {
public:
const std::string guid() const {
return
On Saturday, 7 September 2019 at 12:39:25 UTC, Ali Çehreli wrote:
On 09/07/2019 03:26 AM, Andrew Edwards wrote:
> [1] I did not declare any of the other member variables from
the struct,
> don't know if this is a source of the problem.
Yes, it definitely is a problem. The members are accessed
On 09/07/2019 03:26 AM, Andrew Edwards wrote:
> [1] I did not declare any of the other member variables from the struct,
> don't know if this is a source of the problem.
Yes, it definitely is a problem. The members are accessed as byte
offsets into their objects. Without defining the other
On Saturday, 7 September 2019 at 12:30:53 UTC, Andrew Edwards
wrote:
On Saturday, 7 September 2019 at 12:24:49 UTC, Ali Çehreli
wrote:
On 09/07/2019 03:26 AM, Andrew Edwards wrote:
> float continuallyUpdatedValue;
> float continuallyChangingValue; // [1]
They mean the same thing for
On Saturday, 7 September 2019 at 12:24:49 UTC, Ali Çehreli wrote:
On 09/07/2019 03:26 AM, Andrew Edwards wrote:
> float continuallyUpdatedValue;
> float continuallyChangingValue; // [1]
They mean the same thing for an English speaker but compilers
don't know that (yet?). :)
Ali
On 09/07/2019 03:26 AM, Andrew Edwards wrote:
> float continuallyUpdatedValue;
> float continuallyChangingValue; // [1]
They mean the same thing for an English speaker but compilers don't know
that (yet?). :)
Ali
I'm running into the following issue when attempting to interface
with C++:
// C++
namespace MySpace
{
MyType& GetData();
}
struct MyType
{
// ...
float continuallyUpdatedValue;
// ...
};
// call site
MySpace::GetData().continuallyUpdatedValue;
// D
extern
On Monday, 29 April 2019 at 14:38:54 UTC, 9il wrote:
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
[...]
Hello Ferhat,
You can use RCArray!T or Slice!(RCI!T) [1, 2] as common thread
safe @nogc types for D and C++ code.
See also integration C++ example [3] and C++
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not
On Monday, 29 April 2019 at 00:53:34 UTC, Paul Backus wrote:
On Sunday, 28 April 2019 at 23:10:24 UTC, Ferhat Kurtulmuş
wrote:
You are right. I am rewriting the things using mallocs, and
will use core.stdc.stdlib.free on d side. I am not sure if I
can use core.stdc.stdlib.free to destroy
On Sunday, 28 April 2019 at 23:10:24 UTC, Ferhat Kurtulmuş wrote:
You are right. I am rewriting the things using mallocs, and
will use core.stdc.stdlib.free on d side. I am not sure if I
can use core.stdc.stdlib.free to destroy arrays allocated with
new op.
core.stdc.stdlib.free is (as the
On Sunday, 28 April 2019 at 03:54:17 UTC, Paul Backus wrote:
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not facing crashes so far. Is GC
of D handling things for me? Here is an
On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote:
Example without code; for some reason a macro is defined for
the stdlib functions `malloc`, `realloc`, and `free`. Maybe
it's just because I don't have any pro experience with C or
C++, but that seems a bit excessive. Or I
On Sunday, 13 January 2019 at 23:23:50 UTC, Alex wrote:
These three are members of the standard library in D.
https://dlang.org/phobos/core_memory.html
Ah, yea that's way easier.
At first, I would suggest to try out some automatic converters,
which are written by the community:
On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote:
Example without code; for some reason a macro is defined for
the stdlib functions `malloc`, `realloc`, and `free`. Maybe
it's just because I don't have any pro experience with C or
C++, but that seems a bit excessive. Or I could
Hello all!
So while I have a decent grasp on D, I've been having trouble
figuring out specific projects that I could do in D, so I thought
I'd maybe find a little C or C++ library I could transfer over to
D. I decided to make my life easier and look for something that's
just a single header
On 2018-05-01 17:14:53 +, Robert M. Münch said:
Yes, great! Thanks. I could extend the code now. But I get a next problem:
extern (C++, b2d) {
class AnyBase {
bool isShared();
}
pragma(mangle, "Object");
class b2dObject : AnyBase {
}
class Image : b2dObject {
// class
On 2018-05-01 16:07:30 +, Timoses said:
On Tuesday, 1 May 2018 at 15:24:09 UTC, Robert M. Münch wrote:
Hi, I'm mostly doing simple C-API wrappers around C++ code to access
thigns from D. However, I wanted to try how far I can come using C++
directly.
I have the following C++ code in
On Tuesday, 1 May 2018 at 15:24:09 UTC, Robert M. Münch wrote:
Hi, I'm mostly doing simple C-API wrappers around C++ code to
access thigns from D. However, I wanted to try how far I can
come using C++ directly.
I have the following C++ code in namespace N:
class Image : public Object {
Hi, I'm mostly doing simple C-API wrappers around C++ code to access
thigns from D. However, I wanted to try how far I can come using C++
directly.
I have the following C++ code in namespace N:
class Image : public Object {
Error create(int w, int h, uint32_t p) noexcept;
}
And I have
https://github.com/opencv/opencv/issues/6585#issuecomment-221842441
snip:
> "C-API" is not supported and should be removed totally (but we have a lack of
> resources to port this legacy C code to C++, so some of this code still
> exists right now). Also huge part of fresh OpenCV functionality
On Sunday, 4 February 2018 at 08:33:20 UTC, Mike Parker wrote:
Though, I'm curious why anyone would want to declare a callback
in a C++ program as cdecl only on Windows and use the default
C++ convention everywhere else. I suggest you dig into it and
make sure that's what's intended. And good
Calypso (https://github.com/Syniurge/Calypso/) is the most promising
way to interface with C++, it requires 0 bindings and understands all
of C++ (templates etc); there are some caveats/kinks that are being
ironed out (and any help is welcome).
On Sun, Feb 4, 2018 at 4:37 AM, rjframe via
On Sun, 04 Feb 2018 08:33:20 +, Mike Parker wrote:
> Though, I'm curious why anyone would want to declare a callback in a C++
> program as cdecl only on Windows and use the default C++
> convention everywhere else. I suggest you dig into it and make sure
> that's what's intended. And good
On Sunday, 4 February 2018 at 10:42:22 UTC, infinityplusb wrote:
On Sunday, 4 February 2018 at 08:33:20 UTC, Mike Parker wrote:
[...]
it is, everyone keeps saying writing bindings in D is super
easy ...
I feel this is a slight simplification. :(
[...]
Sounds easy enough.
[...]
[...]
On Sunday, 4 February 2018 at 08:33:20 UTC, Mike Parker wrote:
On Sunday, 4 February 2018 at 08:17:31 UTC, Mike Parker wrote:
Assuming this is OpenCV ...
it is, everyone keeps saying writing bindings in D is super easy
...
I feel this is a slight simplification. :(
version(Windows)
On Sunday, 4 February 2018 at 08:17:31 UTC, Mike Parker wrote:
So assuming CV_CDECL is cdecl, this should do it:
extern(C) alias CvCmpFunc = int function(const(void)*,
const(void)*, void*);
Assuming this is OpenCV, Looking at [1], it's cdecl only on
Windows. Empty everywhere else. So
On Sunday, 4 February 2018 at 07:54:12 UTC, infinityplusb wrote:
Hi all
I'm looking to try and write an interface to C++, but given I'm
a casual dabbler in D, it's slightly beyond my current ability
in terms of both C++ and D!
As a leg up, how would one translate something like this from
On 04/02/2018 7:54 AM, infinityplusb wrote:
Hi all
I'm looking to try and write an interface to C++, but given I'm a casual
dabbler in D, it's slightly beyond my current ability in terms of both
C++ and D!
As a leg up, how would one translate something like this from C++ to D?
`typedef int
Hi all
I'm looking to try and write an interface to C++, but given I'm a
casual dabbler in D, it's slightly beyond my current ability in
terms of both C++ and D!
As a leg up, how would one translate something like this from C++
to D?
`typedef int (CV_CDECL* CvCmpFunc)(const void* a, const
On Sunday, 25 June 2017 at 02:09:53 UTC, Adam D. Ruppe wrote:
On Sunday, 25 June 2017 at 02:05:35 UTC, unleashy wrote:
How would I call `addToBar` from C code?
You don't. Instead write it like:
struct Foo
{
int bar;
}
extern(C) void addToBar(Foo* foo, int what) {
foo.bar += what;
On Sunday, 25 June 2017 at 02:05:35 UTC, unleashy wrote:
How would I call `addToBar` from C code?
You don't. Instead write it like:
struct Foo
{
int bar;
}
extern(C) void addToBar(Foo* foo, int what) {
foo.bar += what;
}
Then define it in C the same way and you call it the
Hello! If I have a D struct like:
struct Foo
{
int bar;
void addToBar(int what) {
bar += what;
}
}
How would I call `addToBar` from C code? Would I need to put the
`addToBar` function outside of the struct and mark it as `extern
(C)` and in normal D code take advantage of
On 06/11/2016 01:59 PM, yawniek wrote:
i forgot to add a few important points:
- the strings in vec_t are not c strings
- vec_t might contain other data than strings
the original ctor i pasted actually doesn't even work, temporarly i
solved it like
this(string s) {
char[] si =
On Saturday, 11 June 2016 at 10:26:17 UTC, Mike Parker wrote:
On Saturday, 11 June 2016 at 09:32:54 UTC, yawniek wrote:
thanks mike for the in depth answer.
i forgot to add a few important points:
- the strings in vec_t are not c strings
- vec_t might contain other data than strings
the
On Saturday, 11 June 2016 at 09:32:54 UTC, yawniek wrote:
so far i defined vec_t as:
struct vec_t {
char *base;
size_t len;
this(string s) { base = s.ptr; len = s.lenght; }
nothrow @nogc inout(char)[] toString() inout @property { return
base[0 .. len]; }
nothrow @nogc
my C library works a lot with strings defined in C as:
struct vec_t {
char *base;
size_t len;
}
is there a easy way to feed regular D strings to functions that
accept vec_t*
without creating a vec_t every time
or do i write wrappers for these functions and if so, what is the
most
D.learn is about basics of D. Interfacing with C++ is an advanced
topic, with feature set in flux, so I'd suggest to ask about it
in http://forum.dlang.org/group/digitalmars.D group.
On Saturday, 1 November 2014 at 21:00:54 UTC, Kagamin wrote:
D claims compatibility with system C compiler, which usually
have 32-bit int.
... and for C/C++ long which can be 32 or 64 bit, DMD recently
introduced the types c_long and c_ulong. (Not released yet.)
On Saturday, 1 November 2014 at 15:00:57 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
In the following pages:
http://dlang.org/interfaceToC.html
http://dlang.org/cpp_interface
the Data Type Compatibility section says D int is compatible
with
C/C++ int. Isn't this actually false
On 11/2/2014 8:59 PM, Marc Schütz schue...@gmx.net wrote:
On Saturday, 1 November 2014 at 21:00:54 UTC, Kagamin wrote:
D claims compatibility with system C compiler, which usually have
32-bit int.
... and for C/C++ long which can be 32 or 64 bit, DMD recently
introduced the types c_long and
On Sunday, 2 November 2014 at 12:37:13 UTC, Mike Parker wrote:
On 11/2/2014 8:59 PM, Marc Schütz schue...@gmx.net wrote:
On Saturday, 1 November 2014 at 21:00:54 UTC, Kagamin wrote:
D claims compatibility with system C compiler, which usually
have
32-bit int.
... and for C/C++ long which
On Sunday, 2 November 2014 at 11:59:27 UTC, Marc Schütz wrote:
On Saturday, 1 November 2014 at 21:00:54 UTC, Kagamin wrote:
D claims compatibility with system C compiler, which usually
have 32-bit int.
... and for C/C++ long which can be 32 or 64 bit, DMD recently
introduced the types c_long
On Sunday, 2 November 2014 at 12:37:13 UTC, Mike Parker wrote:
On 11/2/2014 8:59 PM, Marc Schütz schue...@gmx.net wrote:
On Saturday, 1 November 2014 at 21:00:54 UTC, Kagamin wrote:
D claims compatibility with system C compiler, which usually
have
32-bit int.
... and for C/C++ long which
On Sunday, 2 November 2014 at 16:53:06 UTC, ponce wrote:
c_long and c_ulong get used, should c_int and c_uint too in
bindings?
Looks like fringe use case.
On common 32 and 64-bit platforms, the only type whose size
changed between 32 and 64 bits is long, so the other aliases were
deemed
Hello. I really really need to be able to interface well with a C++
library which contains lots of classes if I am going to further invest
time into D.
Now from the http://dlang.org/cpp_interface I find out the current
status of built-in C++ interfacing support. I'm working on Linux so
using
In the following pages:
http://dlang.org/interfaceToC.html
http://dlang.org/cpp_interface
the Data Type Compatibility section says D int is compatible with
C/C++ int. Isn't this actually false because D's integer types are
fixed-size whereas C/C++'s are variable? So D int is only compatible
with
D claims compatibility with system C compiler, which usually have
32-bit int.
You can see http://wiki.dlang.org/DIP61 and linked discussions.
Static and virtual functions probably work. Constructors and
destructors probably don't. What's difficult is multiple
inheritance. The information on C++ support is largely considered
private to the compiler team.
On Saturday, 5 July 2014 at 22:18:56 UTC, Marco Cosentino wrote:
auto client = *(cast(ClientImplementation*) data);
Try just
auto client = cast(ClientImplementation) data;
and
this.setProcessCallback(callback, cast(void *) this);
setProcessCallback(callback, cast(void*) this);
On Saturday, 5 July 2014 at 22:28:48 UTC, Adam D. Ruppe wrote:
In general, remember any class reference in D is already
equivalent to a pointer in C or C++ and can be casted straight
to void* without needing to take its address.
Thanks Adam,
you're a life saver ;). It works like a charme.
this field, with some GC
magic associating a pointer (ptr) to another pointer (cast(void*)
swig_image).
This would make interfacing with C++ libs much easier as there
would be no bookkeeping in user code.
Short version:
I have a struct A* aptr allocated in C/C++ with an internal
pointer aptr-ptr (say a double*)
I want to store a reference x (say double[]) in D to aptr only through
aptr-ptr, not through aptr directly as it's inconvenient in my use case.
How do I achieve that, so that when x goes
Ok, a C function pointer like this:
struct MyStruct{
int (*foo)(int);
};
Translates to D as this:
struct MyStruct{
int function(int) foo;
}
But what about calling conventions? There isn't any int extern(C)
function(int) is there? Not sure if that would even make
On 30-10-2012 11:13, Nick Sabalausky wrote:
Ok, a C function pointer like this:
struct MyStruct{
int (*foo)(int);
};
Translates to D as this:
struct MyStruct{
int function(int) foo;
}
But what about calling conventions? There isn't any int extern(C)
On Tue, 30 Oct 2012 11:15:55 +0100
Alex Rønne Petersen a...@lycus.org wrote:
On 30-10-2012 11:13, Nick Sabalausky wrote:
Ok, a C function pointer like this:
struct MyStruct{
int (*foo)(int);
};
Translates to D as this:
struct MyStruct{
int
Nick Sabalausky:
Which, if any, of foo1/foo2/foo3 are extern(C)? (I know bar
definitely is.)
A general comment: if you are not sure of the answer, then the
programmer that will read your code will probably have similar
problems. So in such cases it's better to try to not write that
code.
On 10/30/12, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote:
Which, if any, of foo1/foo2/foo3 are extern(C)? (I know bar definitely
is.)
All of them.
void main()
{
pragma(msg, MyFn);
pragma(msg, typeof(MyStruct.foo2));
pragma(msg, typeof(bar));
}
extern (C) int
On 2012-10-30 18:44, Andrej Mitrovic wrote:
All of them.
void main()
{
pragma(msg, MyFn);
pragma(msg, typeof(MyStruct.foo2));
pragma(msg, typeof(bar));
}
extern (C) int function(int)
extern (C) int function(int)
extern (C) void(extern (C) int function(int) foo3)
extern (C) int
Hello,
I was trying to run the example on the Interfacing to C page (
http://www.d-programming-language.org/interfaceToC.html) and ran into few
issues. To get it to work as is i was .dup(ing) strings into new chars
with defined size and passing those with .ptr. Anyway it seemed like quite a
bit
On Tue, Jun 28, 2011 at 11:15 PM, Joshua Niehus jm.nie...@gmail.com wrote:
Hello,
I was trying to run the example on the Interfacing to C page (
http://www.d-programming-language.org/interfaceToC.html) and ran into few
issues. To get it to work as is i was .dup(ing) strings into new chars
On 26/06/2011 20:54, Alex_Dovhal wrote:
I'd like to call C functions and use C variables in D module.
D calls C functions just fine, but how can I use C variables?
extern(C) extern int myCVar;
--
Robert
http://octarineparrot.com/
On Sun, Jun 26, 2011 at 5:00 PM, Alex_Dovhal alex_dov...@yahoo.com wrote:
Robert Clipsham rob...@octarineparrot.com wrote:
On 26/06/2011 20:54, Alex_Dovhal wrote:
I'd like to call C functions and use C variables in D module.
D calls C functions just fine, but how can I use C variables?
Jimmy Cao jcao...@gmail.com wrote:
It works for me like this:
extern(C){
__gshared int c_var;
int func();
}
Thanks.
On 2011-02-26 17:06, Mike Wey wrote:
On 02/26/2011 11:49 AM, Jacob Carlborg wrote:
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some code.
I found a couple of sources on this:
1) http://www.digitalmars.com/d/2.0/htomodule.html
2)
On 2011-02-26 17:58, simendsjo wrote:
On 26.02.2011 17:06, Mike Wey wrote:
On 02/26/2011 11:49 AM, Jacob Carlborg wrote:
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some
code.
I found a couple of sources on this:
1)
On Sat, 26 Feb 2011 22:24:52 -0500, Bekenn leav...@alone.com wrote:
On 2/25/2011 7:24 PM, Steven Schveighoffer wrote:
BTW, I think long long is a gnu extension, it's not standard C (I don't
think long long exists in Visual C for instance).
I'm pretty sure it's standard as of C99 (though not
On 27.02.2011 11:43, Jacob Carlborg wrote:
On 2011-02-26 17:58, simendsjo wrote:
On 26.02.2011 17:06, Mike Wey wrote:
On 02/26/2011 11:49 AM, Jacob Carlborg wrote:
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some
code.
I found a couple
On Sunday 27 February 2011 05:41:49 Steven Schveighoffer wrote:
On Sat, 26 Feb 2011 22:24:52 -0500, Bekenn leav...@alone.com wrote:
On 2/25/2011 7:24 PM, Steven Schveighoffer wrote:
BTW, I think long long is a gnu extension, it's not standard C (I don't
think long long exists in Visual C
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some code.
I found a couple of sources on this:
1) http://www.digitalmars.com/d/2.0/htomodule.html
2) http://www.digitalmars.com/d/2.0/interfaceToC.html
1)
C's long is the same as D's int.
long
On 2011-02-26 02:35, Jonathan M Davis wrote:
On Friday, February 25, 2011 17:16:31 simendsjo wrote:
On 26.02.2011 02:06, bearophile wrote:
simendsjo:
So.. A long in C is the same as the platform size? And long long doesn't
exist in 64 bit?
In D the size of int/uint is 32 bits and long/ulong
On 02/26/2011 11:49 AM, Jacob Carlborg wrote:
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some code.
I found a couple of sources on this:
1) http://www.digitalmars.com/d/2.0/htomodule.html
2)
On 26.02.2011 17:06, Mike Wey wrote:
On 02/26/2011 11:49 AM, Jacob Carlborg wrote:
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some code.
I found a couple of sources on this:
1) http://www.digitalmars.com/d/2.0/htomodule.html
2)
On 02/26/2011 05:58 PM, simendsjo wrote:
On 26.02.2011 17:06, Mike Wey wrote:
On 02/26/2011 11:49 AM, Jacob Carlborg wrote:
On 2011-02-26 01:28, simendsjo wrote:
C is not my strong side, so I'm having some problems wrapping some
code.
I found a couple of sources on this:
1)
On 2/25/2011 7:24 PM, Steven Schveighoffer wrote:
BTW, I think long long is a gnu extension, it's not standard C (I don't
think long long exists in Visual C for instance).
I'm pretty sure it's standard as of C99 (though not yet for C++; that's
coming with C++0x). MSVC does indeed support it.
C is not my strong side, so I'm having some problems wrapping some code.
I found a couple of sources on this:
1) http://www.digitalmars.com/d/2.0/htomodule.html
2) http://www.digitalmars.com/d/2.0/interfaceToC.html
1)
C's long is the same as D's int.
long long is long
2)
C 32bit's long long is
simendsjo:
So.. A long in C is the same as the platform size? And long long doesn't
exist in 64 bit?
In D the size of int/uint is 32 bits and long/ulong is 64 bits.
In C the size of int, unsigned int, long, long long int, unsigned long long
int, etc are not fixed, the change according to
On 26.02.2011 02:06, bearophile wrote:
simendsjo:
So.. A long in C is the same as the platform size? And long long doesn't
exist in 64 bit?
In D the size of int/uint is 32 bits and long/ulong is 64 bits.
In C the size of int, unsigned int, long, long long int, unsigned long long int, etc
On Fri, 25 Feb 2011 20:06:04 -0500, bearophile bearophileh...@lycos.com
wrote:
simendsjo:
So.. A long in C is the same as the platform size? And long long doesn't
exist in 64 bit?
In D the size of int/uint is 32 bits and long/ulong is 64 bits.
In C the size of int, unsigned int, long,
On Friday, February 25, 2011 17:35:02 Jonathan M Davis wrote:
On Friday, February 25, 2011 17:16:31 simendsjo wrote:
On 26.02.2011 02:06, bearophile wrote:
simendsjo:
So.. A long in C is the same as the platform size? And long long
doesn't exist in 64 bit?
In D the size of
94 matches
Mail list logo
