On Saturday, 19 December 2015 at 14:16:36 UTC, anonymous wrote:
On 19.12.2015 14:20, Marc Schütz wrote:
As this is going to be passed to a C function, it would need
to be
zero-terminated. `.dup` doesn't do this, he'd have to use
`std.string.toStringz` instead. However, that function returns
a
On Saturday, 19 December 2015 at 17:30:02 UTC, Kagamin wrote:
On Saturday, 19 December 2015 at 13:20:03 UTC, Marc Schütz
wrote:
As this is going to be passed to a C function
No, ODBC API is designed with multilingual capability in mind,
it doesn't rely on null terminated strings heavily: all
Well, ISO 9075-3 doesn't use const qualifiers, but uses IN/OUT
qualifiers instead, e.g. ExecDirect function is declared as:
ExecDirect (
StatementHandle IN INTEGER,
StatementText IN CHARACTER(L),
TextLength IN INTEGER )
RETURNS SMALLINT
And in C header:
SQLRETURN
On Saturday, 19 December 2015 at 13:20:03 UTC, Marc Schütz wrote:
As this is going to be passed to a C function
No, ODBC API is designed with multilingual capability in mind, it
doesn't rely on null terminated strings heavily: all string
arguments support length specification.
On Friday, 18 December 2015 at 22:35:04 UTC, anonymous wrote:
If the parameter is really not const, i.e. the function may
mutate the argument, then the cast is not ok. You can use
`.dup.ptr` instead to get a proper char* from a string.
As this is going to be passed to a C function, it would
On 19.12.2015 14:20, Marc Schütz wrote:
As this is going to be passed to a C function, it would need to be
zero-terminated. `.dup` doesn't do this, he'd have to use
`std.string.toStringz` instead. However, that function returns a
`immutable(char)*`, which would have to be cast again :-(
Ouch,
On Friday, 18 December 2015 at 22:18:34 UTC, Adam D. Ruppe wrote:
That's what the examples on MSDN do too though, a cast. At
first I thought the binding was missing a const, but the ODBC
docs don't specify it as const either and cast.
The ODBC functions also have a size parameter for string
On Friday, 18 December 2015 at 22:35:04 UTC, anonymous wrote:
If the parameter is de facto const, then the cast is ok.
Though, maybe it should be marked const then.
I'm just worried about casts because I read somewhere that
strings start with the number of characters inside them (probably
in
By the use of this tutorial
(http://www.easysoft.com/developer/languages/c/odbc_tutorial.html), I thought it would be very straightforward to use etc.c.odbc.sqlext and etc.c.odbc.sql to create a simple odbc application. But as soon as I started, I noticed a quirk:
SQLRETURN ret;
SQLHDBC
On 18.12.2015 23:14, Fer22f wrote:
By the use of this tutorial
(http://www.easysoft.com/developer/languages/c/odbc_tutorial.html), I
thought it would be very straightforward to use etc.c.odbc.sqlext and
etc.c.odbc.sql to create a simple odbc application. But as soon as I
started, I noticed a
On Friday, 18 December 2015 at 22:14:04 UTC, Fer22f wrote:
When I remove the string literal and replace it with null, it
compiles. .ptr and .toStringz both give immutable char*
references, and don't work. A "cast(char *)"DNS=*maydns*;""
works, but it feels a lot like a hack that will not work
On 19.12.2015 01:06, Fer22f wrote:
Documentation on casts say:
Casting a pointer type to and from a class type is done as a type paint
(i.e. a reinterpret cast).
That sentence doesn't apply. string is not a class, it's an alias for
immutable(char)[], i.e. it's an array.
Reinterpretation
12 matches
Mail list logo
