On Friday, 1 January 2021 at 23:14:43 UTC, Rekel wrote:
I seem to have hit a bit of a wall when comparing D enums to
Java enums.
Of course the latter is just a fancy class, though it'd be nice
to see partially equivalent usefulness regardless.
For example, as soon as non-integer, non-string va
On Saturday, 2 January 2021 at 00:57:48 UTC, Paul wrote:
So this neither seems a satisfiable solution to me :/
Couldn't you just use Wind.N.hashOf and a custom format()
expression for string-representation?
I have a GUI created using Qt Creator and save it to .ui file. I
can convert .ui file to .cpp or .py (C++ or Python), but I can
not convert .ui to .d for use with Dlang and QtE5.
It seems w.to!string works in conjunction with Wind.N.stringof,
though I wonder about the efficiency/wastefulness of this method.
Sadly this also leads to very funny behavior when some of the
enums have the same value, as to!string(Enum) will yield the name
of the first of these enums having the
On 1/1/21 5:07 PM, Selim Ozel wrote:
I created the simplest possible example as explained by the Vibe-D
community in [1]. The exact source code of what I run is in [2].
On Windows I get a socket handle leak warning on shutdown with crtl+c
from terminal after running the executable.
[main(--
On Thursday, 18 January 2018 at 16:31:02 UTC, ag0aep6g wrote:
I'm interpreting that to mean that it will become an error for
some time, but later it will be allowed again with the new
behavior. And then you can throw away `-transition=intpromote`.
Seeing as it's almost 3 years later, I'd like
I seem to have hit a bit of a wall when comparing D enums to Java
enums.
Of course the latter is just a fancy class, though it'd be nice
to see partially equivalent usefulness regardless.
For example, as soon as non-integer, non-string values are given
to enums things get messy for me when usi
I created the simplest possible example as explained by the
Vibe-D community in [1]. The exact source code of what I run is
in [2].
On Windows I get a socket handle leak warning on shutdown with
crtl+c from terminal after running the executable.
[main() INF] Listening for requests on ht
On Friday, 1 January 2021 at 18:00:57 UTC, SealabJaster wrote:
Meanwhile I believe C++ (keep in mind I very rarely touch or
look at C++) already has a standard allocator interface that
parts of the STL (and I assume libraries, when/if they care)
are able to use? I'm unaware of the issues it mig
On Friday, 1 January 2021 at 16:45:16 UTC, Ola Fosheim Grøstad
wrote:
I don't know anything about any official positions other than
the fact that Walter dislikes having more than one pointer type
and is working on some kind of "liveness" verification for a
C-style free/malloc regime, which is r
On 12/31/20 8:54 PM, Adam D. Ruppe wrote:
On Friday, 1 January 2021 at 01:43:50 UTC, Chris Bare wrote:
a1[10] = "testing a1";
this actually constructs a new thing since it is a straight x = y
assignment.
a2[10].name = "testing a2";
But this looks up something first. It do
On Thursday, 31 December 2020 at 07:17:45 UTC, RSY wrote:
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto
wrote:
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:
On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:
[...]
C++ you need to write duplicate code (.h
On Friday, 1 January 2021 at 16:23:45 UTC, SealabJaster wrote:
Slightly off but also on topic but, has there been any general
consensus yet around standard pointer types (e.g. shared_ptr)
and standard allocator-aware data structures, or just in
general any discussions around non-GC memory manag
On Friday, 1 January 2021 at 15:12:43 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote:
one big move would be to finally put the allocators out of
std.experimental, and finally embrace this everywhere (just
like ziglang)
I am bit torn on this, the less the
On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote:
one big move would be to finally put the allocators out of
std.experimental, and finally embrace this everywhere (just
like ziglang)
I am bit torn on this, the less the compiler knows about
allocation strategies, the less opportunity there
On Thursday, 31 December 2020 at 19:57:53 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe
wrote:
On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim
Grøstad wrote:
What would you like to see?
For shared to mean something.
Stackless corout
That's a fantastic answer! Thank you. I was not aware that
initializers were always compile time, that was the missing piece
in my understanding.
It's a shame that I can't use the nicer (IMO) syntax, but the
reasoning is sound.
On Friday, 1 January 2021 at 13:34:16 UTC, Adam wrote:
A a = new A; // I would expect this to be called for each
"new B".
Your expectation is wrong for D. Since that's in a `static`
context, it is run at compile time.
Any variable marked `static`, `__gshared`, or is
struct/class/module-
Consider the following:
class A
{
int x;
}
class B
{
A a = new A; // I would expect this to be called for each
"new B".
}
void main()
{
import std.stdio;
auto c = new B;
writeln("c ", c.a.x);
c.a.x++;
writeln("c ", c.a.x);
writeln;
auto d = new B;
wri
19 matches
Mail list logo
