On Tuesday, 3 May 2022 at 17:21:47 UTC, JG wrote:
Hi,
The specification of string literals has either some errors or
I don't understand what is meant by a Character.
[...]
Which to me means that e.g.
r"""
should be a WysiwygString, which the compiler thinks is not
(not s
Hi,
The specification of string literals has either some errors or I
don't understand what is meant by a Character.
For instance we have:
WysiwygString:
r" WysiwygCharacters_opt " StringPostfix_opt
WysiwygCharacters:
WysiwygCharacter
WysiwygCharacter Wy
Le 07/04/2019 à 14:23, bauss via Digitalmars-d-learn a écrit :
On Saturday, 6 April 2019 at 19:47:14 UTC, lithium iodate wrote:
On Saturday, 6 April 2019 at 15:35:22 UTC, diniz wrote:
So, I still could store and use and compare string pointers myself [1], and
get valid results, meaning: pointer
On Saturday, 6 April 2019 at 19:47:14 UTC, lithium iodate wrote:
On Saturday, 6 April 2019 at 15:35:22 UTC, diniz wrote:
So, I still could store and use and compare string pointers
myself [1], and get valid results, meaning: pointer equality
implies (literal) string equality. Or am I wrong? The
Le 06/04/2019 à 21:47, lithium iodate via Digitalmars-d-learn a écrit :
On Saturday, 6 April 2019 at 15:35:22 UTC, diniz wrote:
So, I still could store and use and compare string pointers myself [1], and
get valid results, meaning: pointer equality implies (literal) string
equality. Or am I wro
On Saturday, 6 April 2019 at 15:35:22 UTC, diniz wrote:
So, I still could store and use and compare string pointers
myself [1], and get valid results, meaning: pointer equality
implies (literal) string equality. Or am I wrong? The point is,
the parser, operating on an array of prescanned lexeme
Le 06/04/2019 à 16:07, AltFunction1 via Digitalmars-d-learn a écrit :
On Friday, 5 April 2019 at 14:49:50 UTC, diniz wrote:
Hello,
Since literal strings are interned (and immutable), can I count on the fact
that they are compared (==) by pointer?
No. "==" performs a full array comparison and
On Friday, 5 April 2019 at 14:49:50 UTC, diniz wrote:
Hello,
Since literal strings are interned (and immutable), can I count
on the fact that they are compared (==) by pointer?
No. "==" performs a full array comparison and "is" is apparently
simplified at compile time. In the compiler there'
Hello,
Since literal strings are interned (and immutable), can I count on the fact that
they are compared (==) by pointer?
Context: The use case is a custom lexer for a custom language. I initially
wanted to represent lexeme classes by a big enum 'LexClass'. However, this makes
me write 3 ti
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
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.
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 SQLExecDire
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, I
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 ne
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 i
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
p
y
in slices documentation), and not with actual content (though
string literals probably act different in this case).
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).
Reinterpretation is rather dangerous if string
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 quir
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 i
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
()
{
writefln("%s",fromStringz(cpling("hello\0")));
}
or
void callC()
{
writefln("%s",fromStringz(cpling(toStringz("hello";
}
===
am I missing a better way to do this?
To call a C function you can either use string literals which are
always
Thanks for the help.
Laeeth
On Wednesday, 31 December 2014 at 12:25:45 UTC, John Colvin wrote:
String literals can implicitly convert to const(char)* or
immutable(char)*. Neat. It doesn't appear to apply to array
literals in general though...
I believe this is a special case specifically for strings added
extern(C) char* cpling(char* s);
void callC()
{
writefln("%s",fromStringz(cpling("hello\0")));
}
or
void callC()
{
writefln("%s",fromStringz(cpling(toStringz("hello";
}
===
am I missing a better way to do this?
String literals are always null-termi
",fromStringz(cpling("hello\0")));
}
or
void callC()
{
writefln("%s",fromStringz(cpling(toStringz("hello";
}
===
am I missing a better way to do this?
String literals are always null-terminated. You can typically pass them
as-is and D will do the
(toStringz("hello";
> }
>
> ===
>
> am I missing a better way to do this?
First I am not sure, but you do not need to call fromStringz in this
case. Next in this example you even not need to call toStringz, because
D string literals are null-terminated. But generally it is
What's best practice here?
D strings are not null-terminated.
char* cpling(char *s)
{
So toString("This i
Argh - no way to edit.
What's best practice here?
D strings are not null-terminated.
===
cpling.c
char* cpling(char *s)
{
s[0]='!';
return s;
}
===
dcaller.d
extern(C) char* cpling(char* s);
void callC()
{
writefln("%s",fromStringz(cpling("hello\0")));
}
or
void callC()
{
writefln("
On Monday, 23 September 2013 at 11:30:18 UTC, bearophile wrote:
Dicebot:
Rationale / link to discussion? I use it extensively.
http://d.puremagic.com/issues/show_bug.cgi?id=3827
Bye,
bearophile
Thanks.
Well, then we will have _guaranteed_ const-folding of adjacent
concatenated string
Dicebot:
Rationale / link to discussion? I use it extensively.
http://d.puremagic.com/issues/show_bug.cgi?id=3827
Bye,
bearophile
On Monday, 23 September 2013 at 11:10:07 UTC, bearophile wrote:
simendsjo:
Isn't "some" "string" replaced with "somestring" early on?
Yes, unfortunately. And it's something Walter agreed with me to
kill, but nothing has happened...
Bye,
bearophile
Rationale / link to discussion? I use it
simendsjo:
Isn't "some" "string" replaced with "somestring" early on?
Yes, unfortunately. And it's something Walter agreed with me to
kill, but nothing has happened...
Bye,
bearophile
On Monday, 23 September 2013 at 09:42:59 UTC, bearophile wrote:
John Carter:
is there a similar mechanism in D? Or should I do...
string foo =
"long"
"string"
"without"
"linefeeds"
;
Genrally you should do:
string foo = "long" ~
"string" ~
"without" ~
John Carter:
is there a similar mechanism in D? Or should I do...
string foo =
"long"
"string"
"without"
"linefeeds"
;
Genrally you should do:
string foo = "long" ~
"string" ~
"without" ~
"linefeeds";
See also:
http://d.puremagic.com/issues/show_bug.c
On Monday, 23 September 2013 at 04:43:16 UTC, John Carter wrote:
In C/C++ in the presence of the preprocessor a string
char foo[] = "\
long\
string\
without\
linefeeds\
";
Is translated by the preprocessor to
char foo[] = "longstringwithoutlinefeeds";
is there a similar mechanism in D? Or sho
In C/C++ in the presence of the preprocessor a string
char foo[] = "\
long\
string\
without\
linefeeds\
";
Is translated by the preprocessor to
char foo[] = "longstringwithoutlinefeeds";
is there a similar mechanism in D? Or should I do...
string foo =
"long"
"string"
"without"
"linefeeds"
;
On Friday, 31 May 2013 at 14:20:45 UTC, Jack Applegame wrote:
What's the reason that the string literal is a dynamic array,
not a static?
So sometimes it is not possible to get string length compile
time:
void foo(T: E[N], E, size_t N)(auto ref T data) {
pragma(msg, "static");
pragma(m
On Friday, 31 May 2013 at 15:35:51 UTC, Jonathan M Davis wrote:
The fact
that it's a string is irrelevant, and making it a static array
woludn't help
any. If data were a template argument, it would work, but it's
a funciton
argument, so it won't.
If to pass reference to static array as functi
und without ever
being copied is a definite efficiency boost for handling string literals (and a
lot of string handling involves string literals). Making them static arrays
wouldn't buy us anything and would cost us a lot.
> So sometimes it is not possible to get string length compile time:
Jack Applegame:
What's the reason that the string literal is a dynamic array,
not a static?
Originally it was a fixed sized array. But in most cases you want
a dynamic array.
Rust language forces you to specify where to allocate the string
literal with a symbol before the string, as ~"hell
What's the reason that the string literal is a dynamic array, not
a static?
So sometimes it is not possible to get string length compile time:
void foo(T: E[N], E, size_t N)(auto ref T data) {
pragma(msg, "static");
pragma(msg, data.length);
}
void foo(T: E[], E)(auto ref T data) {
p
rstand properly, converts
string to UTF-16, so that they can be sent to various Windows API
functions. But string literals, for example in MessageBox, are fine, no
conversion is needed. I don't understand the magic, what is converted,
and when?
If some variable was used e.g. "appName.
UTF-16, so that they can be sent to various Windows API
functions. But string literals, for example in MessageBox, are fine, no
conversion is needed. I don't understand the magic, what is converted,
and when?
If some variable was used e.g. "appName.toUTF16z", and not "Error".toUTF16z
Ah, I had the wrong assumption but it is a bug. Reported:
http://d.puremagic.com/issues/show_bug.cgi?id=6032
And thanks for disassembling!
On Wed, 18 May 2011 16:57:37 -0400, Andrej Mitrovic wrote:
Skip the rest of the code until you reach main:
http://codepad.org/zPAgFnPX
We have this notion that string *literals* are zero-terminated, which
enables us to send them to C functions expecting zero-terminated char*
strings
Skip the rest of the code until you reach main:
http://codepad.org/zPAgFnPX
We have this notion that string *literals* are zero-terminated, which enables
us to send them to C functions expecting zero-terminated char* strings.
But the same doesn't apply to wide string literals, e.g. "
Andrej Mitrovic:
> This might be related to that bug report you wrote where you could
> assign one string literal to another.
Right. And recently there's another similar bug report in Bugzilla. So I may
add this case just to one of those bug reports.
Bye,
bearophile
This might be related to that bug report you wrote where you could
assign one string literal to another.
bearophile Wrote:
>
> But a string literal isn't a lvalue. This seems all wrong.
This is a small D2 program that uses parse:
import std.conv: parse;
void main() {
parse!int("111");
parse!int("111");
}
Gives the error:
std.conv.ConvError: std.conv(1122): Can't convert value `' of type string base
2 to type int
But a string literal isn't a lvalue. This seems all wron
Rory Mcguire wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
> assert("This" is "This");
> }
Rory Mcguire Wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
> assert("T
Rory Mcguire wrote:
Are all string literals that have the same value initialized to the same
address?
void main() {
string same() {
return "This";
}
assert("This" is same());
assert("This" is "This");
}
On 19.08.2010 09:53, Rory Mcguire wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
>
e OP's point is: Are identical string literals *guaranteed* to be the
same instance? Regardless of implementation? Regardless of whether
they're next to each other, in different modules or anything in between?
Regardless of the phase of the moon?
Stewart.
Rory Mcguire:
> Are all string literals that have the same value initialized to the same
> address?
> ...
> Can this be relied upon?
Probably a conforming D implementation is free to not give the same address to
those.
Bye,
bearophile
On 8/19/10, Rory Mcguire wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
> assert(
Are all string literals that have the same value initialized to the same
address?
void main() {
string same() {
return "This";
}
assert("This" is same());
assert("This" is "This");
}
Can this be relied upon?
Am 20.07.2010 15:38, schrieb Lars T. Kyllingstad:
On Tue, 20 Jul 2010 13:26:56 +, Lars T. Kyllingstad wrote:
On Tue, 20 Jul 2010 14:59:18 +0200, awishformore wrote:
Following this discussion on announce, I was wondering why string
literals are zero-terminated. Or to re-formulate, why
On Tue, 20 Jul 2010 13:26:56 +, Lars T. Kyllingstad wrote:
> On Tue, 20 Jul 2010 14:59:18 +0200, awishformore wrote:
>
>> Following this discussion on announce, I was wondering why string
>> literals are zero-terminated. Or to re-formulate, why only string
>> lite
On Tue, 20 Jul 2010 14:59:18 +0200, awishformore wrote:
> Following this discussion on announce, I was wondering why string
> literals are zero-terminated. Or to re-formulate, why only string
> literals are zero-terminated. Why that inconsistency? What's the
> rationale behin
Following this discussion on announce, I was wondering why string
literals are zero-terminated. Or to re-formulate, why only string
literals are zero-terminated. Why that inconsistency? What's the
rationale behind it? Does anyone know?
/Max
>>>> Did you test with a string th
62 matches
Mail list logo
