Dmitry, All,
I am really sorry I broke the build and could not fix it quickly.
My luck has been really bad lately. I will test builds better next time.
My mail client is broken now, so I cannot respond to your letter (I can only
read mail via SF for now).
1) I defined FB_SIZE_T in types_pub
22.07.2014 0:03, Tony Whyman wrote:
The problem that you have when accessing the current FB3 API from
another programming language is that you have to make assumptions about
the vtable layout of the C++ compiler used to compile the shared object
and somehow map it into your programming
On 22/07/14 01:10, Jim Starkey wrote:
snip
The argument that a pure virtual interface is compiler specific has no merit.
The various C++ implementations have take the necessary and obvious steps so
that object modules compiled with different compilers cannot be mixed. There
is no risk
On 07/22/14 01:49, Nikolay Samofatov wrote:
Dmitry, All,
I am really sorry I broke the build and could not fix it quickly.
My luck has been really bad lately. I will test builds better next time.
My mail client is broken now, so I cannot respond to your letter (I can only
read mail via SF
22.07.2014 11:48, Alex Peshkoff wrote:
1) I defined FB_SIZE_T in types_pub because when somebody (Vlad?) ported my
code into Firebird he
made Trace API use size_t quantities in public interfaces. I used
ntrace_size_t (defined as
unsigned int).
This type can become private as soon Trace
On 07/22/14 04:10, Jim Starkey wrote:
I do have some questions:
1. Does it reflect a plan to introduce schemas, i.e. two level name spaces.
Yes. It's designed to be expandable to as many new field properties as
will be needed in the future.
It not, it should be rejected out of hand. The
On 07/22/14 13:58, Dimitry Sibiryakov wrote:
22.07.2014 11:48, Alex Peshkoff wrote:
1) I defined FB_SIZE_T in types_pub because when somebody (Vlad?) ported my
code into Firebird he
made Trace API use size_t quantities in public interfaces. I used
ntrace_size_t (defined as
unsigned int).
22.07.2014 12:27, Alex Peshkoff wrote:
Reviewing API from this POV I've found 2 plain structures.
You missed message data buffer which IS a plain structure of non-documented
structure.
--
WBR, SD.
--
Want fast
On 07/21/14 19:08, Dimitry Sibiryakov wrote:
01.07.2014 20:05, Alex Peshkoff wrote:
And out of curiosity: what IPluginModule::getModule() is supposed to
return and why it
may be called at all?
self
More interesting question: what is returned by getModule() from internal
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity - besides that, we must neither use virtual destructors
nor overloaded methods to guarantee the stable vtable layout.
Dmitry
22.07.2014 12:31, Alex Peshkoff wrote:
See Nickolay's comment in types_pub.h, line 65.
Instead of fixing handling 32 bits internally without any bounds checking
he decided
to pollute interface with types defined not by purpose, but by bitness. IMHO,
this is a
wrong decision and it
On 07/22/14 14:41, Dmitry Yemanov wrote:
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity - besides that, we must neither use virtual destructors
Definitely not.
Instead dtor release()
On 07/22/14 14:44, Dimitry Sibiryakov wrote:
22.07.2014 12:31, Alex Peshkoff wrote:
See Nickolay's comment in types_pub.h, line 65.
Instead of fixing handling 32 bits internally without any bounds
checking he decided
to pollute interface with types defined not by purpose, but by bitness.
22.07.2014 12:55, Alex Peshkoff wrote:
On 07/22/14 14:44, Dimitry Sibiryakov wrote:
Instead of fixing handling 32 bits internally without any bounds
checking he decided
to pollute interface with types defined not by purpose, but by bitness.
IMHO, this is a
wrong decision and it
On 22/07/2014 07:54, Alex Peshkoff wrote:
On 07/22/14 14:41, Dmitry Yemanov wrote:
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity - besides that, we must neither use virtual destructors
22.07.2014 12:59, Dimitry Sibiryakov wrote:
You will have the same
problem on platforms/compilers where int is 64 bits wide.
http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
--
WBR, SD.
--
Want
22.07.2014 14:54, Alex Peshkoff wrote:
Not sure how does presence of overloaded methods affect stability of
vtable layout, but agree that we should better avoid them in public
interfaces.
Even if you put an overloaded method at the end of the interface, its
vtable entry will be placed in the
22.07.2014 14:44, Dimitry Sibiryakov wrote:
Instead of fixing handling 32 bits internally without any bounds checking
In general, I don't like platform dependent datatypes in the public API,
hence my objections to size_t. (*)
The problems, as I see them, are:
1) It may complicate client
Two steps. First, define a pure virtual interface for C++. Second, machine
generate a flat, i.e. non-object interface for other languages.
Each will be easier to use that the current proposal from any language.
On Jul 22, 2014, at 5:11 AM, Tony Whyman tony.why...@mccallumwhyman.com
On 07/22/14 15:03, Adriano dos Santos Fernandes wrote:
On 22/07/2014 07:54, Alex Peshkoff wrote:
On 07/22/14 14:41, Dmitry Yemanov wrote:
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity
Public interface objects should be reference counted with a protected virtual
destructor.
There are no issues with overloaded functions, though they do complicate the
mapping from object method to flat function names. On balance, it's probably
best to avoid them.
Rtti is intended to salvage
Why do you care? The vtable is an implementation artifact that by design and
architecture is invisible.
Stop trying to be cute. Use the language in the manner it was designed to be
used.
In nearly two decades of heavy C++, the only time I've even look at it is the
JVM side of JNI.
If you
22.07.2014 13:12, Dmitry Yemanov wrote:
The problems, as I see them, are:
1) It may complicate client programs if their compiler misses a 100%
analogue. One might need to introduce conditional compilation etc.
IF their compiler don't provide some types, then it is THEIR problem. Don't
try
On 07/22/14 15:04, Dimitry Sibiryakov wrote:
22.07.2014 12:59, Dimitry Sibiryakov wrote:
You will have the same
problem on platforms/compilers where int is 64 bits wide.
http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
Are you serious that we should take into an account
My current AmorphousDB API (pure virtual) is defined without destructors. It
compiles and works just fine on Visual Studio 10 and whatever the current gcc
is on Linux.
Earlier versions of the compilers required the the inline definition of a
protected destructor to compile without warning.
22.07.2014 15:31, Jim Starkey wrote:
Why do you care?
If the C++ interface (pure virtual) is expected to be used outside the
Firebird project (by other C++ applications) or even by different
Firebird versions (e.g. newer server loading the older engine), then we
must care. You cannot extend
22.07.2014 13:31, Alex Peshkoff wrote:
Are you serious that we should take into an account such exotic as HAL
Computer Systems port of Solaris to SPARC64?
Yes.
Let me once more citate from that page:
Many 64-bit platforms today use an LP64 model (including Solaris, AIX,
HP-UX, Linux, OS
On 07/22/14 16:40, Dimitry Sibiryakov wrote:
22.07.2014 13:31, Alex Peshkoff wrote:
Are you serious that we should take into an account such exotic as HAL
Computer Systems port of Solaris to SPARC64?
Yes.
Let me once more citate from that page:
Many 64-bit platforms today use an LP64
22.07.2014 15:12, Alex Peshkoff wrote:
OK, but if we want to take into an account systems with 64-bit int the
only solution is artificial types? Like FB_SIZE_T?
Yes, but definitely not like FB_SIZE_T.
I would say that if there is no standard type that describe the purpose of
the type
On 07/22/14 17:23, Dimitry Sibiryakov wrote:
22.07.2014 15:12, Alex Peshkoff wrote:
OK, but if we want to take into an account systems with 64-bit int the
only solution is artificial types? Like FB_SIZE_T?
Yes, but definitely not like FB_SIZE_T.
I would say that if there is no
22.07.2014 15:33, Alex Peshkoff wrote:
It was said many times - size_t is very good thing, but we often do not
support such sizes internally. Please do not suggest to add such support
right now - or we will delay fb3 release more and more.
You don't need to add such support right now. It
Alex,
2) Re loop counters: In counter-based loops the best and fastest datatype is
int. It is obviously
faster than unsigned int/ULONG/FB_SIZE_T, whatever. You can use the latter
interchangeably, and
this is appropriate for current code base.
Why is 'int' faster than 'unsigned'?
Very
Alex,
On 07/22/2014 09:33 AM, Alex Peshkoff wrote:
On 07/22/14 17:23, Dimitry Sibiryakov wrote:
22.07.2014 15:12, Alex Peshkoff wrote:
OK, but if we want to take into an account systems with 64-bit int the
only solution is artificial types? Like FB_SIZE_T?
Yes, but definitely not like
22.07.2014 18:41, Nikolay Samofatov wrote:
I can give you some examples where using size_t is not supported:
- Win32 API (DWORD for sizes)
- standard C library - e.g. printf - (int for sizes)
- ICU library (int32_t type from C/C++ standard for sizes)
- libtommath (int for sizes)
- Firebird's
Alex, All,
On 07/22/2014 12:41 PM, Nikolay Samofatov wrote:
Not so smart people use unsigned 32-bit integers.
... One more note on why using unsigned 32-bit integer in interface is not
perfect choice:
There is no such data type in Java and other higher-level languages.
So what do you propose
22.07.2014 18:51, Nikolay Samofatov wrote:
There is no such data type in Java and other higher-level languages.
So what do you propose such people to use when interfacing with Firebird?
Didn't I mentioned LUA which has no integer type at all?..
--
WBR, SD.
A very good rule of thumb is to never use int when defining stuff. Use int32_t
or int64_t or a project equivalent. If you don't no which, you shouldn't be
defining anything. Use of int is fine when iterating over something that is
absolutely never going to overflow.
I agree that size_t has
Having given this a little more thought, I'm going to reverse myself. Size_t
is very convenient for passing lengths, not because it reflects the pointer
size or that any rational structure is likely to be greater than 2GB, but
because it allows the difference of two pointers to be passed
because it allows the difference of two pointers to be passed without a
cast.
To be pedantic about it, differences in pointers are of type ptrdiff_t, not
size_t, and I remember platforms where they weren't the same.
It may be that these platforms are uninteresting from our perspectives.
Steve
39 matches
Mail list logo
