Re: Announcing audio-formats v1.0.0
Guillaume Piolat wrote: Any input concerning stb_vorbis vs Tremor? Tremor is twice the code size and I'm not sure the one to be favoured. tbh, i didn't really tested stb much (if at all). it *should* work, but... my audio player was based on tremor, so it is better tested. maybe just make `version`, and let the user decide? ;-)
Re: Announcing audio-formats v1.0.0
Guillaume Piolat wrote: On Wednesday, 18 March 2020 at 18:49:23 UTC, ketmar wrote: glad you found it useful! but why only that? there is GPL Opus decoder too, and two decoders for Ogg/Vorbis: stb and complete port of the official Xyph tremor library. also, you can find a resampler there, taken from Speex. are you planning to use those too in the future? It's a triple "yes". I haven't yet found the time to do it but figured it could be useful already :) Hope you are well ketmar. yeah. and thank you for your work! that code was simply rotting there, but now people may find some use for it. i am very bad at making my code useful for others, so i really appreciate your efforts! thanks again!
Re: Announcing audio-formats v1.0.0
Guillaume Piolat wrote: On Wednesday, 18 March 2020 at 18:41:11 UTC, Guillaume Piolat wrote: audio-formats is a new pure D #DUB package that allows to decode and encode audio files. Also: it's just a custom repackaging of the huge work of Ketmar. https://repo.or.cz/iv.d.git glad you found it useful! but why only that? there is GPL Opus decoder too, and two decoders for Ogg/Vorbis: stb and complete port of the official Xyph tremor library. also, you can find a resampler there, taken from Speex. are you planning to use those too in the future?
Re: The effect of ref
Adam D. Ruppe wrote: On Friday, 22 November 2019 at 03:42:26 UTC, dokutoku wrote: Is there a difference in the execution speed and stability when executing the program by rewriting the parameter of the function argument like this? the generated code the processor sees is generally identical, but the `ref` version is potentially better because then X cannot possibly be `null` which can help you write better code and might help the optimizer too. still, using explicit pointers may be good for readability. int a; foo(a); // does it chage `a`? boo(); // oh, yeah, now i see that it will prolly change `a` unsafe coding style, but for me pointers for `ref` are more readable.
Re: I was able to write some D last week!
Adam D. Ruppe wrote: I am bumping the arsd repo dub's version number to 4.0.0. (this is super super arbitrary for me though, I very rarely ACTUALLY break backward compatibility, in fact I try to be both backward and forward compatible with myself and with dmd versions, just meh) yay, so your cgi.d and template modules are ready for public now! great.
Re: now it's possible! printing floating point numbers at compile-time
H. S. Teoh wrote: actually, there is a 3rd issue, which is often overlooked: conversion from string to float. to get a perfect roundtrip, this one should be done right too. Doesn't hex output format (e.g. std.format's %a and %A) already solve this? It basically outputs the exact bits in hex. No room for error there. it does. but then you can simply go with writing binaries as-is -- they are not really less readable than hex floats. ;-) but we want decimals! ;-)
Re: now it's possible! printing floating point numbers at compile-time
Basile B. wrote: On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote: too bad that i didn't knew about Ryu back than. It's very recent, announce on proggit is < 1 year. It would be nice to have one to format in phobos. RYU or Grisu3 doesn't matter much as long as the two issues that are - CTFE formatting of floats - formatting is identical on all platforms actually, there is a 3rd issue, which is often overlooked: conversion from string to float. to get a perfect roundtrip, this one should be done right too. is solved. There's also the "real" problem. I'm pretty sure that 32 and 64 bits floats are always handled. Someteimes 128 bits ones but not sure for 80 bits... 80 bits can (usually) be extended to 128. you'll get some extra meaningless digits, of course, but it is better than nothing, i think. actually, Ryu has all the math to derive 80-bit implementation. it will require 128-bit integers, though. (less than 128, but there is no sense in using smaller ints anyway).
Re: now it's possible! printing floating point numbers at compile-time
i think that porting Ryu will get us the fastest one (and with smaller/easier code). and without pathological cases of grisu too. too bad that i didn't knew about Ryu back than. as for roundtrips -- you're probably right. stb implementation was made to be "mostly correct", afair, but not fully correct. or i broke something (which is very possible). it worked for my cases, tho, so i just sticked with it. anyway, two is better than one! ;-)
Re: now it's possible! printing floating point numbers at compile-time
Stefan Koch wrote: Hi Guys, during my research on floating point numbers I came across a short and efficient implementation[0] of the grisu2 algorithm for converting floating point numbers into strings. Which I then ported into CTFEable D code. Thus enabling you to convert doubles into strings at compiletime. Cheers Stefan Koch P.S. You can find it at my fork of fpconv[1]. [0] https://github.com/night-shift/fpconv [1] https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d of course, it is not all that fancy, but i ported STB converter quite a long time ago, and it is ctfe-able too. ;-) [0] https://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d
Re: -O flag ; automatic cast in a bitshift
Guillaume Lathoud wrote: this is UB. by the specs, values are promoted to int, and shifting int by 50 is UB. so both results are nonsense.
Re: float/double to string (pure nothrow @nogc)
vit wrote:
thanks, that code can be modified to pure nothrow @nogc @safe.
Is that lib ok? Is little complicated...
converting float to string is a *very* complicated task. that lib is quite
small for what it is doing ('cause it hacks around some... interesting
cases). the *real* thing will be a LOT bigger.
Re: float/double to string (pure nothrow @nogc)
vit wrote: Hello, is in phobos some function which convert float/double to string and is pure @nogc and nothrow? i don't think that you can make it `pure`, but you certainly can make it `nothrow`, `@nogc` and ctfe-able. it's dangerous to go alone! take this[0]. [0] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d
Re: @safe - why does this compile?
Johan Engelen wrote: On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote: yeah. in simple words: safe code is *predictable*, but not "segfault-less". segfaults (null dereferences) in safe code are allowed, 'cause they have completely predictable behavior (instant program termination). @safe doesn't free you from doing your null checks, it protects you from so-called "undefined behavior" (aka "unpredictable execution results"). so when we are talking about "memory safety", it doesn't mean that your code cannot segfault, it means that your code won't corrupt random memory due to misbehaving. This is not true when using LDC (and I'd expect the same for GDC). With LDC, dereferencing `null` is undefined behavior regardless of whether you are in an @safe context or not. - Johan p.s.: it worth noting that *program* *state* is undefined after null dereference, though. i.e. program cannot continue execution, and must be aborted. in this sense, null dereferencing is defined behavior: it aborts the app unconditionally. and if you will catch segfault with some OS mechanics, you still cannot reliably do *anything* except immediately aborting (strictly speaking, this is true for any `Error` condition, even for asserts). so compiler *can* assume that null dereferencing is something code generally won't do, but it cannot do any optimisations assuming that code will not dereference nulls at all (dmd -O, afair, was guilty of some such optimisations too). so, code can dereference null, and it will be immediately aborted, without any chance to perform cleanup (as program state is undefined after this operation). in this sense, null dereferencing is "defined behavior".
Re: @safe - why does this compile?
Johan Engelen wrote: On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote: yeah. in simple words: safe code is *predictable*, but not "segfault-less". segfaults (null dereferences) in safe code are allowed, 'cause they have completely predictable behavior (instant program termination). @safe doesn't free you from doing your null checks, it protects you from so-called "undefined behavior" (aka "unpredictable execution results"). so when we are talking about "memory safety", it doesn't mean that your code cannot segfault, it means that your code won't corrupt random memory due to misbehaving. This is not true when using LDC (and I'd expect the same for GDC). With LDC, dereferencing `null` is undefined behavior regardless of whether you are in an @safe context or not. - Johan then those compilers are broken, and should be fixed.
Re: @safe - why does this compile?
Steven Schveighoffer wrote: To emphasize the point, this is @safe as well: X2 x2; // = null x2.run(); D does not consider a segmentation fault due to null dereferencing to be unsafe -- no memory corruption happens. yeah. in simple words: safe code is *predictable*, but not "segfault-less". segfaults (null dereferences) in safe code are allowed, 'cause they have completely predictable behavior (instant program termination). @safe doesn't free you from doing your null checks, it protects you from so-called "undefined behavior" (aka "unpredictable execution results"). so when we are talking about "memory safety", it doesn't mean that your code cannot segfault, it means that your code won't corrupt random memory due to misbehaving.
Re: @safe - why does this compile?
Piotr Mitana wrote:
This code:
import std.stdio;
class X1 {}
class X2 : X1
{
void run() @safe
{
writeln("DONE");
}
}
void main() @safe
{
X1 x1 = new X1;
X2 x2 = cast(X2) x1;
x2.run();
}
is obviously wrong gets killed by OS's signal. Why is it @safe? I thought
@safe should prevent such errors as well.
there is nothing wrong here. dereferencing null reference is completely
safe (in terms of result predictability).
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote: Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. Right, i have used the wrong words. Title hopefully is not ambiguous. ah, tbh, i'm just being jealous. you did my work! me is useless now!
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote: Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. for a moment you made my heart stopped, 'cause i thought that i wasted alot of time trying to do a proper port (nope, not finished, but still...). Thanks. BTW I remember you said on IRC that SSA form is much better (maybe it was once when we talked about DMD optimizations or something like that)... this is basically why i choose this one, although not sure if i'll manage to do something with it. tbh, i gave up on porting it fully, so i prolly will go with your wrapper, if anything. and yeah, SSA rox. i am temporarily on C++ side now, yet sooner or later i'll return, and will have to restart Aliced again. maybe this time with a brand new backend. ;-)
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. for a moment you made my heart stopped, 'cause i thought that i wasted alot of time trying to do a proper port (nope, not finished, but still...).
Re: struct dtor never called, what's wrong?
Andrea Fontana wrote: I hope I'm wrong. Maybe I'm missing something. Anyone can help? you are not wrong, this is bug in DMDFE.
Re: Debugging silent exit of threads in Phobos calls
Steven Schveighoffer wrote: Can you put in some more debug messages and see what the exact types of A and T are? Just put it right before the assert. you prolly asked Russel here, as i don't have his sources to experiment with. ;-)
Re: Debugging silent exit of threads in Phobos calls
Russel Winder wrote: On Fri, 2018-06-01 at 17:53 +0300, ketmar via Digitalmars-d-learn wrote: […] it looks like "// type T is not constructible from A" phobos assertion triggered. that is, std.variant cannot wrap the struct, and all hell breaks loose. An instance of FrontendAppeared is created in frontend_manager module and sent to the actor defined in control_window module which has: import frontend_manager: FrontendAppeared It seems the symbol FrontendAppeared in control_window is matching the FrontendAppeared type of the message sent, and yet the assertion fails. it may be something with struct copying. variant wants to copy a struct into itself, and somehow failed. either there is no room, or something prevented it to do that. it is hard to say more without full source code.
Re: Debugging silent exit of threads in Phobos calls
Russel Winder wrote: On Fri, 2018-06-01 at 16:37 +0300, ketmar via Digitalmars-d-learn wrote: […] yeah. if it receives something it doesn't expect (and there is no `Variant` clause to catch it), it throws. and exceptions from threads are silently dropped on the floor -- along with the dead threads. so it is better to always wrap your threads in `try/catch`, and at least log an exception. It seems that in the case he presence of the Variant doesn't matter. The message sent is of type frontend_manager.FrontendAppeared and one of the receive types is frontend_manager.FrontendAppreared yet this fails to match but it is not treated as a Variant. The stack trace is: it looks like "// type T is not constructible from A" phobos assertion triggered. that is, std.variant cannot wrap the struct, and all hell breaks loose.
Re: Debugging silent exit of threads in Phobos calls
Steven Schveighoffer wrote: On 6/1/18 7:12 AM, Russel Winder wrote: So I had a play and gdb seems to be useless for trying to find out why calls to std.concurrency.receive exit silently. Obviously std.concurrency.receive should never terminate a thread, and it should never terminate a thread silently, but given that it clearly does (using dmd 2.080 from d-apt on Debian Sid) how is one to find out useful information as to why it is exiting silently. I remember something like a receive thread that throws terminates silently. Do a try/catch to see if it's that. -Steve yeah. if it receives something it doesn't expect (and there is no `Variant` clause to catch it), it throws. and exceptions from threads are silently dropped on the floor -- along with the dead threads. so it is better to always wrap your threads in `try/catch`, and at least log an exception.
Re: Sealed classes - would you want them in D?
H. S. Teoh wrote: p.s. and struct with `alias this` will allow us to extend it with fields too. not without using some other tricks, of course, but as there is a documented and ligitimate way to workaround any "sealing", i myself see a little sense in such feature. the only thing it will be good at is annoying users, who will be forced to write workarounds.
Re: Sealed classes - would you want them in D?
H. S. Teoh wrote: On Fri, May 11, 2018 at 05:28:48PM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] what the OP wants is to have the class be publicly available while restricting who's allowed to derive from it, with the idea that a particular class hierarchy would have a well-defined set of classes that the person who wrote them had full control over rather than allowing anyone and everyone to derive from any class in the hierarchy except for any final classes at the leaves of the hierarchy. [...] I would like to hear of a real-world use case for such a restriction. I honestly can't think of one that doesn't have a design smell of some sort. Isn't the whole point of OOP that user code can extend your classes to implement functionality you have not thought of, rather than you needing to implement everything for them? T besides, in D, there is a little sense in restricting class anyway, as we can kinda "extend" it with UFCS at any time.
Re: D IDE Coedit 3.6.7 - now with an integrated terminal emulator.
Basile B. wrote: I hadn't announced the 5 or 6 latest releases (3.6.x series) but this one comes with an integrated terminal emulator (linux only), a bit like Geany does, if you see what i mean. See https://github.com/BBasile/Coedit/releases for changelog and download links. yay!
Re: Compile-time variables
Kayomn wrote:
I'll give a better example of what it is I'm trying to do.
These are node types. Their contents are not important in this
explanation, only that they operate as a tree structure.
class Node;
class RootNode : Node;
class SpriteNode : Node;
The result of getNodeID on a specific type is always the same. A value
representing it that is applied during compilation. The value does not
matter to the programmer, only that it is unique and gets applied.
--
uint nodeId1 = getNodeID!(Node)(); // 0.
uint nodeId2 = getNodeID!(SpriteNode)(); // 1.
uint comparison = getNodeID!(Node)(); // 0.
// True.
if (getNodeID!(Node)() == getNodeID!(Node)()) {
}
// False.
if (getNodeID!(SpriteNode)() == getNodeID!(Node)()) {
}
--
it is already done for you, free of charge.
class Node {}
class RootNode : Node {}
class SpriteNode : Node {}
void main () {
auto nodeId1 = typeid(Node);
auto nodeId2 = typeid(SpriteNode);
auto comparison = typeid(Node);
Node n = new SpriteNode();
assert(typeid(Node) is typeid(Node)); // obviously
assert(typeid(SpriteNode) !is typeid(Node)); // sure
assert(typeid(Node) is nodeId1);
assert(typeid(n) is nodeId2);
}
Re: Initializing a class member that is an object
Laurent Tréguier wrote: On Friday, 30 March 2018 at 11:04:59 UTC, ketmar wrote: p.s.: still, it may be nice to warn user about that. 'cause such runtime initializations are really belong to static ctor. dunno, i'm ok both with warning and without it. I simply think a word about it in the docs would be nice, since this is tricky if you come from another language that doesn't do this. Otherwise I'm fine with it (and it's not exactly hard to fix either) please, make an ER in bugzilla then. 'cause it will be lost here, and with ER we have a chance to eventually do that.
Re: Initializing a class member that is an object
p.s.: still, it may be nice to warn user about that. 'cause such runtime initializations are really belong to static ctor. dunno, i'm ok both with warning and without it.
Re: Initializing a class member that is an object
Laurent Tréguier wrote: Is this behavior really intentional ? yes. default values should be the same for all objects. it is predictable, and allows to initialize objects to the known state simply by blitting `.init`. that is, default values aren't a syntax sugar for defining implicit ctor actions, they are executed once. this is by design.
Re: #import mapi.h
Martin Tschierschke wrote: or tutorial ok, tutorial: 1. learn C. 2. learn D. 3. DO IT! ;-)
Re: CTFE ^^ (pow)
Nicholas Wilson wrote: On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote: What is so hard about implementing a pow intrinsic that CTFE can use? It's ridiculous that we can't CTFE any non-linear function... It's one of those blocker bugs that's been there almost 10 years. Not all that much. Can you give me an example that does't work yet that you want to use? building gamma tables in CTFE. and LUT tables for XYZ color space.
Re: CTFE ^^ (pow)
Manu wrote: What is so hard about implementing a pow intrinsic that CTFE can use? It's ridiculous that we can't CTFE any non-linear function... It's one of those blocker bugs that's been there almost 10 years. nobody bothered. it is all done by intercepting calls in CTFE engine (using FQN mangled names), nothing very special. i once did it in my fork (but then mangling scheme was changed, and i never fixed the patch, lol).
Re: signbit question
Miguel L wrote: as the calculations on f guarantee it cannot be 0 at all. than `f` will become zero very soon. something that "cannot happen" is the most probable thing to happen. otherwise, LGTM.
Re: how to make private class member private
psychoticRabbit wrote: Whatever happened to the 'discussion' component of these 'discussions'? dunno. try to ask yourself, why repeating the same point again and again when you were given the answer and the rationale doesn't make a good discussion.
Re: how to make private class member private
psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote: psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes. do you know any other language, where a private class memeber, is not private to the class? (btw. that's a question, not a statement). that is, we should stick to defective design only 'cause there is no "other D" that made it right? ;-) also, your question is not valid. you were told several times that you're evaluating the whole thing wrong, but you're insisting on your view being right. and you're keep asking, omiting the *critical* piece of the picture: modules. you were told that in D, encapsulation unit is *module*, not class/struct. it is not a "misdesign", it is the proper modular design. it doesn't matter what others are doing in this case. p.s.: yes, i know such language. Delphi/FreePascal.
Re: how to make private class member private
psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes.
Re: how to make private class member private
psychoticRabbit wrote: On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote: psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it. umm...didn't you forget something: 1) it is not how C# done it. 2) it is not how C# done it. 1) it is not how Java done it. 2) it is not how Java done it. ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa!
Re: how to make private class member private
psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it.
Re: how to make private class member private
psychoticRabbit wrote: On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. just stop thinking in C/C++ "#include" terms. there, you have no other ways to restrict data access, so they were forced to make it broken, and then introduce "friends" just to workaround the fact that there are no modules in C++. instead, start thinking with modules in mind. module is THE unit of incapsulation. there is nothing wrong in isolating class or two in a module. then, to make imports manageable, either create a package of that, or just a dummy module that does `public import xxx;` for everything.
Re: Remember when make -f posix.mak just worked for dmd from zip?
Adam D. Ruppe wrote: compiler used to build the compiler... if i try to just build dmd from git i get `/home/me/d/dmd2/linux/bin32/../../src/druntime/import/core/exception.d(686): _store is thread local`) it is just a -vtls message, btw, absolutely harmless. i don't know why that reporting is turned on.
Re: Remember when make -f posix.mak just worked for dmd from zip?
Seb wrote: Out of interest: Why would you compile the compiler from the release sources? After all, it's the binary release bundle and not the development build. Also there are tools like digger that automate everything for you... I understand that sometimes it can be nice to do that, but imho you are making a big deal out of this, while it's not really one in practice as you can simply fetch the source from GitHub. Also there is no CI for the release builds and there's only one person who can build them (Martin) as it requires virtual machines for all supported OSes. Martin does an amazing job, but there's only so much one person can do... every sentence in this answer is perfect. and the whole thing perfectly illustrates the reasons for my hardfork.
Re: docs/definition: !object
Nick Sabalausky (Abscissa) wrote: (Or does return the address of the *reference* to the object rather than the address of the object?...You can see just how often I do OO in D ;) ) exactly. if you want to convert object to a pointer safely, do this: MyObject o; void* p = *cast(void**) this magic construct guarantees that you won't hit `opCast()` in `MyObject` (yes, somebody *can* write weird `opCast` for `void*`! ;-). doing just `` gives you the address of a variable (on a stack, or in a tls), which is, obviously, never `null`. ;-)
Re: docs/definition: !object
Nick Sabalausky (Abscissa) wrote: I'm having trouble finding the documentation for what exactly the unary "not" operator does when applied to a class/interface object. Does this documentation exist somewhere? I know at least part of it involves "is null", but I seem to remember hearing there was more to it than just that. https://dlang.org/spec/operatoroverloading.html#boolean_operators "Class references are converted to bool by checking to see if the class reference is null or not."
Re: why not use git rebase instead of git merge in dlang repos?
H. S. Teoh wrote: I've pestered Brad about it before, but the real trouble is the Mailman software. If you feel motivated enough, pestering the upstream Mailman authors about it might actually get us closer to fixing this problem, as it really isn't a problem on Brad's end either. It's not unfixable, it just requires a change to the Mailman software to process headers correctly. yeah, that is what i meant when i wrote "current arch". ;-)
Re: why not use git rebase instead of git merge in dlang repos?
Seb wrote: OT: I don't know what you are doing, but you seem to be the only one who always creates new threads when replying. I assume you use nntp? Maybe something wrong with your client? it was already discussed several times: this is the issue with mailing list processor: it cannot properly link replies. it is unfixable with the current nntp/mlist arch, though.
Re: issue with each specifically for x86
Matt Gamble wrote: Ok, this has been submitted as a bug. https://issues.dlang.org/show_bug.cgi?id=18573 thank you.
Re: issue with each specifically for x86
Matt Gamble wrote:
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
With `real` instead of `double` x86_64 is also affected.
Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I guess I'm
glad I found it and posted. The conversation has gone beyond my realm of
understanding. Has anyone tested on 2.079 like Ali wanted. I have not had
a chance to install. I was going to wait to post the bug till that was
tried.
sure, it is still there in git HEAD. it is not the bug that can be fixed
"accidentally". %-)
Re: issue with each specifically for x86
ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
With `real` instead of `double` x86_64 is also affected.
yeah. that is 'cause SSE cannot do math with 80-bit floats, and compiler
falls back to FPU in this case.
Re: issue with each specifically for x86
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result
is ignored. codegen should have this info at hand, i believe.
Nice catch! Is there a bug filed for this yet? If not, it should be.
btw, this is specific to `cast(void)`. if you'll remove the cast, or do
something like `cast(void)(pred(i)+42);`, the bug won't be there. so it
looks like it is not a codegen bug after all, but glue layer. the codegen
is correctly dropping the result without `cast(void)` (`fstp %st(0)` is
inserted in `main`), but cannot do that if return type information is stripped.
so it looks that glue layer should not strip return type info.
Re: issue with each specifically for x86
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result
is ignored. codegen should have this info at hand, i believe.
Nice catch! Is there a bug filed for this yet? If not, it should be.
it seems that no bug is filled yet. feel free to do so. ;-) or maybe OP
should better do it, dunno. definitely not me. ;-)
Re: issue with each specifically for x86
Steven Schveighoffer wrote:
it seems that the only difference between `void` and `double` lambda is one
asm instruction: `fldl (%edi)`. it is presend in `double` labmda, and
absent in `void` lambda.
it looks like ignoring `double` result causes FPU stack imbalance ('cause
compiler doesn't insert "FPU pop" instruction), and that affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result is
ignored. codegen should have this info at hand, i believe.
Re: Slow code, slow
Martin Tschierschke wrote: basically, compilation of a code without templates is FAST. 500+ KB of source almost without templates often compiles in less than a second (on not-so-bleeding-edge i3, not even i7). but throw templates in a mix, and BOOM! coffee and cigarettes. My negative experience was, when using ctRegex and normal regex. But it was no problem to separate the functions using regex in a lib and compile them separately. (app saving 3 seconds) you happened to hit another issue, yeah: slow CTFE enigne. that should be improved too. ;-)
Re: implicit construction operator
aliak wrote: On Monday, 26 February 2018 at 21:34:21 UTC, ketmar wrote: aliak wrote: And if that's also a no no, how about char -> int. Or int -> float? Is ok? no, it is not ok. it was a mistake. it is now too late to fix it, but we can avoid doing more of the same kind. Oops, yeah, ok, D char ... char -> int yeah mistake. int -> long even? can you see a difference between *charactes* and *integers*? i can.
Re: Slow code, slow
Martin Tschierschke wrote: On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote: On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote: H. S. Teoh wrote: On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote: [...] When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once? The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110 basically, compilation of a code without templates is FAST. 500+ KB of source almost without templates often compiles in less than a second (on not-so-bleeding-edge i3, not even i7). but throw templates in a mix, and BOOM! coffee and cigarettes.
Re: Slow code, slow
H. S. Teoh wrote: On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote: [...] but until that brave new world materializes, we have a smart/fast dilemma. alas. I'd like to contribute to the materialization of that brave new world. Rather than sit around and wait for it to happen. :-P i'd like to do it too, but dmd code to process templates knocks me out of my consciousness. alas.
Re: implicit construction operator
aliak wrote: It makes libraries *much* more intuitive and expressive (C++ just got it wrong by choosing the wrong default). If you allow library authors to opt in instead of opt out then it becomes a conscious decision for one. library authors can create overloads for various argument types. with `foo(T...) (T args)` it is possible to generate conversions with CTFE. so we *already* have such feature.
Re: implicit construction operator
aliak wrote: And if that's also a no no, how about char -> int. Or int -> float? Is ok? no, it is not ok. it was a mistake. it is now too late to fix it, but we can avoid doing more of the same kind.
Re: Aliasing member's members
Kayomn wrote:
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout { return entity.position; }
}
Which will give you most of what you want. Although if you want to take
the address of pos you have to use
auto addr = ();
Damn, was hoping to keep my structs as plain old data-structures. Thanks
for the info, guess I won't be doing this then.
write `pos` as free function then, and use UFCS. there is no real
difference. ;-)
Re: Slow code, slow
H. S. Teoh wrote: The problem is not the Phobos implementation. The problem is that the compiler's way of handling templates and CTFE needs to be improved. We seriously need to muster some manpower to help Stefan finish newCTFE, and then we need to take a serious look at improving the current implementation of templates. yeah, i'm not saying that phobos code is wrong. but being "not wrong" and being fast is not always the same. ;-) still, we can be either smart, or have fast compile times, but not both. T_T [...] I'll like to disagree. :-D There's got to be a way to do this that doesn't have to compromise either way. I mean, this is not like we're doing rocket science here, or solving an NP complete problem. It's a straightforward way of recognizing a particular code pattern and applying 1-to-1 mappings. The general case of completely arbitrary templates can still fallback to the current implementation. The point is to optimize for specific template usage patterns that are common and yields big speedups, but still leave the door open for weirder, but less common, template code. but until that brave new world materializes, we have a smart/fast dilemma. alas.
Re: implicit construction operator
WebFreak001 wrote: Now before you would have only been able to do this: --- Nullable!Foo a; foo(a, Nullable!int(5)); --- but now you should also be able to do: --- Nullable!Foo x = null; Nullable!Foo y = 5; foo(null, 5); please no. such unobvious type conversions goes out of control really fast. there is a reason why D doesn't have such thing, this is not an oversight, but a design decision.
Re: Slow code, slow
H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 08:38:39PM +0200, ketmar via Digitalmars-d wrote:
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow
depdencies on std.format.format which is instantiated. Which has
a ton of dependencies itself.
Aha! That explains it. Thanks, Stefan, for the accurate diagnosis. :-)
Now the next problem is: how to trim the fat off std.format ...
p.s.: and ditch type safety. 'cause `foo(T...) (T args)` is a major
slowdown -- it is a template. ;-)
Actually, I think this is the classic example of why the compiler should
improve the way it implements templates.
In my mind, even C's printf API is sucky, because it involves runtime
parsing of what's usually a static string, over and over again. What we
*really* want is for something like:
writeln("blah %d bluh %s", i, s);
to be translated into something like:
stdout.putString("blah ");
stdout.putInt(i);
stdout.putString(" bluh ");
stdout.putString(s);
I.e., there should not be Yet Another Template with Yet Another
Ridiculously Long Argument List Type Encoded In The Mangled Name, along
with needless marshalling of function arguments on the stack, branching
to some other part of the code (potentially causing an instruction cache
miss), tons of copy-pasta for calling the same old functions for
outputting strings and formatting integers, and incurring Yet Another
Branch Hazard when the function finally returns.
And there should definitely be no silly runtime parsing of format
strings and all of that useless dance.
i once wrote such thing (for fun, using "Functional Programming With
Templates"). it was fun to do, and freakin' slow due to template bloat. ;-)
but yes, it generates a string mixin, and in runtime there was no format
string parsing.
still, we can be either smart, or have fast compile times, but not both. T_T
p.s.: oops. just found that i cannot pass structs with dtors to `(...)`
functions. not fun at all.
Re: Slow code, slow
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow depdencies
on std.format.format which is instantiated.
Which has a ton of dependencies itself.
Aha! That explains it. Thanks, Stefan, for the accurate diagnosis. :-)
Now the next problem is: how to trim the fat off std.format ...
p.p.s.: or replace it with `void fmtlite (...) {}` thingy. this way we can
still have type safety, but get rid of templates.
Re: Slow code, slow
H. S. Teoh wrote: On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d wrote: [...] This particular slowdown happens because there are somehow depdencies on std.format.format which is instantiated. Which has a ton of dependencies itself. Aha! That explains it. Thanks, Stefan, for the accurate diagnosis. :-) Now the next problem is: how to trim the fat off std.format ... no wai. it is just Too General to be slim. what can be done, though, is `std.format.lite` module (or something), that supports only a very small subset of "big format" features, like simply printing numbers, arrays, and unconditionally calling `.toString` on structs/classes, and a very restricted set of formatting options. that should cover alot of use cases. 'cause most of the time people only need something like `%3d %s` and such.
Re: Slow code, slow
H. S. Teoh wrote: On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d wrote: [...] This particular slowdown happens because there are somehow depdencies on std.format.format which is instantiated. Which has a ton of dependencies itself. Aha! That explains it. Thanks, Stefan, for the accurate diagnosis. :-) Now the next problem is: how to trim the fat off std.format ... p.s.: and ditch type safety. 'cause `foo(T...) (T args)` is a major slowdown -- it is a template. ;-)
Re: Translating C "static arrays" into D?
H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 08:07:11PM +0200, ketmar via Digitalmars-d wrote:
[...]
in C, arrays are *always* decaying to pointers. so
void foo (int x[2])
is the same as
void foo (int* x)
`[2]` is purely informational.
that is, in D it will be:
alias mytype = double*;
Actually, that doesn't work, because in the struct declaration it will
be wrong:
// C
struct S {
double[5] x; // actually occupies the space of 5 doubles
}
// D
struct S {
double* x; // occupies the space of 1 pointer (wrong)
}
yeah, sorry. somehow i completely missed structs.
Re: Translating C "static arrays" into D?
H. S. Teoh wrote:
What's the correct translation of the following C declarations into D?
typedef double[1] mytype;
void someFunc(mytype x, mytype *y, mytype **z);
struct SomeStruct {
mytype x;
mytype *y;
mytype **z;
}
I need this to interface with an external C library. Currently, I just
wrapped the above as-is inside an extern(C) block. But I suspect it may
be wrong, because:
1) In C, declaring a function parameter of type double[1] is, IIRC, the
same thing as declaring it as double*. But in D, double[1] passes one
double by value as a static array. So there may be an API mismatch here.
2) In C, declaring a *variable* or struct field as double[1] has
essentially the same semantics as D's static arrrays. Meaning that I
cannot just change the declaration of mytype in order to get the correct
behaviour of function parameters.
3) I'm getting a segfault at runtime of some C++ code into D, that calls
the library via this C API, and I suspect it's probably due to (1).
T
in C, arrays are *always* decaying to pointers. so
void foo (int x[2])
is the same as
void foo (int* x)
`[2]` is purely informational.
that is, in D it will be:
alias mytype = double*;
Re: Forward references
works for me with 2.076.
Re: Destructor called twice.
add postblit debug prints, and you will see.
Re: Function overloading between modules
JN wrote: same idea? absolutely the same. non-qualified imports (be it template, or function) won't take part in overload resoultion.
Re: Function overloading between modules
JN wrote:
Is this expected behaviour?
bar.d
---
void foo(string s)
{
}
app.d
---
import std.stdio;
import bar;
void foo(int x)
{
}
void main()
{
foo("hi");
};
===
Error: function app.foo (int x) is not callable using argument types
(string)
yes. this is done so unqualified won't silently "steal" your functions.
this can cause some unexpected (and hard to find) bugs.
if you want it to work, you can either do qualified import
import bar : foo;
or manuall bring overloads from `bar` with
alias foo = bar.foo;
Re: Tuts/Aritcles: Incrementasl C++-to-D conversion?
Nick Sabalausky (Abscissa) wrote: Are there any tutorials or articles out there for "getting started with converting a C++ codebase to D one module at a time?" Or at the very least: tips, tricks, lessions learned, from those who have come before. from my experience (various codebases up to middle size, mostly C, some C++): fsck the "one module at a time" idea! even in D modules are interwined, and in C and C++ they're even more so. besides, converting tests is tedious, it is much funnier to have something working. so, i'm usually converting alot of code, up to the whole codebase. it is not fun when compler spits 100500 errors, but when it finally stops... oh, joy! trick: use 'sed' (or your favorite regexp search-and-replace tool) alot. basically, before HDD crash i almost had a set of scripts that does 80-90 percents of work translating C to D with sed. ;-) then use editor with "jump to error line" support, and simply compile your code, fixing errors one by one. tip: try to not rewrite code in any way until it works. i know how tempting it to replace "just this tiny thing, it is so ugly, and in D we have a nice idiom!" NEVAR. this is by far the most important thing to remember (at least for me), so i'll repeat it again: no code modifications until it works! personal memories: C code often using things like `a == [idx]`, where idx can go just past the last array element. it got me when i was doing enet conversion. nasty trick. otherwise, sweat and blood, and patience.
Re: Destructing Struct
Jiyan wrote:
Hi :),
What i thought was that when i create a struct dynamically i can just
deconstruct it with __dtor lets say:
struct U {...}
struct S {... private U _member;}
S* p;
p = cast(S*)malloc(S.sizeof);
// just run that if it compiles, for simplicity
// we dont use __traits(compiles, ...)
p.__dtor;
The thing here is that this doesn't work because of when S has an element
that that is private and has a __dtor itself, the __dtor from U doesnt
get called before the call of __dtor from S - or after.
Is there any way with traits or sth to do that?
Are delete, destroy or any other functions the standard library working
here?
I would prefer a solution that can be build by myself - so without the
standard library for example with traits.
Thanks :)
`p.destroy` will call the dtors for you. you'd better not use `__`-frefixed
symbols yourself, as they aren't actually a part of a language, they're just
implementation details.
Re: C++ std::string_view equivalent in D?
0x wrote:
On Wednesday, 21 February 2018 at 09:21:58 UTC, 0x wrote:
What is the equivalent of C++17 std::string_view (an object that can
refer to a constant contiguous sequence of char-like objects with the
first element of the sequence at position zero) in D?
PS: I'm getting back to D after years (since DMD 1 days). A lot changes
since v1.0.
Wow! Thanks guys.
Those are handy, but I specifically want to do something like:
```
string_view sv = "some string";
```
So I can query it's size, make it point to sth else, use it in callbacks
etc. Of course I'm aware of scoping etc...
I'm NOT doing any dynamic allocations, I just want a situation where a
string allocation string would be a little bit expensive.
and that is exactly what slices are for! ;-)
you are probably better to use `const(char)[]`, tho. like this:
// don't store `s`, as it's contents may change after exiting of
`myfunc`
// (this is what `const` implies here)
void myfunc (const(char)[] s) { ... }
...
string s = "test string";
myfunc(s); // yep, this works
s = s[2..4]; // this doesn't allocate
myfunc(s);
myfunc(s[3..6]); // or this, it doesn't allocate
myfunc("abc"); // or this, doesn't allocate
you got the idea.
Re: Annotation of functions
psychoticRabbit wrote: On Tuesday, 20 February 2018 at 12:18:47 UTC, rikki cattermole wrote: So the point is moot. ok. I've come around... and the point reall is moot. so.. in that case..another idea...how about a compiler option to output a list of functions. (I don't really expect many will warm to that idea.) Does anyone know of any tool that could do such a thing? dmd. dmd -X will output alot of interesting info.
Re: How to make AA key a pointer
Clinton wrote:
On Monday, 19 February 2018 at 14:55:01 UTC, Clinton wrote:
Hi all, I need advice from better developers on this concern.
I'm using an AA to reference another array for quicker access:
[...]
Sorry, on second look my explanation isn't very clear. I want to know if:
bool[string] myAA;
myAA[contact.id] = true; // Does this copy contact.id or is this a
pointer to contact.id?
there is absolutely no reason to copy `string` ever, as it is `immutable`.
and compiler knows that. anyway, why don't you just check it by writing the
code first?
import std.stdio;
void main () {
int[string] a;
string s = "test";
writefln("%08x", s.ptr);
a[s] = 666;
s = "test1";
writefln("%08x", s.ptr);
a[s] = 42;
foreach (string k; a.byKey) writefln("%08x", k.ptr);
}
Re: ubyte[4] to int
Nicholas Wilson wrote: On Thursday, 15 February 2018 at 16:51:05 UTC, Kyle wrote: Hi. Is there a convenient way to convert a ubyte[4] into a signed int? I'm having trouble handling the static arrays returned by std.bitmanip.nativeToLittleEndian. Is there some magic sauce to make the static arrays into input ranges or something? As a side note, I'm used to using D on Linux and DMD's error messages on Windows are comparably terrible. Thanks! you mean you want to convert the bitpattern represented by the uint[4] to an int? You want a reinterpret style case ubyte[4] foo = ...; int baz = *cast(int*) better to use `[0]`, this way it will work with slices too.
Re: The Expressive C++17 Coding Challenge in D
Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D. a typo: writefln!"%d"(foo"); it should be `"foo"`, i guess. ;-) great article. now i want to learn D again, it looks so beautiful and powerful! ;-)
Re: import strangeness with std.stdio.write
psychoticRabbit wrote:
Also, if I do this below, how does the compiler choose the correct write
function?
import std.stdio;
import std.file;
void main()
{
write("hello");
writeln("hello again");
}
it's easy: just take a look at `std.file.write()`. first, it require two
arguments. this is enough to rule `stf.file.write()` out in your case.
Re: import strangeness with std.stdio.write
psychoticRabbit wrote:
So, strange problem below.
The commented-out line will not compile (if I un-comment it), unless I
either move std.stdio into main, or, move std.file out of main.
Whereas writeln works just fine as is.
-
module test;
import std.stdio;
void main()
{
import std.file;
//write("hello");
writeln("hello again");
}
---
`std.file` has function named `write()` too. and local import completely
shadows global imports (i.e. it removes global imports from overload set
for the given scope), hence `std.stdio.write()` is not available there.
this is done by purpose, so your code won't accidentally use wrong
function. you can bring `std.stdio` functions back by adding local `import
std.stdio;`, for example.
Re: Old but interesting link as to the low adoption reason for D
welkam wrote: On Monday, 12 February 2018 at 22:10:49 UTC, Bo wrote: * Lack of default OFFICIAL libraries like HTTP(s), database access, ... Why there should be one default OFFICIAL library for anything? because Business Developers wants it that way. they are... well... Doing Business, and they wants someone to maintain all the libraries they are using. for free, of course. and what can be better than to offload this burden to language developers? almost each time we hear about "D should have XXX in standard library", it comes either from Business Developer, or from Business Developer in Disguise. 'cause they always want someone to work for 'em for free.
Re: Old but interesting link as to the low adoption reason for D
Bo wrote: This is part of the issues that D faces. Especially that last sentence... "bring a significant benefit". tbh, the only *real* problem with D that i see is people who thinks that D (and D devs) should do everything to please "business developers". 'cause, you know, there is no sense in language if it is not used by Holy Business. of course, i've never seen the same attitude from the business side (there are some opposite examples, of course, but i'm talking about a big picture). i absolutely cannot see how pleasing yet another business dev will suddenly do alot of good for D. but i surely see how pleasing business devs will do bad. even trying to please reddit crowd already did alot of damage (@nogc).
Re: inout question
lobo wrote: sure, i meant that you have to modify the second parameter accordingly. ;-) anyway, it's good that you fixed it.
Re: inout question
Norm wrote:
Hi,
I'm new to D so can someone explain to me what is happening here?
void func(const char* s, char** e) {
import core.stdc.stdlib;
auto result = strtod(s, e);
}
Error: function core.stdc.stdlib.strtod (scope inout(char)* nptr, scope
inout(char)** endptr) is not callable using argument types (const(char*),
char**)
there is a difference between `const char* s`, and `const(char)* s`.
the former means that both `s` and `*s` cannot change, the latter means
that `s` can be changed, but `*s` cannot. i.e. the first form means that
you cannot do pointer arithmetic with `s`, while with second form you can
(only *contents* are const, not the pointer itself).
that is, `strtod` wants const *contents*, but not pointer. `const(char)* s`.
Re: #dbugfix Issue 16189
Bastiaan Veelo wrote: On Wednesday, 7 February 2018 at 11:37:19 UTC, Michael wrote: Does it work with slightly varied examples like where a = -1, and is incremented etc.? I played with it here https://run.dlang.io/is/15sr6c and every variation I tried worked (correctly). So the example seems to be pretty minimal. Maybe someone understanding assembly is able to see what is going on after pressing that nice [ASM] button? there is a mix of loop strength reduction and data flow analysis. as inner loop contains array access and bounds checking, optimizer decided to turn `a` into actual index (i.e. multiply it by 16), and use subtraction in loop body. so far so good, optimizer did a good job. but then we have `assert(a == -1);` after the loop. and that is where things goes off the road: optimizer knows that it has `a` in register, and it knows that `a` was pre-multiplied, so it decided to divide `a` to 16 to get the real value. but... it does this with `shr` instruction instead of `sar`! most of the time it works as expected, but in our case... oops, we lost a sign. the fix should be fairly easy, but sorry, i can't get any sense from dmd backend. i see what it wrong due to my expirience with similar things, but that's all. here Walter (or some other backand guru) should step in.
Re: -transition=safe and DIP1000
Mike Franklin wrote: And what does "NB" mean? "nota bene". used as "pay attention to the following".
Re: __traits(documentation, X)
Steven Schveighoffer wrote: I shudder at the thought of compiled code being affected by documentation. I don't like it, sorry. it's not really different from `version(DDoc)`, or string mixins, or UDAs. i can put documentation in UDA, and process code differently when UDA changes. yes, UDA is not a comment -- but it doesn't affect code generation directly too. there is just no way to stop people from writing abominations once we got metaprogramming. and adding artificial limitations on that just makes people more inventive, but won't stop infestation. ;-)
Re: Maybe D is right about GC after all !
Russel Winder wrote: I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it. sorry, but it is not zero cost. we have alot of C and C++ code. converting it to Rust is not zero cost at all. and using it as-is won't make our codebases any better. but with D, i can say that converting C code is almost zero cost. i did alot of C->D ports, and most of the work was done with "sed". then i have to run dmd and add some casts and other simple things (sure, i should finally write an automatic converter, but... you know that "ok, next time" kind of self-promises ;-). i also ported some C++ codebases, and it is almost equally easy. mostly due to the fact that people tend to avoid "modern" C++ features and metaprogramming: it is still hard to use with C++. (with D, btw, i started to use templates even before i fully realised that i am using templates ;-) what i want to say (and didn't, as usual) is that Rust is not zero cost due to exisiting codebases. either you have to invest alot of time and efforts to port those codebases, or you have to use both Rust and C/C++, and suffer the consequences. and with D, you can port all your code, and use one language, investing *much* less efforts than you'd have with Rust/Go. plus, you'll get all the things D has to offer, for free. that is, D actually has *no* competitors. if not google and mozco, people won't even start talking seriously about Go/Rust. yet even in this unfair race, D presence is constantly growing. just wait a little, and you'll see a dawn of Rust and Go. and D will be still there, standing strong and proud. ;-)
Re: Maybe D is right about GC after all !
bpr wrote: It seems that there's an effort from the top to bring more higher level features into --betterC. I agree with you that more should be there, that it should really be betterC++ and strive for feature parity with modern C++. we already have better c++: it is titled "D".
Re: why ushort alias casted to int?
crimaniak wrote: Both operands are the same type, so as I understand casting to longest type is not needed at all, and longest type here is ushort in any case. What am I doing wrong? it is hidden in specs: all types shorter than int are promoted to int before doing any math.
Re: D's Newfangled Name Mangling
Andrej Mitrovic wrote: ah, 'cmon, we can hash the whole source file! let's move build system's work to linker! ;-) sorry, but this is really overkill. tracking changed files and rebuilding 'em on demand is something your build system should do.
Re: Some thoughts about C and D, return data through parameters
Steven Schveighoffer wrote:
I insist that auto is a storage qualifier
what is the rationale to have `auto` as storage qualifier? except of
keeping it in line with the ancient C feature (and most C programmers don't
even know what `auto` does in C).
i bet that most people are sure that `auto` in D is a type placeholder. it
works like type placeholder, it looks like type placeholder, why don't make
it a type placeholder?
ok, i can see *one* place where it won't be consistent: `foo (auto ref
Type v)`. which can be left as a logical exception ('cmon, `enum a = 20;`)
is not declaring an enum too, it is used to declare "inline constant".
also:
auto int n = 42;
yay: "Error: variable n storage class 'auto' has no effect if type is not inferred,
did you mean 'scope'?"
even D compiler knows that `auto` is used as *type* *placeholder*. 'cmon,
let's promote it to actual type placeholder!
Re: Maybe D is right about GC after all !
rikki cattermole wrote: On 19/12/2017 11:30 AM, ketmar wrote: rikki cattermole wrote: On 19/12/2017 9:54 AM, Walter Bright wrote: "C, Python, Go, and the Generalized Greenspun Law" http://esr.ibiblio.org/?p=7804 I must agree, GC is a wonderful fallback. Although I do wish we had better scope+RC support. but Rikki, we have this! i'm using refcounted structs for years, and it works like a charm! ;-) And that is why I said better! you can't have better than working! ;-)
Re: Maybe D is right about GC after all !
rikki cattermole wrote: On 19/12/2017 9:54 AM, Walter Bright wrote: "C, Python, Go, and the Generalized Greenspun Law" http://esr.ibiblio.org/?p=7804 I must agree, GC is a wonderful fallback. Although I do wish we had better scope+RC support. but Rikki, we have this! i'm using refcounted structs for years, and it works like a charm! ;-)
Re: Some thoughts about C and D, return data through parameters
cosinus wrote:
So my question is would it be a good idea to have some kind of implicit
declarations of variables that are used as parameters:
```D
int add(decl ref int c, int a, int b);
// ...
// c is unknown here
if(add(c, 123, 456)) {
writeln("error!");
}
// c is implicit declared at the function-call above.
assert(c == 579);
```
D already has one such construct, `foreach`. and it is a huge misdesign. it
is *absolutely* not clear from the code that `c` is introduced by a
function call. exactly like with `foreach (c; ...)`, any sane person
expects that just using variable name without any type prepended means
"let's use already declared variable `c`". the ONLY place where this
uniformity is broken now is `foreach`, and this is already bad.
note that D devs stubbornly insists that `auto` is not a type placeholder,
but a storage qualifier, like `static`, so you can't write `foreach (auto
c; ...)` (and compiler rejects such code). yet, `if (auto c = ...)` is
perfectly allowed, and here `auto` is type placeholder. talking about
consistency, yeah.
anyway, adding yet another broken promise (aka illogical inconsistency)
into language won't do any good. each inconsistency makes code harder to
read and understand.
Re: A list of all the awesome people who made D possible
great. yet i think that the page should note that people are listed in alphabetical order, not in any "importance" order.
Re: Scope failure is not preventing application crush in case of uncaught exceptions
kerdemdemir wrote:
On Saturday, 16 December 2017 at 20:56:26 UTC, ketmar wrote:
kerdemdemir wrote:
As far as I know scope(failure) should be collecting all failure cases.
nope. `failure` scope won't stop exception propagation, it is just
called before exception leaves your function, to give you a last chance
to do some immediate cleanup.
Than do I still need to catch'em all? For me it doesn't matter the which
exception it is. It is more important for me to not pollute my code with
so many exception related lines. What is the most compact way for me to
catch'em all?
see collectException[0], for example. something like (WARNING! DON'T DO
THIS! it's not wise to silence everything! try to be selective with
`collectException!RequiredExceptionType` instead!)
collectException(() {
your code here
}());
or just move your code to some function, and do
collectException(myfunction);
[0] http://dpldocs.info/experimental-docs/std.exception.collectException.2.html
Re: Scope failure is not preventing application crush in case of uncaught exceptions
kerdemdemir wrote: As far as I know scope(failure) should be collecting all failure cases. nope. `failure` scope won't stop exception propagation, it is just called before exception leaves your function, to give you a last chance to do some immediate cleanup.
Re: remake of remake of Konami's Knightmare
Taylor Hillegeist wrote: On Monday, 11 December 2017 at 19:34:56 UTC, ketmar wrote: major update: entity logic is completely driven by external ... you're welcome to study MES compiler implementation if you like. it is contained in one file (mesengine.d), and is not that hard to follow. I hope you didn't write that all in one sitting, I thought it was going to be a bit shorter. i am not even finished! actually, here[0] is the main repository for MES developement. you can track my progress there, starting from the very first commit. it doesn't meant to be public, tho, hence it is marked "OBSOLETE". [0] http://repo.or.cz/mes.d.git
