Hello Sergey,
Sun, 7 Dec 2008 07:04:22 + (UTC), John Reimer wrote:
Hello Jason,
Sergey Gromov wrote:
But what's the typical use case for extern(C++) objects ? I think
it's something like this:
extern(C++) class CppInterfaceClass { ... }
extern(C++) CppInterfaceClass create()
{
retur
Sun, 7 Dec 2008 07:04:22 + (UTC), John Reimer wrote:
> Hello Jason,
>
>> Sergey Gromov wrote:
>>
>>> But what's the typical use case for extern(C++) objects ? I think
>>> it's something like this:
>>>
>>> extern(C++) class CppInterfaceClass { ... }
>>>
>>> extern(C++) CppInterfaceClass cr
In the D code, the factory function enforces the stricture that the
C++ code is responsible for it's own object creation and destruction.
D code should touch this.
Last line above meant to say: "D code should NOT touch this"
as in, D code should not take any responsibility for creation/destr
Hello Jason,
Sergey Gromov wrote:
But what's the typical use case for extern(C++) objects ? I think
it's something like this:
extern(C++) class CppInterfaceClass { ... }
extern(C++) CppInterfaceClass create()
{
return new CppInterfaceClass(...);
}
extern(C++) void destroy(CppInterfaceClass
Sergey Gromov wrote:
> But what's the typical use case for extern(C++) objects ? I think it's
> something like this:
>
> extern(C++) class CppInterfaceClass { ... }
>
> extern(C++) CppInterfaceClass create()
> {
> return new CppInterfaceClass(...);
> }
>
> extern(C++) void destro
Tue, 02 Dec 2008 22:32:33 -0800, Walter Bright wrote:
> John Reimer wrote:
>> Is there a ClassInfo flag indicating no-gc-collection for extern(C++)
>> interfaces too?
>
> No. The COM object is special because part of its interface is to do its
> own memory management, that isn't true in general
John Reimer wrote:
Okay, that is an important detail for me to know. But I assumed that a
C++ interface must not be allocated in D either. In must acquire a
pointer from an external factory that handles the allocation outside of
the gc range (C++ code must allocate/delete it's own objects).
Hello Walter,
John Reimer wrote:
In D (windows) it would look like so (assuming you have done away
with the compilers internal detection of COM interfaces):
extern(C++) interface IUnknown:
{
extern(Windows):
int QueryInterface(nsIID* uuid, void **result);
int AddRef();
int Release();
}
I bet
John C wrote:
But IUnknown.Release does no such thing. If you're talking about the
implementation in std.c.windows.com.ComObject, then all it does is
decrement the reference count. It has a comment saying "let the GC
reap it" - which is incorrect, since the GC doesn't collect COM
objects (as you
Walter Bright Wrote:
> John Reimer wrote:
> > In D (windows) it would look like so (assuming you have done away with
> > the compilers internal detection of COM interfaces):
> >
> > extern(C++) interface IUnknown:
> > {
> > extern(Windows):
> > int QueryInterface(nsIID* uuid, void **
On Tue, 02 Dec 2008 13:23:55 +0300, Walter Bright
<[EMAIL PROTECTED]> wrote:
John Reimer wrote:
In D (windows) it would look like so (assuming you have done away with
the compilers internal detection of COM interfaces):
extern(C++) interface IUnknown:
{
extern(Windows):
int Que
John Reimer wrote:
In D (windows) it would look like so (assuming you have done away with
the compilers internal detection of COM interfaces):
extern(C++) interface IUnknown:
{
extern(Windows):
int QueryInterface(nsIID* uuid, void **result);
int AddRef();
int Release
Hello Walter,
John Reimer wrote:
It would be nice if extern(C++) were still ported to D 1.0, but the
other alternative of enabling extern(System) in COM support (instead
of extern(Windows) ) will also work.
Unfortunately, extern(C++), even if ported to D1, will not work for
COM objects. COM
John Reimer wrote:
It would be nice if extern(C++) were still ported to D 1.0, but the
other alternative of enabling extern(System) in COM support (instead of
extern(Windows) ) will also work.
Unfortunately, extern(C++), even if ported to D1, will not work for COM
objects. COM objects, to be
Hello Kagamin,
G++ uses C++ abstract class for nsISupports, so its methods calling
convention is C++ as implemented by g++:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Compatibility.html
Yes, I had a peek at the XULRunner SDK, and it looked something like you say.
Thank you for the link.
Hello Walter,
John Reimer wrote:
Hello Walter,
John Reimer wrote:
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Just to make this clear, I'm banking on that the fact that
extern(C++) on an interface should al
G++ uses C++ abstract class for nsISupports, so its methods calling convention
is C++ as implemented by g++:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Compatibility.html
John Reimer wrote:
Hello Walter,
John Reimer wrote:
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Just to make this clear, I'm banking on that the fact that
extern(C++) on an interface should also remove the nec
Tomas Lindquist Olsen wrote:
Walter Bright wrote:
John Reimer wrote:
So extern(System) does not translate to extern(C)? Does that mean
that all extern(System)'s in my code are defaulting to extern(D)?
That'd be a shocker to me. :) If that's true, it would certainly
change my understanding
Hello Tomas,
Walter Bright wrote:
John Reimer wrote:
So extern(System) does not translate to extern(C)? Does that mean
that all extern(System)'s in my code are defaulting to extern(D)?
That'd be a shocker to me. :) If that's true, it would certainly
change my understanding of what I thou
Walter Bright wrote:
John Reimer wrote:
So extern(System) does not translate to extern(C)? Does that mean
that all extern(System)'s in my code are defaulting to extern(D)?
That'd be a shocker to me. :) If that's true, it would certainly
change my understanding of what I thought was making
Hello Walter,
John Reimer wrote:
So extern(System) does not translate to extern(C)? Does that mean
that all extern(System)'s in my code are defaulting to extern(D)?
That'd be a shocker to me. :) If that's true, it would certainly
change my understanding of what I thought was making my code
John Reimer wrote:
Okay, I'm confused then. While I understand that the compiler uses
specifically uses extern(...) to describe the calling convention, I
/assumed/ that the compiler was detecting this the extern(C++) like so:
I think you're right, I'd forgotten.
John Reimer wrote:
So extern(System) does not translate to extern(C)? Does that mean that
all extern(System)'s in my code are defaulting to extern(D)?
That'd be a shocker to me. :) If that's true, it would certainly change
my understanding of what I thought was making my code work. :D
No,
Hello Walter,
John Reimer wrote:
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Yes, I think so. But I should probably test the theory with dmd 2.0
first just to make sure. This is just about over my head since
Hello Walter,
John Reimer wrote:
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Just to make this clear, I'm banking on that the fact that
extern(C++) on an interface should also remove the necessity to alias
to a
John Reimer wrote:
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Just to make this clear, I'm banking on that the fact that extern(C++)
on an interface should also remove the necessity to alias to a COM
interfac
John Reimer wrote:
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Yes, I think so. But I should probably test the theory with dmd 2.0
first just to make sure. This is just about over my head since I'm not
too f
Hello John,
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Just to make this clear, I'm banking on that the fact that extern(C++)
on an interface should also remove the necessity to alias to a COM
interface on linux
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Just to make this clear, I'm banking on that the fact that extern(C++) on
an interface should also remove the necessity to alias to a COM interface
on linux. I am gu
Hello Walter,
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
Yes, I think so. But I should probably test the theory with dmd 2.0 first
just to make sure. This is just about over my head since I'm not too familiar
with C++ int
So are you saying that XPCOM will work on Linux with D if only the
extern(Windows) was actually extern(C++) ?
As the title suggests, this post is about D interfaces, specifically as supported
in D 1.0.
Here's some background:
I've been working on porting the SWT Browser package to DWT (on Linux) over
the last few months. I'm happy to say that I've mostly succeeded despite
some rather annoying prob
33 matches
Mail list logo
