On 04/14/11 07:36, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Alex Peshkoff [mailto:peshk...@mail.ru]
>> Sent: Miércoles, 13 de Abril de 2011 9:07
>> To: For discussion among Firebird Developers
>
>>void fini()
>>{
>>if (bufferLength)
> -Original Message-
> From: Alex Peshkoff [mailto:peshk...@mail.ru]
> Sent: Miércoles, 13 de Abril de 2011 9:07
> To: For discussion among Firebird Developers
>void fini()
>{
>if (bufferLength)
>{
>buffer = new u
On 04/13/11 10:58, Alex Peshkoff wrote:
> Certainly. I will add separate public .h for C++ wrappers over
> interface-based API.
Sorry, looks like I have nothing serious to add now :-) Your code
required almost no modification after moving all 4 parts of the message
to the single structure. FYI it
On 04/12/11 19:27, Adriano dos Santos Fernandes wrote:
> On 12-04-2011 04:13, Alex Peshkoff wrote:
>> Adriano, I do not wnat nitpicking. Moreover, I agree that my commit was
>> (not to say more) bad. But your initial solution with non-POD objects
>> in API was also bad. I have not understood - do
On 12-04-2011 04:13, Alex Peshkoff wrote:
>
> Adriano, I do not wnat nitpicking. Moreover, I agree that my commit was
> (not to say more) bad. But your initial solution with non-POD objects
> in API was also bad. I have not understood - do you see problems with
> replacing C++ classes with POD ob
On 04/11/11 21:00, Adriano dos Santos Fernandes wrote:
> On 11-04-2011 13:25, Alex Peshkoff wrote:
>> On 04/11/11 20:19, Adriano dos Santos Fernandes wrote:
>>> On 11-04-2011 13:15, Alex Peshkoff wrote:
On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
> On 11-04-2011 07:28, Alex P
On 11-04-2011 13:25, Alex Peshkoff wrote:
> On 04/11/11 20:19, Adriano dos Santos Fernandes wrote:
>> On 11-04-2011 13:15, Alex Peshkoff wrote:
>>> On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
On 11-04-2011 07:28, Alex Peshkoff wrote:
>> PS Alex will explain you why "struct" or
11.04.2011 20:04, Adriano dos Santos Fernandes wrote:
> Extending XSQLDA/XSQLVAR is like going backto SQLDA/SQLVAR. Plain ugly.
Luckily, it's not absolutely required in many cases. As you know, the
whole SQLDA stuff is a [supposedly] user-friendly wrapper for the
sql_info() call. We may easily
On 04/11/11 20:19, Adriano dos Santos Fernandes wrote:
> On 11-04-2011 13:15, Alex Peshkoff wrote:
>> On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
>>> On 11-04-2011 07:28, Alex Peshkoff wrote:
> PS Alex will explain you why "struct" or "class with data members" is
> bad for *por
On 04/11/11 19:20, Dmitry Yemanov wrote:
>> I can agree that reasonably designed structure can be made safe when
>> used in API. I can even suppose that it can be used from all actively
>> used programming languages. But when you need to add something to it -
>> you have problems.
> I'd say it's a
On 11-04-2011 13:15, Alex Peshkoff wrote:
> On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
>> On 11-04-2011 07:28, Alex Peshkoff wrote:
PS Alex will explain you why "struct" or "class with data members" is
bad for *portable* code.
>>> Taking into an account Dmirty's sample with X
On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
> On 11-04-2011 07:28, Alex Peshkoff wrote:
>>> PS Alex will explain you why "struct" or "class with data members" is
>>> bad for *portable* code.
>> Taking into an account Dmirty's sample with XSQLDA I must say that may
>> be not everything S
On 11-04-2011 12:09, Dmitry Yemanov wrote:
> 11.04.2011 18:04, Alex Peshkoff wrote:
>
>> Telling true, inability to extend XSQLDA in backward compatible
>> way was always obvious for everyone here.
>
> Only partially true. It's designed to be backward compatible and I don't
> see why it cannot w
On 11-04-2011 07:28, Alex Peshkoff wrote:
>
>> PS Alex will explain you why "struct" or "class with data members" is
>> bad for *portable* code.
>
> Taking into an account Dmirty's sample with XSQLDA I must say that may
> be not everything SO bad in this area. At least somehow it did work all
> t
On 11-04-2011 04:19, Alex Peshkoff wrote:
> On 04/09/11 19:44, Adriano dos Santos Fernandes wrote:
>> On 09-04-2011 08:58, Vlad Khorsun wrote:
On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
> Revision: 52693
> http://firebird.svn.sourceforge.net/firebird/?rev
11.04.2011 19:24, Dimitry Sibiryakov wrote:
> What does it do in ibase.h then?
It contains entrypoints public from the subsystem POV, but it's "hidden"
using the linkage (made server only). So it's not supported outside the
server, it's not delivered over the wire and thus it's not exported.
I
11.04.2011 19:11, Vlad Khorsun wrote:
They can be implemented in an old API as well.
>>>
>>> So far i know no plans to extend XSQLDA.
>>
>> I mentioned that a few times here and I still support extending XSQLDA
>> (to the extent it's still maintainable).
>
> Then i leave to you a "pleasure" t
11.04.2011 17:12, Dmitry Yemanov wrote:
> 11.04.2011 18:18, Dimitry Sibiryakov wrote:
>
>> Look at _already implemented_ API extension - fb_ping() and point me to it's
>> description in doc/ folder, please. None.
>
> FWIW, it's not a part of the public API. This symbol is not exported.
What doe
11.04.2011 14:23, Alex Peshkoff wrote:
> Dmitry, just please recall - how many times we said: sorry, this feature
> requires XSQLDA modification, this is serious API change, we will not do
> it this time.
Because we never wanted to change the public API in a big way (causing
serious adjustments
11.04.2011 16:52, Vlad Khorsun wrote:
> Did you noted descriptions of much more important new API's, such as
> fb_shutdown ?
What is it important for? Or, may be, you mean fb_cancel_operation(), not
fb_shutdown()?..
> Where are your ticket at the tracker, btw ?
Solve CORE-3382
11.04.2011 18:18, Dimitry Sibiryakov wrote:
> Look at _already implemented_ API extension - fb_ping() and point me to it's
> description in doc/ folder, please. None.
FWIW, it's not a part of the public API. This symbol is not exported.
Dmitry
--
>>> They can be implemented in an old API as well.
>>
>> So far i know no plans to extend XSQLDA.
>
> I mentioned that a few times here and I still support extending XSQLDA
> (to the extent it's still maintainable).
Then i leave to you a "pleasure" to answer on DS questions. It is enough
fo
11.04.2011 18:04, Alex Peshkoff wrote:
> Telling true, inability to extend XSQLDA in backward compatible
> way was always obvious for everyone here.
Only partially true. It's designed to be backward compatible and I don't
see why it cannot work. The only major problem there is the fixed size
of
11.04.2011 17:44, Vlad Khorsun wrote:
>> They can be implemented in an old API as well.
>
> So far i know no plans to extend XSQLDA.
I mentioned that a few times here and I still support extending XSQLDA
(to the extent it's still maintainable).
Dmitry
-
> 11.04.2011 15:44, Vlad Khorsun wrote:
>>>Not quite so. "Easy to write" (for me) means "use well documented API
>>> which has enough
>>> examples of usage". Nothig from this is applied to the new API.
>>
>> Do you have completed API somewhere ? Where do you read that API is
>> already c
11.04.2011 16:04, Alex Peshkoff wrote:
> Dimitry, can you be more specific here? Telling true, inability to
> extend XSQLDA in backward compatible way was always obvious for everyone
> here.
I can't believe that nobody saw IB implementation. XSQLDA has field
"version" exactly
for that purpose
11.04.2011 15:44, Vlad Khorsun wrote:
>>Not quite so. "Easy to write" (for me) means "use well documented API
>> which has enough
>> examples of usage". Nothig from this is applied to the new API.
>
> Do you have completed API somewhere ? Where do you read that API is
> already completed
On 04/11/11 17:57, Dimitry Sibiryakov wrote:
> 11.04.2011 15:38, Alex Peshkoff wrote:
>> New features are much easier to implement using interfaces. For example,
>> when we try to add namespaces to old XSQLDA (i.e. need to extend that
>> structure), we have a lot of backward compatibility problems
11.04.2011 15:38, Alex Peshkoff wrote:
> New features are much easier to implement using interfaces. For example,
> when we try to add namespaces to old XSQLDA (i.e. need to extend that
> structure), we have a lot of backward compatibility problems.
Nope. Enough to ignore data for which given v
> 11.04.2011 14:59, Vlad Khorsun wrote:
>>> It just don't have enough advantages over old ISC API.
>>
>> With this new API many simple programs (like yours, for example) will
>> be easy to write and require
>> NO additional access layers.
>
> Not quite so. "Easy to write" (for me) means "u
On 04/11/11 17:20, Dimitry Sibiryakov wrote:
> 11.04.2011 14:59, Vlad Khorsun wrote:
>>> It just don't have enough advantages over old ISC API.
>> With this new API many simple programs (like yours, for example) will
>> be easy to write and require
>> NO additional access layers.
>Not qu
On 04/11/11 16:31, Vlad Khorsun wrote:
> We talk there about API *declarations*. API *declarations* ideally
> shouldn't have code else
> it will be hard to port it into another language. As for struct\interface
> choice :
>
> - struct should be as simple as possible to avoid problems with di
11.04.2011 14:59, Vlad Khorsun wrote:
>> It just don't have enough advantages over old ISC API.
>
> With this new API many simple programs (like yours, for example) will be
> easy to write and require
> NO additional access layers.
Not quite so. "Easy to write" (for me) means "use well do
> But reading the discussions during last couple of weeks I see no reason why
> this API
> declaration would ever be ported into another language.
It is your fault then ;)
> It just don't have enough advantages over old ISC API.
With this new API many simple programs (like yours, f
11.04.2011 14:31, Vlad Khorsun wrote:
>> 11.04.2011 14:00, Alex Peshkoff wrote:
>>>On 04/11/11 15:21, Dimitry Sibiryakov wrote:
>>> Certainly, one can safely pass any pointer to interface if it is only
>>> passed, no access to it's internals is attempted.
>>> The problem is that with mentioned
> 11.04.2011 14:00, Alex Peshkoff wrote:
>> On 04/11/11 15:21, Dimitry Sibiryakov wrote:
>>> You are talking about using structures (actually, pointers to them) in
>>> new API, right? Passing pointers to structure to interfaces doesn't mean
>>> that user has do
>>> work with these structures' me
11.04.2011 14:00, Alex Peshkoff wrote:
> On 04/11/11 15:21, Dimitry Sibiryakov wrote:
>> You are talking about using structures (actually, pointers to them) in
>> new API, right? Passing pointers to structure to interfaces doesn't mean
>> that user has do
>> work with these structures' members d
On 04/11/11 15:21, Dimitry Sibiryakov wrote:
> You are talking about using structures (actually, pointers to them) in
> new API, right? Passing pointers to structure to interfaces doesn't mean that
> user has do
> work with these structures' members directly, AFAIU.
Certainly, one can safely p
11.04.2011 12:49, Alex Peshkoff wrote:
> Dimitry, how is it related with internals of isc_db_handle?
> May be you mean some other structure?
No, this is exactly the structure I had on my mind along with isc_tr_handle,
isc_stmt_handle, etc. They all were pointers to structures before became
ar
On 04/11/11 14:33, Dimitry Sibiryakov wrote:
> 11.04.2011 12:28, Alex Peshkoff wrote:
>> Taking into an account Dmirty's sample with XSQLDA I must say that may
>> be not everything SO bad in this area. At least somehow it did work all
>> this time. What is problematic - how to add something to suc
11.04.2011 12:28, Alex Peshkoff wrote:
> Taking into an account Dmirty's sample with XSQLDA I must say that may
> be not everything SO bad in this area. At least somehow it did work all
> this time. What is problematic - how to add something to such structures?
Make it internal. The main problem
> PS Alex will explain you why "struct" or "class with data members" is
> bad for *portable* code.
Taking into an account Dmirty's sample with XSQLDA I must say that may
be not everything SO bad in this area. At least somehow it did work all
this time. What is problematic - how to add something t
On 04/11/11 13:32, Kjell Rilbe wrote:
> Den 2011-04-11 10:44 skrev Alex Peshkoff såhär:
>> On 04/11/11 11:35, Kjell Rilbe wrote:
>>> 2. If I'm not mistaken most languages support a "packed" directive that
>>> tells the compiler to not align/pad the struct. Delphi does. But I doubt
>>> it's possi
On 04/11/11 12:49, Dmitry Yemanov wrote:
> 11.04.2011 11:19, Alex Peshkoff wrote:
>
>> passing pointers to structures into interfaces is definitely wrong solution
> We deal with pointers to XSQLDA in the public API for twenty years
> without problems. I fail to see why interfaces are so much diff
Den 2011-04-11 10:44 skrev Alex Peshkoff såhär:
> On 04/11/11 11:35, Kjell Rilbe wrote:
>> 2. If I'm not mistaken most languages support a "packed" directive that
>> tells the compiler to not align/pad the struct. Delphi does. But I doubt
>> it's possible to do the other way around: tell a compil
11.04.2011 10:44, Alex Peshkoff wrote:
> That's possible, I think. But not too good.
> The main disadvantage that this layout may probably differ for different
> hardware.
> And what - with every new port rewrite/review a piece of documentation?
I think that "#pragma pack(X)" in the header may
11.04.2011 11:19, Alex Peshkoff wrote:
> passing pointers to structures into interfaces is definitely wrong solution
We deal with pointers to XSQLDA in the public API for twenty years
without problems. I fail to see why interfaces are so much different in
this regard.
Dmitry
>> Btw, i see no problem curently. Alex made change but it is not means it
>> can't be undone if
>> necessary.
>>
> Ah, that's it. Every change I do, specially from you come this discurse
> of where the thing was discussed.
>
> But for others, no. It's just a commit that can be undone.
On 04/11/11 11:35, Kjell Rilbe wrote:
> Den 2011-04-11 09:19 skrev Alex Peshkoff såhär:
>> I'm far not sure everything is so fine with that structure/class. Look here:
>> unsigned
>> blrLength;
>>
>> const unsigned char* blr;
>> Pointer (8-bytes object) is placed after integer (4-bytes o
Den 2011-04-11 09:19 skrev Alex Peshkoff såhär:
> I'm far not sure everything is so fine with that structure/class. Look here:
> unsigned
> blrLength;
>
> const unsigned char* blr;
> Pointer (8-bytes object) is placed after integer (4-bytes object). C
> language has a requirement to align
On 04/10/11 15:47, Dmitry Yemanov wrote:
> All,
>
> While being on the subject, may I kindly ask everyone to *stop* naming
> the methods (especially public ones) as nouns and use verbs instead.
> Method names like version(), owner() etc drive me crazy. It gets
> especially "funny" when the form
On 04/09/11 19:44, Adriano dos Santos Fernandes wrote:
> On 09-04-2011 08:58, Vlad Khorsun wrote:
>>> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
Revision: 52693
http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev
Author: alexpeshkoff
On 10-04-2011 08:47, Dmitry Yemanov wrote:
> All,
>
> While being on the subject, may I kindly ask everyone to *stop* naming
> the methods (especially public ones) as nouns and use verbs instead.
> Method names like version(), owner() etc drive me crazy. It gets
> especially "funny" when the fo
All,
While being on the subject, may I kindly ask everyone to *stop* naming
the methods (especially public ones) as nouns and use verbs instead.
Method names like version(), owner() etc drive me crazy. It gets
especially "funny" when the former is a getter while the latter is a setter.
Another
On 09-04-2011 08:58, Vlad Khorsun wrote:
>> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
>>> Revision: 52693
>>> http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev
>>> Author: alexpeshkoff
>>> Date: 2011-04-08 16:43:05 + (Fri, 08 Apr 2011)
>>>
>>>
> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
>> Revision: 52693
>> http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev
>> Author: alexpeshkoff
>> Date: 2011-04-08 16:43:05 + (Fri, 08 Apr 2011)
>>
>> Log Message:
>> ---
>> Use interface I
On 08-04-2011 13:55, Dimitry Sibiryakov wrote:
> 08.04.2011 18:50, Adriano dos Santos Fernandes wrote:
>> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
>>> Log Message:
>>> ---
>>> Use interface IBlrMessage instead passing C++ class pointer to API
>>> interface's functions
08.04.2011 18:50, Adriano dos Santos Fernandes wrote:
> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
>> Log Message:
>> ---
>> Use interface IBlrMessage instead passing C++ class pointer to API
>> interface's functions
>>
> I'm *very* against this *undiscussed* change.
On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
> Revision: 52693
> http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev
> Author: alexpeshkoff
> Date: 2011-04-08 16:43:05 + (Fri, 08 Apr 2011)
>
> Log Message:
> ---
> Use interface IBlrMessage
59 matches
Mail list logo
