Re: GC memory fragmentation
On Sunday, 11 April 2021 at 09:10:22 UTC, tchaloupka wrote: Hi, we're using vibe-d (on Linux) for a long running REST API server and have problem with constantly growing memory until system kills it with OOM killer. One thing that comes to mind: is your application compiled as 32-bit? The garbage collector is much more likely to leak memory with a 32-bit address space since it much more likely for a random int to appear to be a pointer to the interior of a block of GC-allocated memory.
Re: How do I check if a type is assignable to null at compile time?
On Friday, 26 February 2021 at 05:34:26 UTC, Paul Backus wrote: On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote: I started with: enum isAssignableNull(T) = is(T : Object) || isPointer(T); but how do I cover all cases? Something like this should work: enum isAssignableNull(T) = __traits(compiles, (T t) => t = null); `isAssignableNull!(immutable void*)` is true with his definition but false with yours. Of course you are correct that you cannot assign to an immutable pointer.
Re: How do I check if a type is assignable to null at compile time?
On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote: I started with: enum isAssignableNull(T) = is(T : Object) || isPointer(T); but how do I cover all cases? If I understand what you mean by "is assignable to null", this should do it: --- enum bool isAssignableNull(T) = is(typeof(null) : T); // Tests: immutable string arrayslice = null; static assert(isAssignableToNull!(immutable string)); void function(int) funptr = null; static assert(isAssignableToNull!(typeof(funptr))); int[int] aa = null; static assert(isAssignableToNull!(int[int])); ---
Re: Is this a compiler error? "recursive template expansion"
On Tuesday, 8 December 2020 at 22:01:52 UTC, Basile B. wrote:
On Tuesday, 8 December 2020 at 20:11:40 UTC, Nathan S. wrote:
The following code fails to compile. Is this a compiler error
or if not what is wrong with the code?
What is wrong is that partial specialization is not correct.
The correct partial specialization is:
---
struct Template2(T)
{
enum tString = T.stringof;
static if (is(T == class))
enum tLinkage = __traits(getLinkage, T);
}
struct Template1(Param1, Param2 = Template2!Param1) {}
alias AliasTemplate1S(SecondParam) = Template1!(S,SecondParam);
//^here
class S
{
Template1!int x;
}
---
Now that being said, the compiler could complain about the
incorrect partial spec instead of falling in the nonsensical
error message.
There is a gap because the second template param looks optional
so you dont put it the partial specialization but it is still
required.
Anyway. This case is either a "bad diagnostic" or an
"enhancement" request.
Or should be specified.
Thanks a lot! In my case what I was intending was:
alias AliasTemplate1S = Template1!(S, Template2!S)
which as you suggest works fine. It's a bit odd that the
non-optional second parameter becomes optional again if
declaration order is shuffled, but my motivation to look into
this has temporarily abated since it's no longer stopping me from
doing something else.
For the program where I ran into this problem the most convenient
fix turns out to be to get rid of the default template parameter
and instead use a pattern like this:
---
struct Template1(Param1, Param2) {}
alias Template1(Param1) = Template1!(Param1, Template2!Param1);
---
Is this a compiler error? "recursive template expansion"
The following code fails to compile. Is this a compiler error or
if not what is wrong with the code?
---
struct Template2(T)
{
// If both of the following are removed compilation succeeds
// without any other changes:
enum tString = T.stringof;
static if (is(T == class))
enum tLinkage = __traits(getLinkage, T);
}
struct Template1(Param1, Param2 = Template2!Param1) {}
// Moving the definition of AliasTemplate1S after the definition
of S
// causes compilation to succeed without any other changes.
alias AliasTemplate1S = Template1!S;
class S
{
// If the following line is removed compilation succeeds
// without any other changes.
Template1!int x;
}
void main()
{
}
---
Failure message:
main.d(20): Error: struct main.Template1(Param1, Param2 =
Template2!Param1) recursive template expansion
main.d(20):while looking for match for Template1!int
main.d(7): Error: class S is forward referenced
main.d(10): Error: template instance main.Template2!(S) error
instantiating
main.d(14):instantiated from here: Template1!(S)
Re: std.conv.ConvException from double to uint64_t, but only locally in a large project
On Tuesday, 4 August 2020 at 17:49:56 UTC, drathier wrote: Replaced all mentions of uint64_t with ulong, and now it works. Must have an enum called uint64_t defined somewhere in a library I depend on or something? Really wish this was clearer. BTW I believe the reason that `uint64_t` is an enum (which is being imported by "import std" but isn't converting) solely on macOS/iOS is for compatibility with C++ name mangling.
Re: Why is this allowed
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote: Spent some time debugging because I didn't notice it at first, essentially something like this: int[3] foo = [1, 2, 3]; foo = 5; writeln(foo); // 5, 5, 5 Why does such code compile? I don't think this should be permitted, because it's easy to make a mistake (when you wanted foo[index] but forgot the []). If someone wants to assign a value to every element they could do foo[] = 5; instead which is explicit. What's your opinion on using that syntax in the initial declaration, like `float[16] foo = 0`?
Re: Distinguish between a null array and an empty array
On Sunday, 24 May 2020 at 12:12:31 UTC, bauss wrote: Is there a way to do that? Since the following are both true: int[] a = null; int[] b = []; assert(a is null); assert(!a.length); assert(b is null); assert(!b.length); What I would like is to tell that b is an empty array and a is a null array. Yes you can tell: your `is null` check actually works, the part that doesn't work is that `int[] b = []` is initializing b to null. Here's an example: --- int[0] emptyArray; int[] a = null; // a.ptr is null, a.length is 0 int[] b = emptyArray[]; // b.ptr is non-null, b.length is 0 assert(a is null); assert(!a.length); assert(b !is null); assert(!b.length); ---
Re: link error on Windows
On Tuesday, 19 May 2020 at 04:54:38 UTC, Joel wrote: I tried with DMD32 D Compiler v2.088.1-dirty, and it compiled and created an exe file, but not run (msvcr100.dll not found - and tried to find it on the net without success). DMD 2.089 changed the default linking options. I bet an up-to-date DMD will also work if you invoke it as "dmd -m32mscoff". It should also work if you build it in 64-bit mode.
Re: AA code 50x slower
On Sunday, 16 February 2020 at 12:57:43 UTC, AlphaPurned wrote:
template AA(string[] S)
{
auto _do() { int[string] d; foreach(s; S) d[s] = 0; return d; }
enum AA = _do;
}
if (t in AA!(["a", "and", "mp4", "mp3", "the", "with", "live",
"no", "&", "of", "band"])) continue;
The if statement literally causes a 50x slow down of the code.
(LDC debug, dmd debug takes about 1000 times longer)
template AA(string[] S) {
__gshared int[string] AA;
shared static this() {
int[string] d;
foreach (s; S)
d[s] = 0;
AA = d;
};
}
if (t in AA!(["a", "and", "mp4", "mp3", "the", "with", "live",
"no", "&", "of", "band"])) continue;
This will have the performance you want if you don't care whether
it works in CTFE.
How to get the name of an object's class at compile time?
What I want is something like this:
string className(in Object obj) {
return obj is null ? "null" : typeid(obj).name;
}
...except I want it to work in CTFE. What is the way to do this
in D?
Re: Is there a way to slice non-array type in @safe?
On Thursday, 11 July 2019 at 16:31:58 UTC, Stefanos Baziotis
wrote:
I searched the forum but did not find something.
I want to do this:
int foo(T)(ref T s1, ref T s2)
{
const byte[] s1b = (cast(const(byte)*))[0 .. T.sizeof];
const byte[] s2b = (cast(const(byte)*))[0 .. T.sizeof];
}
Which is to create a byte array from the bytes of the value
given, no matter
the type. The above works, but it's not @safe.
Thanks,
Stefanos
If you know that what you're doing cannot result in memory
corruption but the compiler cannot automatically infer @safe, it
is appropriate to use @trusted. (For this case make sure you're
not returning the byte slices, since if the arguments were
allocated on the stack you could end up with a pointer to an
invalid stack frame. If it's the caller's responsibility to
ensure the slice doesn't outlive the struct then it is the caller
that should be @trusted or not.)
Is there any way to define an interface that can implicitly convert to Object?
I want to be able to do things like:
---
bool isSame(Object a, Object b) { return a is b; }
interface SomeInterface { int whatever(); }
bool failsToCompile(SomeInterface a, SomeInterface b) { return
isSame(a, b); }
---
Error: function isSame(Object a, Object b) is not callable using
argument types (SomeInterface, SomeInterface)
Is there a way to declare an interface as explicitly not a COM
interface or a C++ interface? Having to add "cast(Object)"
everywhere is annoying.
Re: Casting to interface not allowed in @safe code?
On Sunday, 23 June 2019 at 21:24:14 UTC, Nathan S. wrote: https://issues.dlang.org/show_bug.cgi?id=2. The fix for this has been accepted and is set for inclusion in DMD 2.080.
Re: Casting to interface not allowed in @safe code?
On Tuesday, 21 May 2019 at 07:59:13 UTC, Jim wrote: On Tuesday, 21 May 2019 at 07:33:17 UTC, rumbu wrote: On Tuesday, 21 May 2019 at 07:16:49 UTC, Jim wrote: On Tuesday, 21 May 2019 at 07:04:27 UTC, rumbu wrote: On Tuesday, 21 May 2019 at 05:51:30 UTC, Jim wrote: That's because foo is of type Base, not implementing FeatureX. Right, Base isn't implementing FeatureX, but foo is really a Foo That's your knowledge, for the compiler foo is really a Base, as written in your own code. Yes, thinking about it again it makes sense. It doesn't even slightly make sense. I just ran into this today myself. Unlike Java and C#, casting from Foo to FeatureX is not an assertion that the Foo implements FeatureX. Instead it's how you test at runtime if the class of a specific object derived from Foo implements FeatureX: if it doesn't then the result of the cast is null. I've opened a bug report at https://issues.dlang.org/show_bug.cgi?id=2.
Re: Function parameter type inference: is this example working as intended?
On Wednesday, 5 September 2018 at 02:33:47 UTC, Nathan S. wrote: The below writes "uint". Is this working as intended? https://run.dlang.io/is/Dx2e7f Note that it's called not with a `ulong` literal but with a `long` literal.
Function parameter type inference: is this example working as intended?
The below writes "uint". Is this working as intended?
https://run.dlang.io/is/Dx2e7f
---
import std.stdio;
auto foo(T = uint)(uint x)
{
return T.stringof;
}
auto foo(T = ulong)(ulong x)
{
return T.stringof;
}
void main()
{
writeln(foo(10L));
}
---
Re: Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
On Wednesday, 27 June 2018 at 22:39:26 UTC, Jonathan M Davis
wrote:
You could explicitly instantiate the function template and then
take its address.
Explicitly instantiating the template can result in a function
that may be behaviorally identical but have a different address.
https://run.dlang.io/is/E9WroB
---
auto foo(T)(const T x) { return x; }
void main()
{
const int a;
assert(!int !is !(const int)); // The addresses are
different.
foo(a); // If I look in the object file I can see this uses
foo!int.
assert(!(typeof(a)) !is !int);
}
---
Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
Let's say there's a function template `doImpl` and `doImpl(x)` compiles thanks to IFTI. Is there any way to get the address of the function that would be called in `doImpl(x)`?
Re: template recursion
On Tuesday, 26 June 2018 at 20:47:27 UTC, Steven Schveighoffer wrote: Naming the hook for `put` the same thing as the global function was one of the biggest mistakes in the range library. I almost think we would be better off to deprecate that and pick another hook name. If you ever do that it would also be nice to use separate names for "put a single X into Y" and "put everything from container X into Y".
Re: Nullable!T with T of class type
On Monday, 25 June 2018 at 22:58:41 UTC, Jonathan M Davis wrote: Java does try to force you to initialize stuff (resulting in annoying false positives at times), but in general, it still can't guarantee when a variable is null or not and is forced to insert runtime null checks. Java can be somewhat clever about this though. Often it just needs to perform a single null check in a method body and thereafter knows the pointer can't be null and elides the check.
Re: Nullable!T with T of class type
On Monday, 25 June 2018 at 19:40:30 UTC, kdevel wrote:
Is it possible
to "lower" the Nullable operations if T is a class type such
that there
is only one level of nullification?
Yes: https://run.dlang.io/is/hPxbyf
template Nullable(S)
{
import std.traits : isPointer, isDynamicArray;
static if (is(S == class) || is(S == interface)
|| is(S == function) || is(S == delegate)
|| isPointer!S || isDynamicArray!S)
{
alias Nullable = S;
}
else
{
static import std.typecons;
alias Nullable = std.typecons.Nullable!S;
}
}
Re: Delegates and classes for custom code.
On Tuesday, 17 April 2018 at 04:09:57 UTC, Chris Katko wrote: I'm having trouble conceptualizing this issue at the moment. But it seems if I pass to the delegate my object, then I can ONLY use one class type. Can you post the code you're trying to run?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 22:56:31 UTC, Jonathan M Davis wrote: The downside is that it increases the number of symbols which the program has to deal with when linking against a shared library, which can have some negative effects. - Jonathan M Davis If I understand correctly it's also responsible for TypeInfo being generated for private classes regardless of whether or not it is ever used.
Re: "Error: address of variable this assigned to this with longer lifetime"
On Tuesday, 13 March 2018 at 22:33:56 UTC, Jonathan M Davis wrote: And you can't get rid of it, because the object can still be moved, which would invalidate the pointer that you have referring to the static array. ... https://issues.dlang.org/show_bug.cgi?id=17448 Thanks for the info.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 21:36:13 UTC, Arun Chandrasekaran wrote: On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote: On 3/12/18 10:06 PM, psychoticRabbit wrote: [...] OK, so I agree there are drawbacks. But these can be worked around. [...] Private members still have external linkage. Is there anyway to solve this? Yeah that's a real WTF.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote: what I don't like, is that I have no way at all to protect members of my class, from things in the module, without moving that class out of that module. D wants me to completely trust the module, no matter what. That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are) I used to feel similarly and understand where you're coming from but after using D for a while the old way feels ridiculous and cumbersome to me. The problem of accidents even in large files can be avoided by using names like "m_length" or "_length": no jury in the world will believe you if you write those then say you didn't know they were private.
Re: "Error: address of variable this assigned to this with longer lifetime"
On Tuesday, 13 March 2018 at 21:07:33 UTC, ag0aep6g wrote: You're storing a reference to `small` in `data`. When a SmallString is copied, that reference will still point to the original `small`. When the original goes out of scope, the reference becomes invalid, a dangling pointer. Can't have those in @safe code. The error message isn't exactly clear, though. The error does not go away when restoring these lines: ``` @disable this(this); @disable void opAssign(this); ```
"Error: address of variable this assigned to this with longer lifetime"
What is this malarky?
https://run.dlang.io/is/S42EBb
"onlineapp.d(16): Error: address of variable this assigned to
this with longer lifetime"
```d
import std.stdio;
struct SmallString
{
char[24] small;
char[] data;
@disable this();
this(scope const(char)[] s) @safe
{
if (s.length < small.length)
{
small[0 .. s.length] = s[];
small[s.length] = 0;
data = small[0 .. s.length];
}
else
{
assert(0, "Compilation failed before I wrote this.");
}
}
}
void main()
{
writeln("Hello D");
}
```
Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2
Cross-posting from the github issue
(https://github.com/libmir/mir-random/issues/77) with a
workaround (execute it at https://run.dlang.io/is/Swr1xU):
I am not sure what the correct interface should be for this in
the long run, but for now you can use a wrapper function to
convert an ndvariable to a variable:
```d
/++
Converts an N-dimensional variable to a fixed-dimensional
variable.
+/
auto specifyDimension(ReturnType, NDVariable)(NDVariable vr)
if (__traits(isStaticArray, ReturnType) && __traits(compiles,
{static assert(NDVariable.isRandomVariable);}))
{
import mir.random : isSaturatedRandomEngine;
import mir.random.variable : isRandomVariable;
static struct V
{
enum bool isRandomVariable = true;
NDVariable vr;
ReturnType opCall(G)(scope ref G gen) if
(isSaturatedRandomEngine!G)
{
ReturnType ret;
vr(gen, ret[]);
return ret;
}
ReturnType opCall(G)(scope G* gen) if
(isSaturatedRandomEngine!G)
{
return opCall!(G)(*gen);
}
}
static assert(isRandomVariable!V);
V v = { vr };
return v;
}
```
So `main` from your above example becomes:
```d
void main()
{
import std.stdio;
import mir.random : Random, threadLocalPtr;
import mir.random.ndvariable : multivariateNormalVar;
import mir.random.algorithm : range;
import mir.ndslice.slice : sliced;
import std.range : take;
auto mu = [10.0, 0.0].sliced;
auto sigma = [2.0, -1.5, -1.5, 2.0].sliced(2,2);
Random* rng = threadLocalPtr!Random;
auto sample = rng
.range(multivariateNormalVar(mu,
sigma).specifyDimension!(double[2]))
.take(10);
writeln(sample);
}
```
Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2
On Tuesday, 27 February 2018 at 16:42:00 UTC, Nathan S. wrote: On Tuesday, 27 February 2018 at 15:08:42 UTC, jmh530 wrote: Nevertheless, it probably can't hurt to file an issue if you can't get something like the first one to work. I would think it should just work. The problem is that `mir.random.ndvariable` doesn't satisfy `mir.random.variable.isRandomVariable!T`. ndvariables have a slightly different interface from variables: instead of of `rv(gen)` returning a result, `rv(gen, dst)` writes to dst. I agree that the various methods for working with variables should be enhanced to work with ndvariables. So, I see that the interface will have to be slightly different for ndvariable than for variable. With the exception of MultivariateNormalVariable, the same ndvariable instance can be called to fill output of any length "n", so one can't meaningfully create a range based on just the ndvariable without further specification. What would "front" return? For MultivariateNormalVariable "n" is constrained but it is a runtime parameter rather than a compile-time parameter. You'll want to ping @9il / Ilya Yaroshenko to discuss what the API should be like for this.
Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2
On Tuesday, 27 February 2018 at 15:08:42 UTC, jmh530 wrote: Nevertheless, it probably can't hurt to file an issue if you can't get something like the first one to work. I would think it should just work. The problem is that `mir.random.ndvariable` doesn't satisfy `mir.random.variable.isRandomVariable!T`. ndvariables have a slightly different interface from variables: instead of of `rv(gen)` returning a result, `rv(gen, dst)` writes to dst. I agree that the various methods for working with variables should be enhanced to work with ndvariables.
Re: std.traits.isBoolean
On Monday, 19 February 2018 at 15:12:15 UTC, Tony wrote: But, assuming there is a use case for it, what if you want to restrict to a type that is either boolean, or a struct/class that can substitute for boolean - how do you do that without using the "private" TypeOfBoolean thing? In that case you can just write `is(T : bool)`.
Re: Size threshold replace complex probing with linear search for small hash tables
On Monday, 19 February 2018 at 10:22:12 UTC, Nordlöw wrote: I'm currently developing a combined HashMap and HashSet with open addressing You might want to consider using Robin Hood hashing to reduce the worst-case length of collision chains, regardless of what kind of probing scheme you use.
Re: opCast cannot implicitly convert a.opCast of type X to Y
On Monday, 12 February 2018 at 02:05:16 UTC, aliak wrote:
struct B(T) {
T t;
}
struct A(T) {
T t;
auto opCast(U)() {
return B!U(cast(U)t);
}
}
void main() {
auto a = A!int(3);
auto b = cast(float)a; // error
}
Having the result of "cast(float) a" not be a float would be evil.
Re: What does "(this This)" mean in member function templates?
On Monday, 12 February 2018 at 08:42:42 UTC, rikki cattermole wrote: https://dlang.org/spec/template.html#TemplateThisParameter Cheers.
What does "(this This)" mean in member function templates?
For example in std.container.rbtree:
---
auto equalRange(this This)(Elem e)
{
auto beg = _firstGreaterEqual(e);
alias RangeType = RBRange!(typeof(beg));
if (beg is _end || _less(e, beg.value))
// no values are equal
return RangeType(beg, beg);
static if (allowDuplicates)
{
return RangeType(beg, _firstGreater(e));
}
else
{
// no sense in doing a full search, no duplicates are
allowed,
// so we just get the next node.
return RangeType(beg, beg.next);
}
}
---
Re: new int[]
On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
If I understand correctly, the goal is to have the `int[]`
itself on the GC heap.
The code
void main(string[] args) @nogc
{
int[] x = [1, 2, 3];
}
won't compile, because "array literal in @nogc function 'D main'
may cause GC allocation". But "may" isn't the same as "will".
What determines it? That's a kind of goofy error message now that
I think about it.
Re: new int[]
Is there any problem with:
import std.stdio;
void main(string[] args)
{
int[] x = [1, 2, 3];
writeln(x);
}
https://run.dlang.io/is/CliWcz
Re: Does LDC support profiling at all?
On Friday, 22 December 2017 at 09:52:26 UTC, Chris Katko wrote: DMD can use -profile and -profile=gc. But I tried for HOURS to find the equivalent for LDC and came up with only profile-guided optimization--which I don't believe I want. Yet, if we can get PGO... where's the PROFILE itself it's using to make those decisions! :) Thanks. Is -fprofile-instr-generate= what you're looking for?
Re: why ushort alias casted to int?
On Friday, 22 December 2017 at 10:42:28 UTC, crimaniak wrote: Hm, really. ok, I will use the explicit cast, but I don't like it. It's because the C programming language has similar integer promotion rules. That doesn't make it any more convenient if you weren't expecting it but that is the reason behind it.
Re: How to catch line number of exception without catching it ?
On Wednesday, 13 December 2017 at 18:24:09 UTC, Thomas wrote: So my question is: Is there a way to catch that line where the exception has happened without a catch ? Yes: use a debugger.
Re: Static array as immutable
On Tuesday, 12 December 2017 at 11:37:40 UTC, Jonathan M Davis
wrote:
On Tuesday, December 12, 2017 10:35:15 Ivan Trombley via
Digitalmars-d-learn wrote:
On Tuesday, 12 December 2017 at 09:48:09 UTC, Jonathan M Davis
wrote:
> On Tuesday, December 12, 2017 07:33:47 Ivan Trombley via
>
> Digitalmars-d-learn wrote:
>> Is there some way that I can make this array immutable?
>>
>>static float[256] ga = void;
>>static foreach (i; 0 .. 256)
>>
>>ga[i] = (i / 255.0f) ^^ (1 / 2.2f);
>
> If you want anything to be immutable, you either have to
> initialize it directly or give it a value in a static
> constructor (and the static constructor solution won't work
> for local variables). So, you'd need to do something like
>
> static immutable float[256] ga = someFuncThatGeneratesGA();
>
> If the function is pure, and there's no way that the return
> value was passed to the function, then its return value can
> be assigned to something of any mutability, since the
> compiler knows that there are no other references to it, and
> it can implicitly cast it, or if the type is a value type
> (as in this case), then you just get a copy, and mutability
> isn't an issue. Alternatively to using a pure function, you
> can use std.exception.assumeUnique to cast to immutable, but
> that relies on you being sure that there are no other
> references to the data, and it may not work at compile-time,
> since casting is a lot more restrictive during CTFE. So, in
> general, using a pure function is preferable to assumeUnique.
>
> - Jonathan M Davis
Ah, it doesn't work. I get this error using the ^^ operator:
/usr/include/dmd/phobos/std/math.d(5724,27): Error: cannot
convert to ubyte* at compile time
/usr/include/dmd/phobos/std/math.d(6629,24):called from
here: signbit(x)
/usr/include/dmd/phobos/std/math.d(6756,16):called from
here: impl(cast(real)x, cast(real)y)
:(
Well, if the code you need to initialize a variable can't be
run at compile time, then that variable can't be a variable
that needs to be initialized at compile time and be immutable.
- Jonathan M Davis
While what you're saying is true, exponentiation not being
runnable at compile-time is a defect and I would assume a
regression. I'll file a bug report. FWIW when trying to run the
following with DMD v2.077.1 I get:
```
void main(string[] args)
{
import std.stdio;
enum e = (1.0 / 255.0f) ^^ (1 / 2.2f);
writeln("e = ", e);
}
```
=>
[...]/dmd/std/math.d(440): Error: y.vu[4] is used before
initialized
[...]/dmd/std/math.d(413):originally uninitialized here
[...]/dmd/std/math.d(4107):called from here: floorImpl(x)
[...]/dmd/std/math.d(2373):called from here: floor(x +
0.5L)
[...]/dmd/std/math.d(2110):called from here: exp2Impl(x)
[...]/dmd/std/math.d(6743):called from here: exp2(yl2x(x,
y))
[...]/dmd/std/math.d(6756):called from here:
impl(cast(real)x, cast(real)y)
Re: minElement on array of const objects
Unqual!Element seed = r.front; alias MapType = Unqual!(typeof(mapFun(CommonElement.init))); This looks like a job for std.typecons.Rebindable!(const A) instead of Unqual!(const A) which is used currently. I am surprised that this is the first time anyone has run into this.
Re: How to use containers in lock based concurrency
Is this advice from 2015 outdated? I found it while I was wrestling with shared data structures, and after reading I stopped doing that. https://p0nce.github.io/d-idioms/#The-truth-about-shared The truth about shared It's unclear when and how shared will be implemented. Virtually noone use shared currently. You are better off ignoring it at this moment.
Re: private keyword dont appear to do anything
On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote: Most folks are surprised by this behavior I found it surprising at first but now any other way seems absurd to me. None of the benefits of data encapsulation apply to code written five lines away in the same file.
Re: Is there further documentation of core.atomic.MemoryOrder?
Thank you. For anyone else with the same question, I also found this page helpful: http://en.cppreference.com/w/cpp/atomic/memory_order
Is there further documentation of core.atomic.MemoryOrder?
Is there a formal description of "hoist-load", "hoist-store", "sink-load", and "sink-store" as used in core.atomic.MemoryOrder (https://dlang.org/library/core/atomic/memory_order.html)?
