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
