On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 07/08/2017 02:29 PM, Andre Pany wrote:
>
> > I use assert(false, tmp) to see the content of variable tmp as it
> > seems there is no other way in CTFE.
>
> A more natural way is pragma(msg), which you can
On Sunday, 9 July 2017 at 03:11:17 UTC, Mike Parker wrote:
On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:
To include stat1.d and stat2.d in the compilation, you'll
either have to import them in statmain.d or use the
--extra-file command line switch:
rdmd --extra-file=stat1.d
On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:
$ rdmd statmain.d stat1.d stat2.d
// outputs nothing...
Bug or intended behaviour?
rdmd takes the first D file you give it, follows its import tree,
and compiles all the modules found there. Anything on the command
line after
RDMD does not behave the same as DMD WRT static constructors. The
following example, extracted form Mike Parker's "Learning D",
does not produce the same result:
// stat1.d
module stat1;
import std.stdio;
static this() { writeln("stat1 constructor"); }
// stat2.d
module stat2;
import
On Saturday, July 8, 2017 10:12:29 PM MDT Era Scarecrow via Digitalmars-d-
learn wrote:
> On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:
> > app.d(17):called from here: test("1234\x0a5678\x0a")
> >
> > I wrote the source code on windows with a source file with \r\n
> > file
Just saw that my first example was wrong, it should read
1 void main ()
2 {
3import std.uri;
4string a = "";
5assert (a);
6auto s = a.decodeComponent;
7assert (s);
8 }
The non-nullity was not preserved. Only the second assert
On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn
wrote:
> Yesterday I noticed that std.uri.decodeComponent does not
> 'preserve' the
> nullity of its argument:
>
> 1 void main ()
> 2 {
> 3import std.uri;
> 4string s = null;
> 5assert (s is
On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:
app.d(17):called from here: test("1234\x0a5678\x0a")
I wrote the source code on windows with a source file with \r\n
file endings.
But the console output has only the character X0a. In addition
not the content of tmp is shown
On 07/08/2017 02:29 PM, Andre Pany wrote:
> I use assert(false, tmp) to see the content of variable tmp as it seems
> there is no other way in CTFE.
A more natural way is pragma(msg), which you can use in main in this case:
string test(string s)
{
string tmp = s;
tmp = tmp[4..$];
Hi,
I use assert(false, tmp) to see the content of variable tmp as it
seems there is no other way in CTFE.
The output is kind of weired:
app.d(6): Error: "1234\x0a5678\x0a"[4..10]
app.d(17):called from here: test("1234\x0a5678\x0a")
I wrote the source code on windows with a source
I use protocol buffers (using dproto) for this, storing my settings in
either text or wire format. Advantages: type-safety with fwd/backward
compatibility (unlike json which requires dynamic field access, eg
with dproto you get errors at compile time instead of runtime),
supports comments
What's the fastest XML-parser on code.dlang.org?
Are there any benchmarks that show performance improvements
compared to std.xml?
On 07/08/2017 07:16 PM, kdevel wrote:
The assertion in line 6 fails. This failure gave rise to a more general
investigation on strings. After some research I found that one
"cannot implicitly convert expression (s) of type string to bool" as in
[...]
Nonetheless in certain boolean contexts
On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote:
On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote:
On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote:
On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
[...]
"best" always depends on your specific use case. I
On 08.07.2017 19:16, kdevel wrote:
I wonder if this distinction is meaningful
Not nearly as much as it would need to be to justify the current
behavior. It's mostly a historical accident.
and---if not---why it is
exposed to the application programmer so prominently.
I don't think there
Yesterday I noticed that std.uri.decodeComponent does not
'preserve' the
nullity of its argument:
1 void main ()
2 {
3import std.uri;
4string s = null;
5assert (s is null);
6assert (s.decodeComponent);
7 }
The assertion in line 6 fails. This failure gave
import std.stdio;
enum A : int { a, b };
enum B : int { a, b };
enum AS : string[2] { a = ["1","2"], b = ["3","4"] };
enum BS : string[2] { a = ["5","6"], b = ["7","8"] };
void func(A a) { writeln("A"); }
void func(B b) { writeln("B"); }
void funcs(AS a) { writeln("AS"); }
void funcs(BS
On Saturday, 8 July 2017 at 08:56:17 UTC, Rainer Schuetze wrote:
On 08.07.2017 07:55, Nicholas Wilson wrote:
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole
wrote:
On 08/07/2017 2:35 AM, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson
wrote:
My
On 08.07.2017 07:55, Nicholas Wilson wrote:
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote:
On 08/07/2017 2:35 AM, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:
My library is generating a typeid from somewhere.
e.g.
Thanks, that was what was happening.
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote:
On 08/07/2017 2:35 AM, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:
My library is generating a typeid from somewhere.
e.g.
typeid(const(Pointer!(cast(AddrSpace)1u, float)))
[...]
It
21 matches
Mail list logo
