Hi!
I put in my github account the first version of cloop - Cross Language
Object Oriented Programming.
- https://github.com/asfernandes/cloop
This first version is limited to void and int datatypes, supports C, C++
and Free Pascal, and the makefile works only in POSIX.
Some files in
On 08/14/14 13:50, Dimitry Sibiryakov wrote:
14.08.2014 11:34, Alex Peshkoff wrote:
I do not have access
to that box myself, so I can't report what is actually that format. But
an attempt to access it as we do on windows/linux cause an error.
Do you mean normal access like calling virtual
On 08/14/14 18:24, Tony Whyman wrote:
I was using the Alpha 2 source
may be 16, 15 ...
but definitely not 4
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 08/14/14 15:28, Dimitry Sibiryakov wrote:
14.08.2014 11:34, Alex Peshkoff wrote:
HP C/aC++ Version A.06.26
Alpha version?..
don't think so
PS: The problem with FPC which started whole this topic seems to be a
compiler's bug which destroy value returning by external function.
15.08.2014 9:40, Alex Peshkoff wrote:
strange...
I use external functions in the sample of calling c++ from pascal and
returned values are OK
Integers are ok, pointers are ok, interfaces are in trouble.
--
WBR, SD.
On 15/08/14 08:48, Dimitry Sibiryakov wrote:
Integers are ok, pointers are ok, interfaces are in trouble
This should probably be written in stone somewhere.
Even simple external calls such as fb_get_master_interface are difficult
enough. You have carefully define each data type used and ensure
15.08.2014 10:36, Tony Whyman wrote:
You have carefully define each data type used and ensure that
the calling conventions are compatible. Even cdecl starts being a
problem as soon as you get away from simple types - as you have found.
All that I found is:
1) Translating must be done by a
FYI - our colleagues from the Mission Control Center tested format of
VMT in the following environment
Intel(R) Itanium(R) Processor 9310
HP-UX B.11.31
HP C/aC++ Version A.06.26
and it differs from what we have on windows/linux. I do not have access
to that box myself, so I can't report what is
14.08.2014 11:34, Alex Peshkoff wrote:
I do not have access
to that box myself, so I can't report what is actually that format. But
an attempt to access it as we do on windows/linux cause an error.
Do you mean normal access like calling virtual function of PAC or your
hackery with its
14.08.2014 11:34, Alex Peshkoff wrote:
HP C/aC++ Version A.06.26
Alpha version?..
PS: The problem with FPC which started whole this topic seems to be a compiler's bug which
destroy value returning by external function. Testcase is attached. I registered ticket in
their bugtracker:
On Thursday 14 August 2014 13:28:33 Dimitry Sibiryakov wrote:
14.08.2014 11:34, Alex Peshkoff wrote:
HP C/aC++ Version A.06.26
Alpha version?..
More to the point - Itanium?
An ARM-based test would be useful.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird
On 14/08/2014 08:28, Dimitry Sibiryakov wrote:
14.08.2014 11:34, Alex Peshkoff wrote:
HP C/aC++ Version A.06.26
Alpha version?..
PS: The problem with FPC which started whole this topic seems to be a
compiler's bug which destroy value returning by external function.
Testcase is attached.
14.08.2014 13:40, Adriano dos Santos Fernandes wrote:
Isn't you that talked many times that a Delphi/FPC interface is
incompatible (more methods in the HEAD) with our ones, so why you keep
calling methods this way? How it's going to work?
If you had read whole messages, not random pieces of
I'm not quite sure what you think is wrong with this code (from the fpc
viewpoint):
# [31] WriteLn(master.getVersion());
callfpc_get_output
movq%rax,%rbx
movqU_P$CREATE_MASTER,%rdi
movqU_P$CREATE_MASTER,%rax
movq(%rax),%rax
call*(%rax)
movl
Just came across this on Wikipedia (hence needs to be checked)
If this is how gcc ++ works then it is clear why there is a mis-match
with fpc (instance variable in %rdi) and IMaster.GetVersion (instance
variable expected on stack with caller cleanup).
/thiscall/
//
/This calling
14.08.2014 14:08, Tony Whyman wrote:
I'm not quite sure what you think is wrong with this code (from the fpc
viewpoint):
That code is fine. This isn't:
callfb_get_master_interface
movq-104(%rbp),%rax
movq%rax,U_P$CREATE_MASTER
As you can see, value returned
Apologies, I should have read your bug report before replying as I
didn't realise your problem was with the flat call to
fb_get_master_interface. I just assumed that you would be getting a
problem with the call to GetVersion.
I have put your Pascal example into my test system and got an Access
On 14/08/2014 11:04, Tony Whyman wrote:
master := IMaster(GetMaster());
The program now does complete without an error, but returns 15 as the
version. My reading of the Firebird code is that the correct result is
4. So still something not right - probably the way the instance variable
is
I was using the Alpha 2 source
On 14/08/14 15:23, Adriano dos Santos Fernandes wrote:
On 14/08/2014 11:04, Tony Whyman wrote:
master := IMaster(GetMaster());
The program now does complete without an error, but returns 15 as the
version. My reading of the Firebird code is that the correct
14.08.2014 16:04, Tony Whyman wrote:
I changed it to:
Yes, I tried this workaround too. It works, but requirement to use cast on
every
assignment looks ugly: code generated for TMaster.getStatus() etc is the same,
so every
returning of interface will have to use such cast.
The program
My 800 Firebird/Delphi systems contact just asked, Any word on the Beta? He
needs SMP right now.
I don't think he watches this list but he does watch
http://tracker.firebirdsql.org/secure/Dashboard.jspa
I asked him how many times he's watched the FB3 Beta release date slide since
he's been
On 08/12/14 21:54, Adriano dos Santos Fernandes wrote:
On 12/08/2014 14:37, Mark Rotteveel wrote:
On 12-8-2014 18:48, Tom Coleman wrote:
One bias of mine that I will confess to is that I hate C++. Every time I am
forced to use it it turns out to be a horrible PITA. The last project I
On 13/08/2014 07:04, Alex Peshkoff wrote:
On 08/12/14 21:54, Adriano dos Santos Fernandes wrote:
On 12/08/2014 14:37, Mark Rotteveel wrote:
On 12-8-2014 18:48, Tom Coleman wrote:
One bias of mine that I will confess to is that I hate C++. Every
time I am forced to use it it turns out to be
13.08.2014 12:04, Alex Peshkoff wrote:
I attach here version 6 of our sample, which accesses C++ implemented
interfaces from FPC
program (tested on linux x64)
If you have FPC at hand, could you test attached modification of UIB's module that
should work with the current version of FB
On 08/13/14 14:53, Adriano dos Santos Fernandes wrote:
On 13/08/2014 07:04, Alex Peshkoff wrote:
On 08/12/14 21:54, Adriano dos Santos Fernandes wrote:
On 12/08/2014 14:37, Mark Rotteveel wrote:
On 12-8-2014 18:48, Tom Coleman wrote:
One bias of mine that I will confess to is that I hate
On 08/13/14 15:23, Dimitry Sibiryakov wrote:
13.08.2014 12:04, Alex Peshkoff wrote:
I attach here version 6 of our sample, which accesses C++ implemented
interfaces from FPC
program (tested on linux x64)
If you have FPC at hand, could you test attached modification of
UIB's module that
Den 2014-08-13 13:56 skrev Adriano dos Santos Fernandes såhär:
On 13/08/2014 08:24, Alex Peshkoff wrote:
Is this syntax Delphi-compatible?
:-)
I've wrote that I've used to work with Pascal 25 years ago. For example
I've used objects cause they are just present in language docs before
First of all I think about support of smart pointers.
I think this is left to callers, but...
I do not say that it must be done immediately.
Next - ability to
have implementation without Impl in the end of function names.
Already done. Implementation of objects uses virtual functions and
On 13/08/2014 09:15, Alex Peshkoff wrote:
Already done. Implementation of objects uses virtual functions and
dispatchers dispatches directly to them, without additional cost, via
obj-Name::method().
Can you send it to me?
I'll do as soon as I have the generator working a bit better.
Adriano
13.08.2014 13:24, Alex Peshkoff wrote:
What do you think about adding different styles of C++ code generation?
First of all I think about support of smart pointers.
Can your IDL generate current interface with pure abstract classes as well?..
--
WBR, SD.
The O.T. thread seems to be the subject of intense discussion.
Would anyone care to share their thoughts on this suggestion?
Thanks
On Aug 12, 2014, at 12:56 PM, Tom Coleman wrote:
On Aug 12, 2014, at 12:11 PM, Jim Starkey wrote:
I haven't a clue how this can be sorted out.
I have
On 13/08/2014 13:25, Dimitry Sibiryakov wrote:
13.08.2014 13:24, Alex Peshkoff wrote:
What do you think about adding different styles of C++ code generation?
First of all I think about support of smart pointers.
Can your IDL generate current interface with pure abstract classes as
well?..
On 08/13/14 20:25, Dimitry Sibiryakov wrote:
13.08.2014 13:24, Alex Peshkoff wrote:
What do you think about adding different styles of C++ code generation?
First of all I think about support of smart pointers.
Can your IDL generate current interface with pure abstract classes as
well?..
On 08/13/14 22:11, Alex Peshkoff wrote:
On 08/13/14 20:25, Dimitry Sibiryakov wrote:
13.08.2014 13:24, Alex Peshkoff wrote:
What do you think about adding different styles of C++ code generation?
First of all I think about support of smart pointers.
Can your IDL generate current
On 08/13/14 21:23, Dimitry Sibiryakov wrote:
13.08.2014 18:57, Adriano dos Santos Fernandes wrote:
Can your IDL generate current interface with pure abstract classes as
well?..
Why one would need this, if the proposed generated code is usable in the
same manner and has a stable layout
On 08/13/14 20:33, Tom Coleman wrote:
The O.T. thread seems to be the subject of intense discussion.
Would anyone care to share their thoughts on this suggestion?
Thanks
On Aug 12, 2014, at 12:56 PM, Tom Coleman wrote:
On Aug 12, 2014, at 12:11 PM, Jim Starkey wrote:
I haven't a clue
13.08.2014 20:28, Alex Peshkoff wrote:
Do you often read GPRE generated files? Or (even more interesting) yacc
generated?
A little difference: they are used by compiler only. Files generated from
IDL are used
by programmer.
Readable should be .idl file - product of preprocessing should
On Aug 13, 2014, at 2:34 PM, Alex Peshkoff wrote:
Why not focus on getting FB 3 out the door as a release - API as is - and
defer the API changes to a later release?
This will cause a need to support both interfaces in the future. And
they are not exactly compatible. We are at
On 13/08/2014 16:22, Tom Coleman wrote:
Understanding maybe, but I'm not sure you can say the same for Agreement.
And excuse me, but you may not have to support either interface in the future
if the current users die off waiting for a FB3 release.
AFAIK, Firebird 3 is at Alpha 2, which
You are now quite close to COM. The primary difference is that COM is based on
immutable interfaces and you have a single squishy interface with explicit
interface version. After a few iterations, developers with have to track what
versions had which features to avoid calling things that
On 13/08/2014 16:39, Jim Starkey wrote:
You are now quite close to COM. The primary difference is that COM is based
on immutable interfaces and you have a single squishy interface with explicit
interface version. After a few iterations, developers with have to track
what versions had
On Aug 13, 2014, at 3:28 PM, Adriano dos Santos Fernandes wrote:
On 13/08/2014 16:22, Tom Coleman wrote:
Understanding maybe, but I'm not sure you can say the same for Agreement.
And excuse me, but you may not have to support either interface in the
future if the current users die off
On 13/08/14 20:22, Tom Coleman wrote:
And excuse me, but you may not have to support either interface in the future
if the current users die off waiting for a FB3 release.
Are we really that desperate for a new version?
I have perfectly stable sites still running FB1.5 because they don't
want
On Aug 13, 2014, at 5:25 PM, Lester Caine wrote:
On 13/08/14 20:22, Tom Coleman wrote:
And excuse me, but you may not have to support either interface in the
future if the current users die off waiting for a FB3 release.
Are we really that desperate for a new version?
Our partner wants
On 13-08-2014 18:03, Tom Coleman wrote:
AFAIK, Firebird 3 is at Alpha 2, which snapshots almost always available.
This discussion was actually started internally.
You all think alpha versions and snapshots are there for what?
It's not there for we developers, certainly.
Download
LC Are we really that desperate for a new version?
I'm afraid so. At last in Brazil, currently situation is becoming
alarming at least. I hear more and more people saying that Firebird
became zumbi project. Firebird 3 release became kind of myth here,
and some people even think it will never get
Sorry, Adriano, but that's exactly what alpha versions are for. The
testers of the development team do the testing.
End users cannot be expected to test until a beta version is available.
--
Cheers!
Rich Saunders
From: Adriano dos Santos Fernandes adrian...@gmail.com
You all think alpha
On 08/11/14 22:29, Tom Coleman wrote:
I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
There is never any case where I would want to see std:exception.
Could it be time to start thinking about burying this idea that is looking
more and more like a sacred cow?
On 08/12/14 01:41, Dimitry Sibiryakov wrote:
11.08.2014 21:43, Adriano dos Santos Fernandes wrote:
You told before (and now) as y-valve is part of each provider. That's
not true.
Not true even that I ever told that. Read carefully and you'll see that I
name
completely separate parts:
On 08/11/14 22:40, Adriano dos Santos Fernandes wrote:
On 11/08/2014 15:29, Tom Coleman wrote:
I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
There is never any case where I would want to see std:exception.
Could it be time to start thinking about burying this
12.08.2014 9:50, Alex Peshkoff wrote:
Police classes seem to be ideal for exception type control.
I just wonder how these police classes can find out a way to store status
into custom
user-made class.
Say, I have in application Firebird exception class with following members:
gdscode,
53e9b621.5050...@mail.ru
Message-ID: e1539af719bd359c5254c41730071...@imap.procolix.com
X-Sender: m...@lawinegevaar.nl
User-Agent: RoundCube Webmail/0.2
On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On 08/11/14 22:29, Tom Coleman wrote:
I interface a proprietary
On 08/12/14 12:07, Dimitry Sibiryakov wrote:
12.08.2014 9:50, Alex Peshkoff wrote:
Police classes seem to be ideal for exception type control.
I just wonder how these police classes can find out a way to store status
into custom
user-made class.
Say, I have in application Firebird
Mark,
A good post as this sums up the issue. I only hope that the core team
are listening as what happens to a project when the developers ignore
the users?
On 12/08/14 09:13, Mark Rotteveel wrote:
The main point of an API is to allow developers to*use* Firebird, so
please do not alienate
On 08/12/14 12:13, Mark Rotteveel wrote:
53e9b621.5050...@mail.ru
Message-ID: e1539af719bd359c5254c41730071...@imap.procolix.com
X-Sender: m...@lawinegevaar.nl
User-Agent: RoundCube Webmail/0.2
On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On 08/11/14 22:29, Tom
On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On 08/11/14 22:29, Tom Coleman wrote:
I interface a proprietary language with Firebird, Oracle, and
Sybase/MS-SQL.
There is never any case
On 08/12/14 13:55, Mark Rotteveel wrote:
On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On 08/11/14 22:29, Tom Coleman wrote:
I interface a proprietary language with Firebird, Oracle, and
On Aug 12, 2014, at 2:35 AM, Alex Peshkoff wrote:
On 08/11/14 23:57, Tom Coleman wrote:
On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote:
You may be more interested in why something failed than just that it failed.
An error mechanism should play nicely with the status vector to expose as
On 08/12/14 19:43, Tom Coleman wrote:
On Aug 12, 2014, at 2:35 AM, Alex Peshkoff wrote:
On 08/11/14 23:57, Tom Coleman wrote:
On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote:
You may be more interested in why something failed than just that it
failed.
An error mechanism should play nicely
Mark, this is how I think we got here. There is a compelling need to export
engine semantics of UDFs and other types of plugins. The obvious -- and
desireable way -- to do this is with abstract objects. Since there also needed
some minor work on primary interface, it seemed logical to unite
On Aug 12, 2014, at 1:11 PM, Jim Starkey j...@jimstarkey.net wrote:
My position is that the external interface (the API) should remain y-valve
and handle oriented, extended as needed. An interface for export engine
semantics, however, has different requirements and can and should be
On Aug 12, 2014, at 2:37 AM, Alex Peshkoff wrote:
On 08/11/14 22:29, Tom Coleman wrote:
I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
There is never any case where I would want to see std:exception.
Could it be time to start thinking about burying this
On Aug 12, 2014, at 12:11 PM, Jim Starkey wrote:
I haven't a clue how this can be sorted out.
I have a suggestion.
Clearly this New Interface issue is complex and critical and is going to take
some time to sort out.
Why not focus on getting FB 3 out the door as a release - API as is - and
12.08.2014 19:54, Adriano dos Santos Fernandes wrote:
Later I'll improve it for C and FPC and put in my github.
Don't forget about Java and C#.
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
On 12/08/2014 14:59, Dimitry Sibiryakov wrote:
12.08.2014 19:54, Adriano dos Santos Fernandes wrote:
Later I'll improve it for C and FPC and put in my github.
Don't forget about Java and C#.
I'll not forget, if I want to do.
Adriano
On 12-8-2014 19:59, Dimitry Sibiryakov wrote:
12.08.2014 19:54, Adriano dos Santos Fernandes wrote:
Later I'll improve it for C and FPC and put in my github.
Don't forget about Java and C#.
I don't think those are directly relevant. I would think that the only
people who would ever use a
On Aug 12, 2014, at 1:37 PM, Mark Rotteveel wrote:
On 12-8-2014 18:48, Tom Coleman wrote:
One bias of mine that I will confess to is that I hate C++. Every time I
am forced to use it it turns out to be a horrible PITA. The last project I
wrestled with was an interface from our
12.08.2014 20:41, Mark Rotteveel wrote:
Don't forget about Java and C#.
I don't think those are directly relevant. I would think that the only
people who would ever use a direct interface from Java and C# are Jiri
and me, all normal application developers will simply use the JDBC
driver
Hi!
Some note from an outsider view.
#1 : both client plugin API MUST support C-tyle
API (lowest common dominator)
- standard data types, zero terminated strings,
pointers/handles, records, stdcall/cdecl functions, NO
objects/interfaces
-
11.08.2014 9:12, Molnár Attila wrote:
#3 : client plugin OO API
- only C++ developers can use is (small part of the whole user base pie)
It is not true. Common Object Model is supported not only in C++ compilers.
Current
problem is the result of two factors:
1) Our object hierarchy
On 08/08/14 20:40, Jim Starkey wrote:
On Aug 8, 2014, at 9:05 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 08/08/2014 08:52, Jim Starkey wrote:
So, if I understand your original goals, again as an outsider, I would have
to say that your current interface proposal does
Lets see the next scenatios
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like
fields)1
- host has to support reference counting2
#2 : API call parameterised by a host created object
BTW API and host has different (can't have) class information (class
pointer, VMT, etc..) for the same object, so by definition they not
communicate with the SAME class. The classes could have same name,
and can act the same, but the equality operation would give you
11.08.2014 10:49, Molnár Attila wrote:
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like fields)^1
- host has to support reference counting^2
#2 : API call parameterised by a host created object
- see #1
1 :
11.08.2014 10:59, Molnár Attila wrote:
So basicly pure Object based API is off the table.
Interface based might be good, and we ended up with COM.
Funny that you said that. Following article makes clear that they are
exactly the same:
http://www.codeproject.com/Articles/338268/COM-in-C
--
Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär:
10.08.2014 13:55, Reinier Olislagers wrote:
However, apparently FB devs don't think it's important to keep it in
sync with the C++ interface - even if third parties could submit patches
for that.
So in effect, new FB (features) will not be
So this Interface is not designed and made for clinet component
developers and communicatin with server but just for Firebird engine
inside use?
In that case just do what you want. ;)
On 2014.08.11. 11:05, Dimitry Sibiryakov wrote:
Remember, that new API wasn't designed as a public API. It
On 11/08/2014 05:43, Alex Peshkoff wrote:
Technical issues can, in fact, be discussed with more depth than +1. In
fact, everything in engineering is a tradeoff, and tradeoffs can be
reasonably balanced and discussed. But dismissing something that you don't
agree with as abstract bullshit
On 11/08/2014 06:04, Kjell Rilbe wrote:
Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär:
10.08.2014 13:55, Reinier Olislagers wrote:
However, apparently FB devs don't think it's important to keep it in
sync with the C++ interface - even if third parties could submit patches
for that.
So in
On 11/08/2014 06:25, Molnár Attila wrote:
So this Interface is not designed and made for clinet component
developers and communicatin with server but just for Firebird engine
inside use?
In that case just do what you want. ;)
He's totally wrong on this!
Adriano
53e74645.6000...@ibphoenix.com
Message-ID: a2df4a7f7c30f812d5f98c4057c3a...@imap.procolix.com
X-Sender: m...@lawinegevaar.nl
User-Agent: RoundCube Webmail/0.2
On Sun, 10 Aug 2014 12:15:33 +0200, Dimitry Sibiryakov s...@ibphoenix.com
wrote:
was a lot of languages (including Java and .NET in their
11.08.2014 12:47, Adriano dos Santos Fernandes wrote:
The hack approach dependent on compilers details is the one we use
currently.
Currently used pure abstract classes are exactly like in COM. And The
Component Object
Model specifies a *programming-language-independent _binary standard_
Adriano, this is a completely inappropriate response. If you think he is
wrong, you must explain exactly why he is wrong. While reasoning carries
weight, person opinions do not.
So, if you think he is wrong, olease elaborate.
On Aug 11, 2014, at 7:48 AM, Adriano dos Santos Fernandes
On 08/11/14 14:52, Mark Rotteveel wrote:
IIRC, calling C interfaces from Java code (using JNI), has been possible
from Java 1 (or maybe 1.1), but most Java developers don't want to deal
with native dependencies in their applications. That in itself is the main
reason to write against a wire
11.08.2014 15:36, Dimitry Sibiryakov wrote:
11.08.2014 13:39, Vlad Khorsun wrote:
As you already 'discovered' absence
of not needed QueryInterface in our classes, you should understand why it
was not a mistake.
It wasn't a mistake for Delphi only. It failed for FPC.
I don't have
11.08.2014 14:37, Alex Peshkoff wrote:
hide reference counters under
the hood as well as dealing with exceptions.
Both not acceptable for us
Why? Do you insist on manual calling of Release by cruelty only or you have
some
technical reasons?
Will it be OK to return E_NOINTERFACE to
On 11/08/2014 09:45, Alex Peshkoff wrote:
On 08/08/14 20:47, Adriano dos Santos Fernandes wrote:
At least I have time to answer tech question. What a luck!
Sure.
Automatic vtable upgrade is ok for me, provided we have a trust-able and
reliable way to add them.
Attached a demo for it,
53e8afd3.3010...@mail.ru
Message-ID: 37c270dc067e4e9904bdcf9108c6f...@imap.procolix.com
X-Sender: m...@lawinegevaar.nl
User-Agent: RoundCube Webmail/0.2
On Mon, 11 Aug 2014 15:58:11 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On 08/11/14 14:52, Mark Rotteveel wrote:
IIRC, calling C interfaces
On 08/11/14 16:57, Adriano dos Santos Fernandes wrote:
But there may be more cases, like passing a [in]/out parameter, but may
be possible in C++.
May you be a bit more explicit here?
If it's about passing interface as parameter - yes, version
check/upgrade is needed here.
But I do not
Since plugins pretty much need to be compiled with the same compiler as the
engine, and since both COM objects and their clients will be compiled from the
machine generated interface defintion headers, there is no danger of
incompatibilities even if there are compilers incompatible with
11.08.2014 18:18, Jim Starkey wrote:
Since plugins pretty much need to be compiled with the same compiler as the
engine
Very questionable requirement. I can easily expect plugins written in
Delphi.
Dmitry
--
On 11/08/2014 11:18, Jim Starkey wrote:
Since plugins pretty much need to be compiled with the same compiler as the
engine,
Hum??
and since both COM objects and their clients will be compiled from the
machine generated interface defintion headers, there is no danger of
incompatibilities
11.08.2014 17:47, Dmitry Yemanov wrote:
11.08.2014 18:18, Jim Starkey wrote:
Since plugins pretty much need to be compiled with the same compiler as the
engine
Very questionable requirement. I can easily expect plugins written in
Delphi.
Agree. More, there is no reason to use same C++
On 11/08/2014 11:49, Adriano dos Santos Fernandes wrote:
COM is full of problems:
Also, the our-IDL compiler may generate COM (complex) wrapper code for
our interfaces (simple).
Doesn't this kill the argument to use something that does not really fit
well as an internal API?
Then if Delphi or
11.08.2014 16:49, Adriano dos Santos Fernandes wrote:
COM is full of problems:
- UTF16
- HRESULT with TLS access to errors
Could you point out where COM specification is forcing usage of UTF16 and
TLS for HRESULT?
--
WBR, SD.
Before this goes much further, can someone confirm that COM is
compatible with Linux. I was always under the impression that it was a
Windows only technology. Googling the subject does not come up anything
other than DCOM and a lot of negative comments on COM.
COM is full of problems:
- UTF16
This COM business has caught me off guard so let me be the first to admit that
I don't know much about it.
But if there's no Linux support for COM it would be dead on arrival as far as I
would be concerned.
(My contact looking to get out of Delphi is also looking for a way to dump
8:26 AM
To: firebird-devel@lists.sourceforge.net
Subject: Re: [Firebird-devel] New Interface
Before this goes much further, can someone confirm that COM is compatible
with Linux. I was always under the impression that it was a Windows only
technology. Googling the subject does not come up anything
11.08.2014 17:26, Tony Whyman wrote:
Before this goes much further, can someone confirm that COM is
compatible with Linux. I was always under the impression that it was a
Windows only technology. Googling the subject does not come up anything
other than DCOM and a lot of negative comments on
On Aug 11, 2014, at 11:49 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
COM is full of problems:
- UTF16
- HRESULT with TLS access to errors
- No real OOP, just object composing with QueryInterface
- Ref. counting for all sorts of objects
This what I mean by
1 - 100 of 273 matches
Mail list logo
