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
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 lis...@warmboot.com.br wrote:
DY Very questionable requirement. I can easily expect plugins
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
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/WindowsGCCImprovements
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 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
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
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 agree with this
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 other
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 cow?
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, an
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 other
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 thinking
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
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 there.
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
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
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
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,
sometimes a
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. Sometimes
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
10.08.2014 5:09, Adriano dos Santos Fernandes wrote:
From this pointer, however, the vtable is not compatible with C++.
But we can autogenerate classes for good usage in Delphi/FPC if we put a
dummy pointer both in our vtable (the template demo) and in object
instances.
If class layout in
10.08.2014 07:09, Adriano dos Santos Fernandes wrote:
I did some tests and detected that FPC class with or without virtual
methods has a pointer in its start.
From what I've seen on the web, there should be three pointers there.
But maybe it depends on the compiler settings or other reasons
10.08.2014 10:00, Dmitry Yemanov wrote:
From what I've seen on the web, there should be three pointers there.
But maybe it depends on the compiler settings or other reasons (like for
RTTI and multiple inheritence in gcc).
One of settings that must be taken into account:
10.08.2014 10:00, Dmitry Yemanov wrote:
From what I've seen on the web, there should be three pointers there.
Sure: they are QueryInterface, AddRef, releaseRef.
Worth reading, especially comments:
http://sergworks.wordpress.com/2011/12/08/why-we-need-interfaces-in-delphi/
--
WBR,
10.08.2014 10:20, Dimitry Sibiryakov wrote:
they are QueryInterface, AddRef, releaseRef.
Oops, I was too quick. Here are details:
http://www.freepascal.org/docs-html/prog/progsu167.html#x211-2240008.2.12
http://www.freepascal.org/docs-html/prog/progsu168.html#x212-2250008.2.13
--
WBR,
On 10/08/2014 09:48, Dimitry Sibiryakov wrote:
10.08.2014 5:09, Adriano dos Santos Fernandes wrote:
From this pointer, however, the vtable is not compatible with C++.
If class layout in FPC is incompatible with C++, it is FPC problem.
They must either fix their layout or implement
10.08.2014 10:34, Reinier Olislagers wrote:
If not, it seems quite drastic to require C++ compatibility for
languages that may not even have C++ compatibility envelopes
Compatibility and interoperability are right things. Implementing them is a
gain for
every compiler/language in the
10.08.2014 12:34, Reinier Olislagers wrote:
Do I understand correctly that the existing FB 2.5 C API will therefore
remain supported
Correct.
and updated with new features for each FB release?
Not necessarily correct.
Dmitry
On 10/08/2014 10:40, Dimitry Sibiryakov wrote:
10.08.2014 10:34, Reinier Olislagers wrote:
If not, it seems quite drastic to require C++ compatibility for
languages that may not even have C++ compatibility envelopes
Compatibility and interoperability are right things. Implementing them is
10.08.2014 11:09, Dmitry Yemanov wrote:
and updated with new features for each FB release?
Not necessarily correct.
It is an open project, no?..
When C API missed a new feature that I could use, I created a patch,
submitted it to
the project and now C API _does_ support a new feature I
On 10/08/2014 11:44, Dimitry Sibiryakov wrote:
10.08.2014 11:11, Reinier Olislagers wrote:
Of course, my view is that it should be the other way round: FB should
be compatible with languages, but your answer is clear enough.
It is compatible. It's C++ interface is compatible with MSVC and
10.08.2014 13:48, Dimitry Sibiryakov wrote:
It is an open project, no?..
It is. But open unmanaged.
When C API missed a new feature that I could use, I created a patch,
submitted it to
the project and
it may be either accepted or rejected. Because you may disappear
tomorrow but the
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.
This is not true
Regards,
Vlad
--
Firebird-Devel mailing
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 compatible with any language
that does not have C++
10.08.2014 12:01, Dmitry Yemanov wrote:
it may be either accepted or rejected. Because you may disappear
tomorrow but the project will have to maintain your patch till the end
of life.
Anyone may disappear tomorrow. A human being to be mortal is not a problem.
The
problem is that
I think it is universally accepted that the Firebird interfaces should be OO.
I would like to remind folks that there are at least two ways to do this. One
is to define the interface in an OO language. But, as has been widely argued,
this is impossible to make compatible across the various
On 10/08/2014 12:04, Dmitry Yemanov wrote:
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
10.08.2014 12:04, Dmitry Yemanov 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 compatible with any language
that does not have C++
10.08.2014 12:10, Jim Starkey wrote:
Leverage what you have. Implement language specific interface class wrappers
on the original handle based flat interface. Then extend this to support
user friendly, industry standard interface semantics, e.g. JDBC, to attract
new users.
When I told
10.08.2014 14:09, Dimitry Sibiryakov wrote:
Whole project is inherited, remember?.. You have to maintain code written by
Jim, Mike,
Arno, Nikolay and others, so why not mine?..
Everything depends on the patch. There's a difference between *can* be
accepted and *will* be accepted. If you
10.08.2014 14:10, Jim Starkey wrote:
It is a fool's errand to try to build a OO interface that is call compatible
across a wide range of OO languages. If anyone is in doubt, look at
Objective-C and weep.
If this is found being impossible (I'm not deeply involved, so I don't
have a
10.08.2014 14:02, Dmitry Yemanov wrote:
If this is found being impossible
IMHO, it is possible, but not by reinventing VMT for everyone: users of
incompatible
compilers just have to use structures and pointers to emulate standard VMT.
Democracy
works in this case.
1) Do we keep the
Dmitry, these questions are a good starting point.
To design (or select) an interface, you must start with a solid idea of who the
users will be, their skill level, how they will use it, and where you want to
go with the product.
For example, the original interface targeted two classes of
On 10-08-2014 07:15, Dimitry Sibiryakov wrote:
10.08.2014 12:04, Dmitry Yemanov 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
10.08.2014 17:12, Adriano dos Santos Fernandes wrote:
Writing wrappers around handlers is just something that does not make
sense in the easy-of-use point of view. If you disagree, I'm waiting for
your prototype here!
Why a prototype? FIB+, IBX, UIB, IBObject - all of them are wrappers
On 10-08-2014 12:45, Dimitry Sibiryakov wrote:
10.08.2014 17:41, Adriano dos Santos Fernandes wrote:
And none of this are passed from your library to Firebird, i.e.,
plugins, external routines.
When will you start to separate application API and plugin API?..
I do not see any sane
10.08.2014 19:45, Dimitry Sibiryakov wrote:
When will you start to separate application API and plugin API?..
UDRs must use a regular application API for callbacks into the engine,
this is a design requirement.
Dmitry
10.08.2014 17:50, Adriano dos Santos Fernandes wrote:
I do not see any sane reason to create two flavor of APIs for a thing
which must be integrated.
They mustn't. End user application doesn't work with plugins. It works with
Y-valve
(and in the worst case - with a provider directly).
10.08.2014 17:55, Dmitry Yemanov wrote:
UDRs must use a regular application API for callbacks into the engine,
this is a design requirement.
Right. But use API and has API are different things. I don't understand
why Adriano
ties them into one.
--
WBR, SD.
On 10-08-2014 05:30, Dimitry Sibiryakov wrote:
10.08.2014 10:20, Dimitry Sibiryakov wrote:
they are QueryInterface, AddRef, releaseRef.
Oops, I was too quick. Here are details:
http://www.freepascal.org/docs-html/prog/progsu167.html#x211-2240008.2.12
10.08.2014 18:07, Adriano dos Santos Fernandes wrote:
What I'm actually saying is that inserting a dummy entry in instances
and vtable, we make free for use our objects in the languages who uses
such layout with variations.
You can insert whatever to anything, but...
Delphi/Lazarus
On 10-08-2014 13:20, Dimitry Sibiryakov wrote:
10.08.2014 18:07, Adriano dos Santos Fernandes wrote:
What I'm actually saying is that inserting a dummy entry in instances
and vtable, we make free for use our objects in the languages who uses
such layout with variations.
You can insert
10.08.2014 18:31, Adriano dos Santos Fernandes wrote:
Why do you keep arguing about vtables if the thing you want is just not
see any change, because you do not want to re-write your applications to
use the new thing?
Hmmm, altruism, perhaps. I'm trying to save other's butt from the pain I
Let me tell a little more about this.
10.08.2014 17:55, Dmitry Yemanov wrote:
UDRs must use a regular application API for callbacks into the engine,
this is a design requirement.
It is a very reasonable requirement. But technically it means only two
things:
1) Provider (engine) must be
On Aug 10, 2014, at 12:12 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
Writing wrappers around handlers is just something that does not make
sense in the easy-of-use point of view. If you disagree, I'm waiting for
your prototype here!
Uh, I've done at least a dozen.
It has been pointed out that the client and plugin APIs are used by different
types of developers for different purposes. You didn't respond, so it's hard
to know whether you disagreed, didn't understand the point, or just didn't care.
There is no benefit to forcing two completely different
On 10-08-2014 15:29, Jim Starkey wrote:
It has been pointed out that the client and plugin APIs are used by different
types of developers for different purposes. You didn't respond, so it's hard
to know whether you disagreed, didn't understand the point, or just didn't
care.
There is no
10.08.2014 20:33, Adriano dos Santos Fernandes wrote:
It does not make any sense to write a COM-plugin that could just say,
hey, I'm a plugin and do nothing.
You seem don't understand one things about plugins: they don't need to do
anything but
respond to engine's calls. Exactly for this
09.08.2014 0:38, Adriano dos Santos Fernandes wrote:
As we tend to adopt an IDL processor, we tend to autogenerate these
Delphi/FPC classes in a way it 1) works 2) is good enough to use, like
the C++ binding.
Autogeneration has one disadvantage: it just a waste of time. You somehow
forged
All this heat is not useful. Yes, of course Delphi and Free Pascal use a
non-standard ABI. That's because there is no standard. Likewise, C++
compilers also have a non-standard ABI.
In the absence of standards all we can do is default to the lowest
common denominator and, in practice, that
On Aug 9, 2014, at 6:26 AM, Tony Whyman wrote:
All this heat is not useful.
Some heat is good. It's an indication of underlying passion, and one would
expect developers to be passionate about Firebird.
That passion however should not be about promoting one's own personal
programming
09.08.2014 19:13, Tom Coleman wrote:
It has to be channeled to benefit current and prospective users.
Current users don't care about API because they don't use it. They use all
kind of
envelopes which are already OO-oriented, tested by years and well documented.
Future users
also will use
09.08.2014 21:19, Dimitry Sibiryakov wrote:
It has to be channeled to benefit current and prospective users.
Current users don't care about API because they don't use it. They use all
kind of
envelopes which are already OO-oriented, tested by years and well documented.
Future users
also
Someone told abstract Delphi classes was compatible with the C++ vtable,
but FPC wasn't.
I did some tests and detected that FPC class with or without virtual
methods has a pointer in its start.
From this pointer, however, the vtable is not compatible with C++.
But we can autogenerate classes
On 08/07/14 21:29, Jim Starkey wrote:
Version number of what? The interface, the client implementation, the
protocol, the server, the engine, the ODS?
The interface.
--
Want fast and easy access to all the code in
On 08/07/14 20:44, Adriano dos Santos Fernandes wrote:
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
- Automatic version check (done only when necessary)
From code I see that it takes place on every invocation of every method.
I agree that adding
On 08/07/14 21:25, Jim Starkey wrote:
Just as a matter of curiosity, is there an agreed on set of requirements for
the new interface? If not, may I suggest that one be drawn up and discussed?
It's very hard to measure the success of a design without knowing what it is
supposed to do.
08.08.2014 13:20, Alex Peshkoff wrote:
but once again nobody of developers argued again.
I can tell why: everybody decided oh, it has nothing to do with me, no
point to read
so many letters.
--
WBR, SD.
--
As an outsider looking in, I think I understand how you got there but not the
there you got.
For openers, I don't understand what a plugin architecture has to do with the
primary database API. They are different beasts used for different purposes by
different types of developers. The demands
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 not meet them. Each step in
the progression may have seen logical, but the end result is not.
I'm resisting to reply to you
08.08.2014 14:05, Adriano dos Santos Fernandes wrote:
You actually seem to not even looked at the current code, interfaces or
proposed changes.
Believe me, I looked at proposed changes. It is an abomination.
It repeats the code that is already cleaned out of Y-valve, but is worse.
08.08.2014 13:20, Alex Peshkoff wrote:
avoid 16-bit limit on object sizes in API calls.
Do you know that every modern compiler (actually, processor) expand every
integer
function parameter to a full machine word? I.e. short in parameters is just a
syntax
sugar, they are pushed into stack
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 not meet them. Each step
in the
On 08/08/2014 07:45, Alex Peshkoff wrote:
On 08/07/14 20:44, Adriano dos Santos Fernandes wrote:
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
- Automatic version check (done only when necessary)
From code I see that it takes place on every invocation of
08.08.2014 18:47, Adriano dos Santos Fernandes wrote:
It works provided that who called the method that returned the new
object was compiled together (or with the same API version) of who is
calling the object method. In most of cases I'd imagine, this is true.
If this assumption is true,
On 08/08/2014 14:19, Dimitry Sibiryakov wrote:
08.08.2014 18:47, Adriano dos Santos Fernandes wrote:
It works provided that who called the method that returned the new
object was compiled together (or with the same API version) of who is
calling the object method. In most of cases I'd imagine,
08.08.2014 21:00, Adriano dos Santos Fernandes wrote:
Plugin manager? Everyone can create and return instances. Plugin manager
only loads main plugin objects.
Yes. It loads plugin library and fill table of methods. That's all what is
needed.
This architecture solves all problems with
On 08/08/2014 16:13, Dimitry Sibiryakov wrote:
In contrast, last Alex/me solution does not add memory and performance
problems (each call is a single virtual call) with a check (indirect
access) for upgrade when a function returns a new object.
Individual function table in every object
I fear that this project is getting bogged down in technical minutiae.
Please consider the numbers. Firebird's position in the RDB world is already
low and actually diminishing.
With this release you have the opportunity to broaden Firebird's appeal to a
wider audience. Will you accept
So you should be more humble when talking about things you do not know.
This is happening just because someone found the current implementation
to not work in FreePascal.
Firebird will continue to be implemented in C++. And be accessible by
any language. And this is what serious people are done
Hey guys - someone would also like to get this discussion back on track.
If there is anything that has come out of these discussions is the
importance of the Delphi/Free Pascal user base and the first requirement
for the FB3 API has to be to ensure that these users have an efficient
and easy to
On 08-08-2014 17:30, Dimitry Sibiryakov wrote:
08.08.2014 21:59, Adriano dos Santos Fernandes wrote:
This is happening just because someone found the current implementation
to not work in FreePascal.
Actually, this is happening just because someone though about C++ only...
Firebird
On 08/06/14 22:11, Adriano dos Santos Fernandes wrote:
Alex and All,
Based on Alex code, I did some changes (attached) to support:
- Avoid runtime crash if a method is missed in an implementation
- Avoid need to manually initialize the vTable
- Avoid preprocessor tricks
OK for all this. very
On 08/07/14 15:44, Adriano dos Santos Fernandes wrote:
On 07/08/2014 07:00, Alex Peshkoff wrote:
If we anyway need different ways to call different types of methods
why have all this underlines?
May be better do
void RefCounted::addRefCaller()
{
IRefCounted::addRef();
}
and let
07.08.2014 13:44, Adriano dos Santos Fernandes wrote:
Here you just mean to call the current (possibly inherited) addRef
method, but you need to prefix it with the interface name. And if you
don't, someone inheriting the implementation will have problems
difficult to understand. And it's a
07.08.2014 15:50, Dimitry Sibiryakov wrote:
where IInterfaceVMT is struct { void (*realMethod)(void*, IStatus*, a, b, c);
}
Oh, I forgot to write implementation of realMethod:
void realMethod(IInterface* this, IStatus* s, a, b, c)
{
try
{
this-Method(a, b,
On 07/08/2014 10:24, Alex Peshkoff wrote:
I can agree with your arguments provided you demonstrate a real world
sample where we need to inherit the implementation of interface. The
problem is that surprisingly named methods will be present always, but
need in implementation inheritance is
07.08.2014 16:16, Adriano dos Santos Fernandes wrote:
we should
have something good for general use, as not only us Firebird project
will have implementations, but plugins, etc.
You are too optimistic here.
--
WBR, SD.
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
- Automatic version check (done only when necessary)
- Marks (TODO) for C/C++ exception integration
With this versioning scheme, IVersioned will die, but I maintained it
for the demo.
As we don't rely on C++
Just as a matter of curiosity, is there an agreed on set of requirements for
the new interface? If not, may I suggest that one be drawn up and discussed?
It's very hard to measure the success of a design without knowing what it is
supposed to do.
Version number of what? The interface, the client implementation, the
protocol, the server, the engine, the ODS?
On Aug 7, 2014, at 1:44 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
-
I also think the version checks must be automatic at least in the C++
API, but calling getVersion in each call is not good.
It is not good but unavoidable in current plugin architecture. The first
thing that
every method of every interface have to do is to check versions of every
On 08/06/14 11:26, Dimitry Sibiryakov wrote:
I also think the version checks must be automatic at least in the C++
API, but calling getVersion in each call is not good.
It is not good but unavoidable in current plugin architecture. The first
thing that
every method of every interface
06.08.2014 10:19, Alex Peshkoff wrote:
You are wrong here. See releaseUpgradeTabs(IPluginModule*) function.
Ok, but when a third-party plugin must release tables for engine interfaces?
--
WBR, SD.
--
On 08/06/14 12:26, Dimitry Sibiryakov wrote:
06.08.2014 10:19, Alex Peshkoff wrote:
You are wrong here. See releaseUpgradeTabs(IPluginModule*) function.
Ok, but when a third-party plugin must release tables for engine
interfaces?
It must not do it. It will be done by plugin manager when
On 08/05/14 16:11, Adriano dos Santos Fernandes wrote:
On 05/08/2014 08:20, Alex Peshkoff wrote:
As the result we get language-neutral compiler-independent ABI, with an
ability to generate a kind of headers for any language, with a machine
generated code to catch exceptions into status vector
06.08.2014 11:48, Alex Peshkoff wrote:
I want to have warnings in IStatus separate from errors (keeping them in
same status vector IMO artifact of isc api). I think that after it this
is not big problem. Am I missing something obvious?
Yes. If not in the status, where should warnings be?
On 08/06/14 14:01, Dimitry Sibiryakov wrote:
06.08.2014 11:48, Alex Peshkoff wrote:
I want to have warnings in IStatus separate from errors (keeping them in
same status vector IMO artifact of isc api). I think that after it this
is not big problem. Am I missing something obvious?
Yes. If
06.08.2014 12:10, Alex Peshkoff wrote:
I've not said - not the status, I've said - in the status but separate
from errors. I.e. if you have now function get() returning mix of errors
and warnings, you will have getErrors() and getWarnings() instead.
I always thought that get() is a stub for
101 - 200 of 273 matches
Mail list logo
