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 surpri
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 Wysiwyg
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:
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?
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
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
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
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
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
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
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 strings
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
(%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 null terminated or use std.string.toStringz (when using
string
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()
{
What's best practice here?
D strings are not null-terminated.
char* cpling(char *s)
{
So toString(This i
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 better to
use toStringz when need pass D strings to C code.
Important Note: When passing a char* to a C function, and the C
function keeps it around for any
(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 right thing (you can also pass MyStr.ptr if
you want). Use
* 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-terminated. You can typically
pass them as-is and D will do
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
Thanks for the help.
Laeeth
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.cgi?id=3827
You
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 ~
linefeeds;
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 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
Dicebot:
Rationale / link to discussion? I use it extensively.
http://d.puremagic.com/issues/show_bug.cgi?id=3827
Bye,
bearophile
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
;
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) {
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
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:
void foo(T: E[N], E
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
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
, 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.toUTF16z, and not Error.toUTF16z
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. somestringw
On Wed, 18 May 2011 16:57:37 -0400, Andrej Mitrovic n...@none.none 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
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!
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 wrong.
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.
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
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);
}
Can this be relied upon?
Interesting thanks guys.
Was just curious about the speed
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?
On 8/19/10, Rory Mcguire rjmcgu...@gm_no_ail.com 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);
}
Can
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
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.
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());
assert(This is This);
}
Can this be relied upon?
I
Rory Mcguire rjmcgu...@gm_no_ail.com 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);
}
Can this be relied upon
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);
}
Can this be relied upon?
This should
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
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
literals are zero-terminated. Why
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
58 matches
Mail list logo
