Re: [SOCI-users] SOCI::use and const

[Maciej S. <pr...@ms...>]

Hi,

Rodrigo Madera wrote:

>> You could for example set a member variable with that information
>> (is_const) that could later be checked or, even better, if use
>> return-type is already templated you could return another type when
>> use takes a const argument.
> 
> Agree. You are right.
> 
> Although it would allow const related errors to pass the compilation
> and make them catchable only by testing.
> 
> Well Steve, looks like now it's a matter of thinking it up and putting
> some new stuff on the next release.

It's not that obvious. :-)

The problem is that use (and into) elements were designed to be able to 
bind the given variable without any intermediate objects. At least 
Oracle backend makes good use of it. In other words, when you do this:

sql << "some query", use(x);

then *address* of x is given to the Oracle native client library and 
from this moment Oracle is doing whatever she wants with the memory 
pointed by that address. There is absolutely no copying of any 
additional values around. And of course, Oracle has no notion of const. 
If it needs to read the value from the given chunk of memory, it reads; 
if it needs to write to that memory, it writes. Just like that.
This means that even though it is perfectly possible to discover the use 
of const object at compile time and take some run-time decisions based 
on that fact, there is no decision to take in this case. Oracle is 
taking all decisions and she doesn't care about the constness of your 
data. It's the logic of the query (stored procedure call actually) that 
makes something readable or writable (or both).

The only way to solve this problem would be to actually use intermediary 
objects in the backend and check for modifications and then do the copy 
(or not, if it's not desired). Which itself is not possible again - how 
do you check that something was modified by a third-party library code?

I don't say that this problem is impossible to solve. Rather - that is 
requires a bit more head-scratching.
And at least I hope that the above gives you some rough explanation for 
why things work this way in SOCI. ;-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/