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=52693&view=rev
>>>>> Author: alexpeshkoff
>>>>> Date: 2011-04-08 16:43:05 +0000 (Fri, 08 Apr 2011)
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> Use interface IBlrMessage instead passing C++ class pointer to API
>>>>> interface's functions
>>>>>
>>>> I'm *very* against this *undiscussed* change.
>>> You also against endless discucssions of every tiny code change, isn't
>>> is ? :)
>>>
>>>> Pointer to plain struct is know to be portable and usable by the clients
>>>> we expect to use our API.
>
> 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 it on 8-bytes boundary, but what
> about others? I't quite possible that some other language will try to
> save memory. The result is obvious - segfault when we use such structure.
>
Congrats. We already make a C++ runtime (GlobalPtrs, Statics,
refptrs)... I just don't understand how the rest of the world is doing
C++ development without use our classes.
This rest of the world, including our old code does:
typedef struct isc_blob_ctl
{
ISC_STATUS (* ctl_source)(); /* Source filter */
struct isc_blob_ctl* ctl_source_handle; /* Argument to pass to
source
filter */
short ctl_to_sub_type;
/* Target type */
short ctl_from_sub_type;
/* Source type */
unsigned short ctl_buffer_length; /*
Length of buffer */
unsigned short ctl_segment_length; /*
Length of current segment */
unsigned short ctl_bpb_length; /*
Length of blob parameter block */
/* Internally, this is const UCHAR*, but this public struct probably
can't change. */
ISC_SCHAR* ctl_bpb;
/* Address of blob parameter block */
ISC_UCHAR* ctl_buffer;
/* Address of segment buffer */
ISC_LONG ctl_max_segment;
/* Length of longest segment */
ISC_LONG ctl_number_segments; /*
Total number of segments */
ISC_LONG ctl_total_length;
/* Total length of blob */
ISC_STATUS* ctl_status;
/* Address of status vector */
long ctl_data[8];
/* Application specific data */
} * ISC_BLOB_CTL;
/* This is the famous internal descriptor that UDFs can use, too. */
typedef struct paramdsc {
ISC_UCHAR dsc_dtype;
signed char dsc_scale;
ISC_USHORT dsc_length;
short dsc_sub_type;
ISC_USHORT dsc_flags;
ISC_UCHAR *dsc_address;
} PARAMDSC;
and it works. It uses the Windows API, full of structs and it works.
>>> Plain struct ? It was declared as "class", not as "struct", sorry. If
>>> you want understanding
>>> from other developers, please, make you ideas clear. Else there will be
>>> such "incidents".
>>> Something obvious for you is not obvious for me and far not obvious for end
>>> users. This is life.
>>>
>>> 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.
>>
>> BTW what about if I just came to whole plugin thing and just removed the
>> reference counters because it was obviously wrong? Is it just a piece of
>> code that was write to be undone? (at least it appears to be till now,
>> cause the implementation is currently broken)
>>
>> And "MessageBuffer" was discussed here in this list and you had all your
>> time to comment on it.
>>
>
> Adriano, from your explanations I did not understand that you plan to
> pass pointer to it into interfaces. I understood it as a tool to prepare
> a message (with what I see no problems), but passing pointers to
> structures into interfaces is definitely wrong solution.
>
> But I agree that 4 additional virtual calls is really unneeded (though
> not dramatic) loss of performance here. To save both performance and
> avoid tragic misalignment, I suggest to simply return to old format of
> passing parameters as 4 independent values. This does not prevent use of
> class Message (aah, name is really not ideal...) to prepare messages,
> keeps interfaces in clear state and avoids possible performance issues.
>
I don't buy your arguments.
Adriano
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
