Re: Static ternary if
On Monday, 25 July 2016 at 05:00:23 UTC, Ali Çehreli wrote:
On 07/24/2016 07:15 PM, Gorge Jingale wrote:
Is there a static ternary if?
(A == B) ? C : D;
for compile type that works like static if.
The way to force an expression at compile time is to use it for
something that's needed at compile time. For example, you can
initialize a manifest constant (enum) with that expression:
void main() {
enum i = (__MODULE__.length % 2) ? 42 : 43;
pragma(msg, i);
}
Instead of enum, you can use 'static const' as well.
Ali
It also works for "real" enumerated types.
enum ver = 0; // version(Windows) ... else
enum VersionRelative1
{
A = ver ? 1 : 2,
B = ver ? 3 : 4,
}
enum VersionRelative2
{
A = !ver ? 1 : 2,
B = !ver ? 3 : 4,
}
unittest
{
static assert(VersionRelative1.A == 2);
static assert(VersionRelative2.A == 1);
}
which is quite cool and not widely known.
Re: How to pause terminal in D on Linux?
On Sunday, 24 July 2016 at 00:54:21 UTC, Zekereth wrote:
On Saturday, 23 July 2016 at 19:08:00 UTC, WhatMeWorry wrote:
What I thought would be trivial is becoming a nightmare. Can
anybody set me straight. Thanks in advance.
[...]
Use the getchar() function.
void pause(const string msg = "Press enter/return to
continue...")
{
write(msg);
getchar();
}
just call std.stdio.stdin.read() and ignore the result...
Re: Singletons importing each other?
On Sunday, 24 July 2016 at 15:07:20 UTC, Jack wrote:
Is there a way for singletons that import each other, use each
other's functions?
Like i.e:
--
module sing1;
import sing2;
final class Singleton_1{
static this{
instance = new Singleton_1();
}
static Singleton_1 getInstance(){
return instance;
}
void foo(){
writeln("Sample");
}
void bar2(){
Singleton_2.getInstance().bar();
}
private:
static Singleton_1 instance;
}
---
module sing2;
import sing1;
final class Singleton_2{
static this(){
instance = new Singleton_2();
}
static Singleton_2 getInstance(){
return instance;
}
void bar(){
Singleton_1.getInstance().foo();
}
private:
static Singleton_2 instance;
}
without triggering the "cycle between modules with
constructors/destructors"?
- You can use a 3rd module that imports the two that "cycle".
- You can use another singleton implementation that doesn't rely
on a static this. e.g a kind of "lazy factory" that control the
uniquness.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 15:09:53 UTC, Lodovico Giaretta wrote: Yes, making them @nogc would require all existing overrides to be changed (overrides cannot throw away attributes, but must specify them explicitly as in the parent class, or stricter). The real problem making these @nogc is that with the current state of things @nogc implies nothrow, thus preventing exceptions (of course we should work to change this thing, and I'm personally researching convenient ways of doing it; I'll soon write a post on General about this). Remember that comparison of complex objects may require normalization, which may change the objects themselves and allocate memory. Also, comparisons may throw exceptions that need the GC (see above). So I'm personally against making those methods @nogc. But I'm also against a singly-rooted hierarchy. Removing Object and having multiple class hierarchies would entirely solve the issue. But please note that you can already "do" that: if you never use Object, but always subclasses, the fact that Object isn't @nogc is no longer an issue. While Object (if it exists) must support any kind of descendant (and thus cannot pose arbitrary limitations like @nogc is), the roots of domain-specific hierarchies can exploit the fact that they are domain-specific to impose meaningful limitations, based on the expected usage and behaviour, and can thus be @nogc. And you can either limit your algorithm inputs to objects of a specific hierarchy or, if you want it generic, use a template (read as: you don't use Object explicitly, as if it doesn't exists). Almost off topic but I've recognized a typical error here, I think that many of us have already seen it too. You develop a nice class. You put attributes everywhere @safe pure nothrow @nogc. Yay the unittest pass. Later you use it for real and you realize then that the attributes must be removed because you can't do anything in the overriden methods.
