On 06/14/12 14:50, Adriano dos Santos Fernandes wrote:
> On 14/06/2012 06:13, Alex Peshkoff wrote:
>> For me this looks like regression, sorry.
>>
> If you talking about specific subject about warning removal, I'd instead
> call it "let bad legacy and non-feature interfere with new design for no
> reason".
>
1. Do you treat C++ compiler warnings also 'bad and non-feature'? :)
2. Not long ago it was suggested to have a warning when non-secure
channel is opened by client as the almost single method to inform a user
about it. A few years before we added SQL states support with special
section dedicated to warnings. I.e. SQL warnings is not something dead
from XX century, we continue with them in development and I suppose that
some people do use them.
3. SQL completion condition warning is described in details in sql 2008.
We try to get as close to standard as possible - why break compatibility
where we already have it?
Is it enough to agree that keeping warnings in our API is the only
correct solution?
>> I suppose we should find better way to do this. I've used to meet more
>> or less same (as far as I can suppose) problem when reworking code in
>> interface.cpp to make it use exceptions instead a lot of copies of
>> status vector. But it was required to return server's errors from one
>> place (where it's received from network). Throwing such errors after
>> receiving from server was almost impossible, cause this is not an error
>> condition for remote client, and it's normal control flow should not be
>> interrupted - that is why that errors are almost like warnings for
>> remote client. As the result we still have a status vector parameter in
>> a number of remote client functions, but all errors/warnings raised in
>> remote client itself are thrown to the client in C++ style.
> I've probably already meet the code you're talking about, and my changes
> does not interfere with it.
>
> In these places, things looks like now, example:
>
> IAttachment* att = service->attachDatabaseNoThrow(status, ...);
>
> if (status->isSuccess())
> ...
>
> ...
>
> The callers are not obliged to use the throwing methods.
>
>> It's hard to suggest something not seeing the code. Can you send me some
>> fragments helping to better understand what do you want to do?
>>
>>
> The code just automatically creates inline non-virtual methods, example:
>
> // New method automatically generated
> IAttachment* attachDatabase(const char* filename)
> {
> // call attachDatabaseNoThrow, check status vector and throw if
> necessary
> }
>
> // Original method
> virtual IAttachment* attachDatabaseNoThrow(IStatus* status, const char*
> filename)
> {
> ...
> }
>
> These inline non-virtual methods does not interfere with linkage nor
> vtable layouts, so from external POV, nothing changes.
>
> Externally, someone may even declare attachDatabaseNoThrow as the
> original attachDatabase if exceptions are not intended to be thrown.
Well, it's not too big question how this methods are called.
Why not generate 2 wrappers?
IAttachment* attachDatabase(const char* filename)
IAttachment* attachDatabase(IWarning* warning, const char* filename)
(I'm not ready to answer right now what does IWarning contain - hope
it's not a problem)
A.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
