On 12-04-2011 06:02, marius adrian popa wrote:
>
> ps:we really need a really good c++ for flamerobin and other c++
> toolkits :qt/wx
> How can i test the new api ? there is some doc or samples somewhere ?
>
I'll soon publish some tests at https://github.com/asfernandes/fbstuff.
Adriano
-
On 04/12/11 13:02, marius adrian popa wrote:
> How can i test the new api ? there is some doc or samples somewhere ?
I'm afraid that it's not ready for tests. If you look at current
samples, you\ll sooner of all say - it's awful. It's really not ready.
--
On Thu, Apr 7, 2011 at 4:23 PM, Daniel Rail wrote:
> Hi,
>
> At April-07-11, 9:44 AM, Dmitry Yemanov wrote:
>
>> I believe some form of queryInterface/upgradeInterface is required in
>> the API. But I don't think we should mimic IUnknown precisely without
>> really strong reasons. First of all, we
>Yes, it can. It stores first 4 (on linux 6) arguments in registers, the
>rest are stored on stack using cdecl conventions.
I must say, there is a difference in treatment of the stack between Windows
and Linux systems. Windows not only passes the first 4 parameters in
registers but ALWAYS allocate
On 04/08/11 19:00, Adriano dos Santos Fernandes wrote:
> On 08-04-2011 11:25, Vlad Khorsun wrote:
>>> 08.04.2011 15:42, Vlad Khorsun wrote:
Thanks. But, if this is true : "In 64 bit mode, there is only one
calling convention for each
operating system" then we have no problem w
08.04.2011 17:15, Vlad Khorsun wrote:
> This is compiler, who put argumets on stack, isn't it ? :)
Ok, ok. At last I realized that all compilers' authors have agreed and thus
all
compilers in the world work the same way. Thanks for explanation.
--
SY, SD.
--
> 08.04.2011 16:25, Vlad Khorsun wrote:
>>> 08.04.2011 15:42, Vlad Khorsun wrote:
Thanks. But, if this is true : "In 64 bit mode, there is only one
calling convention for each
operating system" then we have no problem with interfaces despite of
compiler\language
on
On 08-04-2011 11:25, Vlad Khorsun wrote:
>> 08.04.2011 15:42, Vlad Khorsun wrote:
>>> Thanks. But, if this is true : "In 64 bit mode, there is only one
>>> calling convention for each
>>> operating system" then we have no problem with interfaces despite of
>>> compiler\language
>>> on x64 sy
08.04.2011 16:25, Vlad Khorsun wrote:
>> 08.04.2011 15:42, Vlad Khorsun wrote:
>>> Thanks. But, if this is true : "In 64 bit mode, there is only one
>>> calling convention for each
>>> operating system" then we have no problem with interfaces despite of
>>> compiler\language
>>> on x64 syst
> 08.04.2011 15:42, Vlad Khorsun wrote:
>> Thanks. But, if this is true : "In 64 bit mode, there is only one
>> calling convention for each
>> operating system" then we have no problem with interfaces despite of
>> compiler\language
>> on x64 systems.
>
> Yep, if forget that current FB AP
08.04.2011 15:42, Vlad Khorsun wrote:
> Thanks. But, if this is true : "In 64 bit mode, there is only one
> calling convention for each
> operating system" then we have no problem with interfaces despite of
> compiler\language
> on x64 systems.
Yep, if forget that current FB API, impleme
> At April-08-11, 3:56 AM, Vlad Khorsun wrote:
>
>>> And, I've just learned that the new
>>> Delphi 64-bit compiler(hopefully released later this year) will only
>>> use fastcall for DLL interfaces(even Microsoft has that same
>>> restriction for 64-bit).
>
>> Where can i read about it ? Bec
Hi,
At April-08-11, 3:56 AM, Vlad Khorsun wrote:
>> And, I've just learned that the new
>> Delphi 64-bit compiler(hopefully released later this year) will only
>> use fastcall for DLL interfaces(even Microsoft has that same
>> restriction for 64-bit).
> Where can i read about it ? Because i
> And, I've just learned that the new
> Delphi 64-bit compiler(hopefully released later this year) will only
> use fastcall for DLL interfaces(even Microsoft has that same
> restriction for 64-bit).
Where can i read about it ? Because i doubt fastcall is *only* supported
calling convention in
On 04/07/11 17:23, Daniel Rail wrote:
> Hi,
>
> At April-07-11, 9:44 AM, Dmitry Yemanov wrote:
>
>> I believe some form of queryInterface/upgradeInterface is required in
>> the API. But I don't think we should mimic IUnknown precisely without
>> really strong reasons. First of all, we don't need
Hi,
At April-07-11, 9:44 AM, Dmitry Yemanov wrote:
> I believe some form of queryInterface/upgradeInterface is required in
> the API. But I don't think we should mimic IUnknown precisely without
> really strong reasons. First of all, we don't need GUIDs as interface
> version identifiers, as ou
All,
Speaking honestly, I've got lost in ping ponging between different
aspects of the topic. So feel free to correct me if I'll be going a
completely wrong way. And please forgive me for writing the obvious
things, as I tried to compose a complete picture for myself.
The basic requirement we
04.04.2011 14:58, Adriano dos Santos Fernandes wrote:
> Let's stop to waste our time.
>
> I'll never agree with your used approach to fix *real user mistakes*
> adding methods to our API, nor even seems to be enough interested
> persons to make things better.
>
> In the end, the community has what
Alex,
Let's stop to waste our time.
I'll never agree with your used approach to fix *real user mistakes*
adding methods to our API, nor even seems to be enough interested
persons to make things better.
In the end, the community has what it deserves in the final product, and
developers will need
On 04/02/11 01:34, Adriano dos Santos Fernandes wrote:
> On 01-04-2011 07:14, Alex Peshkoff wrote:
>> On 03/31/11 19:13, Adriano dos Santos Fernandes wrote:
>>> On 31-03-2011 07:49, Alex Peshkoff wrote:
>>>
> People would like to detach a parent and not care about statements
> created but
On 01-04-2011 07:14, Alex Peshkoff wrote:
> On 03/31/11 19:13, Adriano dos Santos Fernandes wrote:
>> On 31-03-2011 07:49, Alex Peshkoff wrote:
>>
People would like to detach a parent and not care about statements
created but unfreed for this attachment.
>>> If they do not call addR
On 03/31/11 19:13, Adriano dos Santos Fernandes wrote:
> On 31-03-2011 07:49, Alex Peshkoff wrote:
>
>>> People would like to detach a parent and not care about statements
>>> created but unfreed for this attachment.
>>>
>> If they do not call addRef for statements, they will be destroyed when
>>
On 31-03-2011 07:49, Alex Peshkoff wrote:
>> People would like to detach a parent and not care about statements
>> created but unfreed for this attachment.
>>
>
> If they do not call addRef for statements, they will be destroyed when
> attachment goes away
>
This is against of what you already s
Vlad Khorsun skriver:
So, would you say that this article is misleading:
http://en.wikipedia.org/wiki/IUnknown
Article is not misleading. How you read it - probably.
It said :
In programming, the IUnknown interface is the fundamental interface in the
Component Object Model (COM)
>> Nobody going ever think about COM.
>
> So, would you say that this article is misleading:
>
> http://en.wikipedia.org/wiki/IUnknown
Article is not misleading. How you read it - probably.
It said :
In programming, the IUnknown interface is the fundamental interface in the
Compo
On 03/31/11 17:52, Kjell Rilbe wrote:
> Adriano dos Santos Fernandes skriver:
>> QueryInterface uses GUIDs, and an interface with a GUID should not
>> change.
>>
>> This is not conceptually compatible with our versioning scheme.
>
> If I, as a mere deadly FB user, may butt in here, I really really
On 03/31/11 17:45, Adriano dos Santos Fernandes wrote:
> On 31-03-2011 10:30, Alex Peshkoff wrote:
>> On 03/31/11 16:21, Vlad Khorsun wrote:
On 03/31/11 15:28, Vlad Khorsun wrote:
>> On the other hand I see no problems with adding that method to our
>> interfaces, specially if it's n
Vlad Khorsun skriver:
1. FB is multi platform, while IUnknown is inherently tied to Microsoft.
(Or am I wrong about this?)
Absolutely wrong.
2. IUnknown compatibility would imply a lot of other stuff that FB
doesn't want, re. COM etc.
Wrong again.
Although that may not be requir
> 1. FB is multi platform, while IUnknown is inherently tied to Microsoft.
> (Or am I wrong about this?)
Absolutely wrong.
> 2. IUnknown compatibility would imply a lot of other stuff that FB
> doesn't want, re. COM etc.
Wrong again.
> Although that may not be required per se,
> jus
Adriano dos Santos Fernandes skriver:
QueryInterface uses GUIDs, and an interface with a GUID should not change.
This is not conceptually compatible with our versioning scheme.
If I, as a mere deadly FB user, may butt in here, I really really think
QueryInterface and IUnkown compatibility is
On 31-03-2011 10:30, Alex Peshkoff wrote:
> On 03/31/11 16:21, Vlad Khorsun wrote:
>>> On 03/31/11 15:28, Vlad Khorsun wrote:
> On the other hand I see no problems with adding that method to our
> interfaces, specially if it's needed to make Delphi people life easier.
> It does not con
On 03/31/11 16:21, Vlad Khorsun wrote:
>> On 03/31/11 15:28, Vlad Khorsun wrote:
On the other hand I see no problems with adding that method to our
interfaces, specially if it's needed to make Delphi people life easier.
It does not conflict with our versioning support.
>>> Unfor
> On 03/31/11 15:00, Kjell Rilbe wrote:
>> Generally speaking, I feel it's completely wrong to add something to
>> an api only because some clients/users would expect it, unless it
>> actually does something useful in the api. it will only lead to extra
>> complexity and problems down the line.
>>
> On 03/31/11 15:28, Vlad Khorsun wrote:
>>> On the other hand I see no problems with adding that method to our
>>> interfaces, specially if it's needed to make Delphi people life easier.
>>> It does not conflict with our versioning support.
>> Unfortunately it is not enough. To be binary compa
On 03/31/11 15:00, Kjell Rilbe wrote:
> Generally speaking, I feel it's completely wrong to add something to
> an api only because some clients/users would expect it, unless it
> actually does something useful in the api. it will only lead to extra
> complexity and problems down the line.
>
> So,
On 03/31/11 15:28, Vlad Khorsun wrote:
>> On the other hand I see no problems with adding that method to our
>> interfaces, specially if it's needed to make Delphi people life easier.
>> It does not conflict with our versioning support.
> Unfortunately it is not enough. To be binary compatible
> On the other hand I see no problems with adding that method to our
> interfaces, specially if it's needed to make Delphi people life easier.
> It does not conflict with our versioning support.
Unfortunately it is not enough. To be binary compatible with IUnknown
(not with Delphi itself but w
Alex Peshkoff skriver:
In many aspects use of queryInterface might be ideal. Two main reasons
why we can't use it:
- it will cause additional delays in time-critical places like fetching
next record,
- it will pollute each place in the code where we work with plugins.
On the other hand I see no
On 03/30/11 18:44, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 07:23, Alex Peshkoff wrote:
>> On 03/29/11 18:58, Adriano dos Santos Fernandes wrote:
>>> On 29-03-2011 10:45, Alex Peshkoff wrote:
We have too many problems in single thread. I try to divide it to
smaller parts.
>>
On 03/30/11 18:39, Adriano dos Santos Fernandes wrote:
>> Do you see the difference ?
>>
> If user pass an invalid pointer parameter, it *will* crash in our code:
>
> provider->attachDatabase((Status*) 0x1, (char*) 0x1, ...);
>
> We can't prevent wrong program from crashing in our code. The sa
On 03/31/11 00:18, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 17:09, Vlad Khorsun wrote:
Therefore it will be very desirable to add queryInterface to the our
base interface,
even empty or raising notImplemented error. IUnknown *is* industry
standard, despite
On 03/31/11 02:07, Adriano dos Santos Fernandes wrote:
> On 30-03-2011 18:35, Vlad Khorsun wrote:
>>> stdcall is incompatible with our approach to upgradeInterface.
>> Why ? I see no reason for it.
>>
> We add methods to vtable, which expect single "status" parameter, but
> user may call this
42 matches
Mail list logo
