Not again, not another D thread noooooooooooooooooo (i'm joking)
All your base belong to D!
Obvious things C should do
51–60 of 310 posts
Re: Obvious things C should do
#52[stub for offtopicness]
I didn't know X put articles behind a paywall? I haven't tried putting articles there before. Anyhow, here's the same article: https://www.digitalmars.com/articles/Cobvious.html Fun fact: X's article formatter recognizes D code!
Haven't you noticed that the homepage does not include the X widget anymore ? It's been removed [1] exactly because of that, i.e the content is not public anymore.
Re: Obvious things C should do
#53> Evaluating Constant Expressions The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. Which is probably assumed "too complex" to go into the standard. I'm not saying it's impossible, but I kind of understand why this would not go into any kind of standard. > Imp…
> I kind of understand why this would not go into any kind of standard.
Other popular languages can do it. That aside, it is an immensely popular and useful feature in D.
And yes, as one would expect, the more it is used, there's compile time speed and memory consumption required. As for a VM, the constant folder is already a VM. This just extends it to be able to handle function calls. C has simple semantics, so it's not that bad.
> Additionally
Great minds think alike! Your suggestions are just what D imports do. https://dlang.org/spec/module.html#import-declaration
> In this specific case I don't know if I'm importing dex.d or dex.c
This issue does come up. The answer is setting up your import path. It's analogous to the C compiler include path.
Re: Obvious things C should do
#54Earlier quoted context omitted.
Interesting you brought that up. I implemented them for Symantec C and C++ back in the 90s. I never want to do that again! They are brittle and a maintenance nightmare. They did speed up compilations, though, but did not provide any semantic advantage. With D I focused on fast compilation so much that precompiled headers didn't offer enough speedup to make them worth the agony.
>They are brittle and a maintenance nightmare I happened to be reading DMC source this week, those hydrate/dehydrate stuff really is everywhere (which I assume is solely used for precompiled headers?)
Yup. I spent a crazy amount of time debugging that. The tiniest mistake was a big problem to find.
Re: Obvious things C should do
#55While the author has WAY more knowledge/experience than me on this and so I wonder how he would solve the following issues: Evaluating Constant Expressions - This seems really complicated...if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. Compile Time Unit Tests - This is alrea…
Every other language does seems to not require header file/forward declarations. I don't understand the backlash against that. Are modern C compilers actually still single pass?
> Are modern C compilers actually still single pass?
All except ImportC, which effortlessly handles forward references. (Mainly because ImportC hijacks the D front end to do the semantics.)
Re: Obvious things C should do
#56[stub for offtopicness]
Sorry to be off-topic, but I'm disappointed in this being on X, it even comes with an ad built-in. We should be doing better. Spinning up a single-site blog is easier than ever for technically-minded folks - the internet needs to become independent again.
I posted it originally on digitalmars.com, and nobody noticed it. I posted it today on X, and bang! I didn't even submit it to HackerNews.
I'll be using X more for articles in the future, but will also put them on the dlang.org and digitalmars.com sites.
Re: Obvious things C should do
#57Earlier quoted context omitted.
> if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. You are correct in that the source code to the function being evaluated must be available to the compiler. This can be done with #include. I do it in D with importing the modules with the needed code. > This is already somewhat…
Thanks for taking the time to respond! I have a few followup questions if thats ok: > You are correct in that the source code to the function being evaluated must be available to the compiler. This can be done with #include. I do it in D with importing the modules with the needed code. > D's strategy is to separate the parse from the semantic analysis. I suppose it is a hair slower, but it also doesn't have to recomp…
> Is a translation unit the same as in C, but since you're #including the file you would expect multiple compilations of a re-included C file? woudnt this bloat the resulting executable (/ bundle in case of a library)
I think the idea is that compiling a translation unit produces two outputs, the object code (as it currently does), and an intermediate representation of the exported declarations, that could be basically a generated .h file, but it would probably be more efficient to use a different format. Then dependent translation units use those declaration files.
With this, you can still compile in parallel. You are constrained by the order of dependencies, but that is already kind of the case.
One complication is that ideally, if the signature doesn't change, but the implementation does, you don't need to re-compile dependent translation units. This is trivial if your build system detects changes based on content (like, say, bazel), but if it uses timestamps (like make) then the compiler needs to ensure the timestamp isn't updated when the declarations don't change.
But this really isn't a new concept. Basically every modern compiled language works fine without needing separate header files.
Re: Obvious things C should do
#58Yeah... no. Constexpr function evaluation sounds like a great idea until you start trying to use it, and get surprised when seemingly-constexpr-safe functions aren't constexpr. Or, you tweak one function and suddenly all your fancy compile-time unit tests explode. Ok, so you get around that with good code hygiene and by limiting the complexity of your constexpr functions... in other words, do the exact things we alre…
Just like constant expressions, a function run at compile time needs to be pure, which means no globals, no system calls, no I/O, no undefined behavior. Yes, that does constrain it somewhat, but D users have found it to be immensely useful anyway.
There's really no comparison with preprocessor macros. All the preprocessor can do is trivial expressions with long values. Not even floating point.
> you add a constexpr keyword to the lang, but now we have red functions and blue functions
My proposal (and D) does not require constexpr. The same function can be used at run or compile time. There is no need for that keyword. C++ made a mistake.
Re: Obvious things C should do
#59[stub for offtopicness]
Sorry to be off-topic, but I'm disappointed in this being on X, it even comes with an ad built-in. We should be doing better. Spinning up a single-site blog is easier than ever for technically-minded folks - the internet needs to become independent again.
It's also hosted here: https://www.digitalmars.com/articles/Cobvious.html
Re: Obvious things C should do
#60[stub for offtopicness]
Perhaps I could load the Javascript and also "login to X", but I'll instead forego reading this and pay attention to what others are writing about C.
It's also hosted here: https://www.digitalmars.com/articles/Cobvious.html