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 src/tests/t
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
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 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 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.
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 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
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
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
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
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 variabl
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
Vio
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
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 conventi
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%e
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
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 at
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 Firebi
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: http://b
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
r
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
Carlos H. Cantu wrote Thu, 14 Aug 2014 03:29:51
+0400:
>
> So, IMHO, we need to do whatever needs to be done, but in a way that
> will not delay FB 3 anymore. I know all of our core developers are
> working as hard as they can, sorry if I'm putting some pressure, but
> that's how I'm feeling th
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
> You all think alpha versions and snapshot
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 ge
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.
>
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 wa
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 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
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 w
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 don't
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, whi
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
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 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:
>>
>>
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 stabl
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 curren
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
> we
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 across compilers/platforms?
Becaus
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
> w
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.
>
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.
--
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.
>> 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 functi
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
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
> classes. But as long as we do not talk about implementations t
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 mod
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 t
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 interf
AdSF> I asked for one to test the thing I do for FPC, but seems our "Delphi
AdSF> community" is not here.
Contact me in private and I'll try to help. I didn't answer before
because I'm totally busy with the FDD arrangements + customers
requests, but I'll see what I can do.
PS: My Delphi version 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 tur
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
wrest
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
> dr
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 pro
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 u
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
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
https
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
>> wrestled with was an interface from our proprietary l
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 proprietary language to ApacheMQ, and
> the only interface a
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 - an
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 bur
> On Aug 12, 2014, at 1:11 PM, Jim Starkey 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
> encapsulated
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 t
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 mec
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 vect
On 08/12/14 13:55, Mark Rotteveel wrote:
> On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff
> wrote:
>>> On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff
>>> wrote:
On 08/11/14 22:29, Tom Coleman wrote:
> I interface a proprietary language with Firebird, Oracle, and
> Sybase/MS-SQL
On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff
wrote:
>> On Tue, 12 Aug 2014 10:37:21 +0400, 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
On 08/12/14 12:13, Mark Rotteveel wrote:
> <53e9b621.5050...@mail.ru>
> Message-ID:
> X-Sender: m...@lawinegevaar.nl
> User-Agent: RoundCube Webmail/0.2
>
> On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff
> wrote:
>> On 08/11/14 22:29, Tom Coleman wrote:
>>> I interface a proprietary language w
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 t
On 12/08/14 09:13, Mark Rotteveel wrote:
> <53e9b621.5050...@mail.ru>
> Message-ID:
> X-Sender: m...@lawinegevaar.nl
> User-Agent: RoundCube Webmail/0.2
>
> On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff
> wrote:
>> On 08/11/14 22:29, Tom Coleman wrote:
>>> I interface a proprietary language
12.08.2014 10:16, Alex Peshkoff wrote:
>> Say, I have in application Firebird exception class with following
>> members: gdscode,
>> >SQLCode, text, origin. How your templates will know what values set to
>> >these members
>> >before throwing?
>> >
> May be IBPP sources can help you answer y
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 Fire
<53e9b621.5050...@mail.ru>
Message-ID:
X-Sender: m...@lawinegevaar.nl
User-Agent: RoundCube Webmail/0.2
On Tue, 12 Aug 2014 10:37:21 +0400, 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
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,
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 bury
12.08.2014 8:34, Alex Peshkoff wrote:
> I.e. you suggest to have different interface on different borders.
> Afraid you will soon say that it makes overall system much cleaner
Cleaner - may be no: garbage code will be just swept from core to borders.
Faster - yes: one parameter less on each
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 pa
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
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
>> much -- or as little as the user needs. So
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: outer world, Y-valve, providers, plugins. What I
On 11/08/2014 16: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
>> much -- or as little as the user needs.
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
> much -- or as little as the user needs. Sometimes an error code is enough,
> sometime
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 much
-- or as little as the user needs. Sometimes an error code is enough,
sometimes a full formatted compound message is required.
But a secon
On 11/08/2014 16:37, Dimitry Sibiryakov wrote:
> 11.08.2014 21:28, Adriano dos Santos Fernandes wrote:
>> No. Providers and plugins should work when compiled by different
>> compilers and being in different libraries!
>That's why border guards must stay between engine and plugins. As well as
>
11.08.2014 21:28, Adriano dos Santos Fernandes wrote:
> No. Providers and plugins should work when compiled by different
> compilers and being in different libraries!
That's why border guards must stay between engine and plugins. As well as
between
Y-valve and outer world. Guards between Y-va
On 11/08/2014 16:19, Dimitry Sibiryakov wrote:
> 11.08.2014 21:13, Adriano dos Santos Fernandes wrote:
>> An integrated approach (who throws from IStatus, catchs and set IStatus)
>> is very welcome.
>I would suggest a very simple approach: push IStatus out of engine, just
> throw
> exceptions
11.08.2014 21:13, Adriano dos Santos Fernandes wrote:
> An integrated approach (who throws from IStatus, catchs and set IStatus)
> is very welcome.
I would suggest a very simple approach: push IStatus out of engine, just
throw
exceptions there. Leave catching and converting exceptions into IS
On Aug 11, 2014, at 2:40 PM, 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
On 11/08/2014 16:03, Dmitry Yemanov wrote:
>
> We either forget about exceptions completely, or throw some partially
> abstract class (thus forcing users to implement the exception before
> being able to compile), or maybe go for the policies you described.
>
> That said, I'd rather resolve the o
11.08.2014 22:08, Adriano dos Santos Fernandes wrote:
> But an (client) application wants to generate exception when accessing
> the API, and we do not know in advance what's the good classes for each
> project.
And we'll never know. This is not our business, IMO.
> Some may use like Firebird, a
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 idea that is looking
> more and more like a sacred
11.08.2014 20:20, Jim Starkey wrote:
> A COM solution would be to have all methods return a COM object (null for
> success if no succes return is required), which could be either a proper
> result object or an error object. But it would require a queryInterface to
> determine which. There othe
On Aug 11, 2014, at 12:06 PM, Lester Caine wrote:
> On 11/08/14 12:53, Alex Peshkoff wrote:
>>> IBPP can
still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would
act the same for Delphi, etc. They just need to be ported to the new
core API (whatever it will be).
>> I
Exceptions are clearly an issue. Exception handling is specific to the C++
runtime and can't be handled by other languages. This is specific to COM
however, it applies to all cross language interfaces.
A COM solution would be to have all methods return a COM object (null for
success if no suc
On 11/08/2014 15:00, Dimitry Sibiryakov wrote:
> 11.08.2014 19:55, Adriano dos Santos Fernandes wrote:
>> What's your point?
>No exception is allowed to cross alien boundaries. Only modules built with
> the same
> compiler can throw and catch exceptions. Such modules has no problems you are
11.08.2014 19:55, Adriano dos Santos Fernandes wrote:
> What's your point?
No exception is allowed to cross alien boundaries. Only modules built with
the same
compiler can throw and catch exceptions. Such modules has no problems you are
talking
about, so no hand-made unwind is needed.
--
On 11/08/2014 14:51, Dimitry Sibiryakov wrote:
> 11.08.2014 19:29, Adriano dos Santos Fernandes wrote:
>> Another requirement not yet mentioned for C++ users, are exceptions.
>Worth reading before jumping in:
>
> http://tdm-gcc.tdragon.net/quirks
> https://gcc.gnu.org/wiki/WindowsGCCImprovement
11.08.2014 19:29, Adriano dos Santos Fernandes wrote:
> Another requirement not yet mentioned for C++ users, are exceptions.
Worth reading before jumping in:
http://tdm-gcc.tdragon.net/quirks
https://gcc.gnu.org/wiki/WindowsGCCImprovements
https://www.usenix.org/legacy/events/osdi2000/wiess200
Ok, I got it. I stand corrected.
For the record, when I invented UDFs, neither C++ nor Delphi existed. Hell, C
didn't even have function prototypes.
> On Aug 11, 2014, at 1:58 PM, "Carlos H. Cantu" wrote:
>
> DY> Very questionable requirement. I can easily expect plugins written in
> DY>
Another requirement not yet mentioned for C++ users, are exceptions.
While we can easily just convert IStatus to Exception, if Exception is a
FB class, not even derived from std::exception, it may be completely
inappropriate for users applications.
You know, each C++ project has its own requireme
DY> Very questionable requirement. I can easily expect plugins written in
DY> Delphi.
DY> Dmitry
++1, as it already happens with UDFs (lots of them coded in Delphi).
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
DY> 11.08.2014 18:18, Jim Starkey wrote:
>> Since pl
1 - 100 of 317 matches
Mail list logo
