SQLite 3.6.23.1 wrapper + connector

awishformore awishformore at gmail.com
Sun Jul 18 21:20:53 PDT 2010


On 19/07/2010 04:59, Ellery Newcomer wrote:
> On 07/18/2010 09:20 PM, Jonathan M Davis wrote:
>> On Sunday 18 July 2010 19:10:35 Ellery Newcomer wrote:
>>> btw, would it be possible to distribute as something other than a rar? I
>>> wanted to have a peek at what you've done, but apparently nothing on my
>>> [linux] system can read that file.
>>
>> While I hate rar, every distribution than I have used has had unrar.
>> There's a
>> decent chance that it isn't installed by default though.
>>
>> - Jonathan M Davis
>
> Hmm. I suppose I could have spent more than 2 seconds trying to open it.
> You're right on both counts.
>
> As for the code, I'm looking at SQLiteConnector.ptrtostr. Does reserve
> really work that way? Just curious - I wouldn't know one way or the
> other, although I would probably use something more like
>
> string ptrtostr(char* ptr, int size = 0){
> return ptr ? ptr[0 .. size].idup : null;
> }

I think an empty array/string is safer to return than null. And yes, 
reserve works that way, it will reserve the space needed for the 
(character) array to expand.

The strings are null terminated in SQLite and you won't always know the 
size; I had previously used the same method in another place of my app. 
I however also wasn't aware that you could still access pointers like 
arrays in D, so that would indeed be a better way to do it when you 
always know the size.

You could then even go as far as not iduping, but instead casting it to 
a string to avoid unnecessary allocations.

Greetings, Max.


More information about the Digitalmars-d-announce mailing list