Re: Rather D1 then D2
On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler wrote: On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote: On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler wrote: On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote: On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan Marler wrote: On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote: Then D isn't the right choice for you. I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax. I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal. That inconsistency is an issue for me. I wish there a clear decision to make things consistent. Yeah there's been alot of discussion around it over the years, which is why I put this together about 4 years ago: https://wiki.dlang.org/Language_Designs_Explained#Function_attributes Gosh I've forgotten how long I've been using D. Interesting article. "int safe = 0; // This code would break if "safe" was added as a keyword" My question here: why didn't D use a similar solution as C when dealing with these things? Look at the introduction of the bool datatype in C99. They created the compiler reserved type "_Bool" and put "typedef _Bool bool" in "stdbool.h". The people wanting to use this new feature can include this header, and other can leave it be. No ugly "@" polluting the language on every line where it's used. Wouldn't a similar solution have been possible in D? That works for types but wouldn't work for keywords. Keywords have special meaning in the lexical stage and you can't extend/change the grammar of the language via an alias or typedef. You could do something like this with a preprocessor but then you run into all sorts of other problems (i.e. #define safe @safe). If you come up with other ideas then feel free to share. No one likes the current state but no one has come up with a good solution yet. Yes, of course you are right. A typedef for this problem wouldn't be good enough. But there are plenty of other solutions to encapsulate the ugliness in one area instead of spreading it to every codeline. What about a compiler switch like the one in gcc? "-std=c11"? until making the change to default? There is an excellent speech from Scott Meyers about this. I loved his books about C++, and his recommendations for D are just as good. 41:00 into the video he mentions the legacy crud of C++ and the accidental complexity it contains. He advises D to avoid the need of having "explainers" like him in the future, and to use the small legacy codebase in D to remove/avoid such accidental complexity. https://www.youtube.com/watch?v=KAWA1DuvCnQ I don't think enough people listened to him.
Re: Rather D1 then D2
On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler wrote: On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote: On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan Marler wrote: On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote: Then D isn't the right choice for you. I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax. I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal. That inconsistency is an issue for me. I wish there a clear decision to make things consistent. Yeah there's been alot of discussion around it over the years, which is why I put this together about 4 years ago: https://wiki.dlang.org/Language_Designs_Explained#Function_attributes Gosh I've forgotten how long I've been using D. Interesting article. "int safe = 0; // This code would break if "safe" was added as a keyword" My question here: why didn't D use a similar solution as C when dealing with these things? Look at the introduction of the bool datatype in C99. They created the compiler reserved type "_Bool" and put "typedef _Bool bool" in "stdbool.h". The people wanting to use this new feature can include this header, and other can leave it be. No ugly "@" polluting the language on every line where it's used. Wouldn't a similar solution have been possible in D?
Re: Why not flag away the mistakes of the past?
On Thursday, 8 March 2018 at 17:35:11 UTC, H. S. Teoh wrote: On Thu, Mar 08, 2018 at 10:14:16AM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] [...] [...] [...] Yeah, the only reason autodecoding survived in the beginning was because Andrei (wrongly) thought that a Unicode code point was equivalent to a grapheme. If that had been the case, the cost associated with auto-decoding may have been justifiable. Unfortunately, that is not the case, which greatly diminishes most of the advantages that autodecoding was meant to have. So it ended up being something that incurred a significant performance hit, yet did not offer the advantages it was supposed to. To fully live up to Andrei's original vision, it would have to include grapheme segmentation as well. Unfortunately, graphemes are of arbitrary length and cannot in general fit in a single dchar (or any fixed-size type), and grapheme segmentation is extremely costly to compute, so doing it by default would kill D's string manipulation performance. [...] Which companies are against changing this? They must be powerful indeed if their convenience is important enough to protect so destructive features. Even C++ managed to give up trigraphs against the will of IBM. Surely D can give up something that is even more destructive?
Re: Vtable for virtual functions in D
On Wednesday, 7 March 2018 at 22:02:17 UTC, sarn wrote:
On Wednesday, 7 March 2018 at 12:49:40 UTC, Guillaume Piolat
wrote:
If you know enough D maybe you can implement your own virtual
functions on top of D structs. It seems no one has made it yet.
When I wrote Xanthe a year ago, I rolled my own classes using
alias this and explicit vtables:
https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15
(I did this because normal D classes use the druntime library,
and Xanthe was an experiment in not using the D runtime at all.)
Henrik: you might be interested in this post I wrote about
making that:
https://theartofmachinery.com/2017/02/28/bare_metal_d.html
NB: things are moving fast and some things have already
improved since then.
This is great, it is exactly what I was hoping for! The
core.sys.posix is also pure gold. I'm obviously not the first
person here to have an interest in this topic. Really pleasant
reading!
In my view; the evolution of programming languages skipped at
step after C, and forced many of us to go directly to Java, C#
and similar languages. If D could form an natural next step after
C, with a favorable tradeoff between memory safety and
performance, it could really change the embedded software
industry. C11 + Valgrind/AdressSanitizer etc are great to develop
fast reliable software, and most universities here in Europe -
from my experience at least - are teaching C, but not as much
C++. I like C, but it really only dominates because everyone else
performs so poorly in embedded/system environments.
I should probably move to the learn category for the next part,
but I can post one example at least. It is my first naive step of
creating a RAII struct dummy, and check my program for memory
corruptions; two things that C cannot do. It all works good, but
why do I have to put the @nogc on the constructor and destructor
separately?
import std.stdio;
import core.exception;
@nogc:
struct Nice
{
int a;
this(int a) @nogc
{
this.a = a;
puts("A");
}
~this() @nogc
{
puts("B");
}
}
void TestStruct()
{
//char *c = new char();
Nice n = Nice(55);
}
void TestIndexOutOfBounds(int i)
{
int a[100] = void;
a[0] = a[i];
}
void main(string[ ] args)
{
try {
TestStruct();
TestIndexOutOfBounds(100);
} catch(core.exception.RangeError e) {
puts("Sloppy work! Enter safety mode!");
}
}
Re: Vtable for virtual functions in D
Hi everyone, thank you all for your great answers. I'm playing around with @nogc right now, and it looks really promising. Strings and static arrays all seem to be located on the stack, which is so much better compared to std::string and std::vector in C++. The double indirection for virtual functions bother me, and it isn't getting better with all methods being virtual by default - I guess I'll be writing the keyword "final" very intensively in all my programs. I would also gladly pay some bytes in pointer bloat to have my virtual functions speed up. Strange that D kept the vtable approach when breaking with C++. I know that D concentrated much on C++ compatibility a while ago. Are there any plans to support the direct inclusion on C header files? Many important libraries like ICU have C interfaces even when written in C++. The direct support of C headers would be very convenient in migrating parts of C/C++ projects to D. It would also open up POSIX which is used extensively in our work. This looks great: https://github.com/D-Programming-Deimos/ but it must be tedious to keep such files up to date. Despite the point where I'm complaining, I must say that D looks very impressive. Beautiful syntax, large standard library, and standardized inline assembler (Thank you!). I'll definitely try to find a suitable project to try out D under serious conditions.
Vtable for virtual functions in D
Does anyone know if D is using the vtable implementation for virtual functions just like most C++ compilers? If yes, can someone explain the advantages of this strategy? A function pointer in C is regarded as expensive because of missing inlining, but a double indirection through a vtable just looks insane - if there aren't really good reasons for such an implementation. Does it make class inheritance or class polymorphism much simpler to implement or what is the reason? I have worked with C in embedded systems for many years now, and for our modern Linux systems we are using a combination of C and Java today. Java for parts where memory safety is more important than speed/determinism, and C for the critical real time parts. There should exist a language between these worlds, where we can achieve memory safety at relatively small costs. C++ is not really an alternative, and D looks much more pleasant for us C programmers than for example Rust.
