i think compile time evaluation should be extended: if it can get a pass over the source code then this could replace preprocessor macros with something less shitty.
Obvious things C should do
201–210 of 310 posts
Re: Obvious things C should do
#202Earlier quoted context omitted.
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…
> I dont have the power to make large decisions on an existing codebase like "lets switch languages" We struggled with that for a long time with D. And finally found a solution. D can compile Standard C source files and make all the C declarations available to the D code. When I proposed it, there was a lot of skepticism that this could ever work. But when it was implemented and debugged, it's been a huge win for D.…
I know that in other languages, one obstacle for "just compile the C files" is that the target language might not have pointers and thus have difficulty representing things such as return-by-pointer.
I suppose in D this was less of an issue because D has pointers?
Re: Obvious things C should do
#203Compile time unit tests are as bad of an idea as "unused import/variable/result" errors (rather than warnings). They're "nanny features" that take control away from the developer and inevitably cause you to jump through bureaucratic hoops just to get your work done. These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds (which a…
[deleted]
Re: Obvious things C should do
#204Earlier quoted context omitted.
Why is it odd? The compiler does all sorts of other checks based on things like static assert or type information.
It's odd because you lose control over that aspect of compilation. It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Every time you do exploratory work you now have to comment out all the tests that this work breaks because otherwise it won't compile anymore. That would be even more annoying than Go's stupidly pedantic compil…
> It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet.
Can't that be an optional thing decided by some compiler flag? I think I remember doing something like that in D.
Re: Obvious things C should do
#205If you want to write D, write D. C is fine without these things
I want to write d, but I have a ton of c - d makes it easy. rust is harder as I have to write ffi. d makes working with something else easy shich it an advantage. Too bad it never took off.
> Too bad it never took off.
It may not be very hyped but the forum and community is quite active. I don't think it's popularity should stop you from exploring it, it's a fascinating language.
Re: Obvious things C should do
#206Earlier quoted context omitted.
the constexpr stuff has been around since the beginning[0]. concretely, what other thing from D do you claim zig has added since? [0] minimally 2019, 3 years in: https://youtu.be/Gv2I7qTux7g?si=p0kVhtB56GvVLLNr
D had compile time execution of functions in 2007. Order-independent top level declarations. Underscores embedded in integer literals. (I stole this idea from Ada, which had been forgotten. Soon after D popularized it, it became standard in other languages.) Continue or break to labeled loop. Fixed sizes for ints, longs, etc. Of course, I don't know if there's a straight line here, and Zig is welcome to use any featu…
> Underscores embedded in integer literals.
Perl had this years before D even existed [1]. Given its earlier age and higher reach, it's likely that Perl did more to popularize the idea as well.
> Continue or break to labeled loop.
Also a feature that Perl had years before D's existence [2].
These two are the ones I immediately recognized because of my familiarity with Perl, but given the trend, I'm doubtful of the other claims as well now.
[1] https://perldoc.perl.org/5.005/perldata [2] https://perldoc.perl.org/5.005/perlsyn#Loop-Control
Re: Obvious things C should do
#207Earlier quoted context omitted.
It's odd because you lose control over that aspect of compilation. It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Every time you do exploratory work you now have to comment out all the tests that this work breaks because otherwise it won't compile anymore. That would be even more annoying than Go's stupidly pedantic compil…
> It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet. Can't that be an optional thing decided by some compiler flag? I think I remember doing something like that in D.
That's how one would normally do it, and that's what I would expect to see: Build for development, and the compiler only errors out if things are so bad that it's unable emit a binary (for everything else, it emits warnings). Build for release, and it errors out unless EVERYTHING is done right.
Unfortunately, ever since golang decided on an autocratic and backwards "there are no warnings, only errors" policy, others have started to sip from the same kool aid jar.
Re: Obvious things C should do
#208Earlier quoted context omitted.
I think that's a problem with C's header files. With C++ you have the third option where the compiler makes sure that the "people will do the right thing" with the private keyword - assuming they're not doing some weird pointer math to access the private members.. Of course, you'll have to deal with ABI stability now but it's all tradeoffs for what your requirements are.
Of course you should do the right thing, but if you want to break the private of C++ it is much easier to "#define private public" before including the header file.
now that's just diabolical...
Re: Obvious things C should do
#209i think compile time evaluation should be extended: if it can get a pass over the source code then this could replace preprocessor macros with something less shitty.
maybe even add reflection and the ability to check for the type of a value - but that is probably too much to ask for.
Re: Obvious things C should do
#210Earlier quoted context omitted.
As someone who likes C header files, I enjoy manually maintaining them. Designing the interface separately from the implementation feels good to me, and a well-structured .h file is nicer to read than any auto-generated docs I've encountered.
> Designing the interface separately from the implementation feels good to me would you make the same argument for java then?
Even as a java programmer, I think this is a bad take. Java doesn't force separation of implementation and interface, and java interfaces also have a lot of weird stuff going on with them.
Java also has too many tools for this. You both have class/interface, but also public/private. I honestly think C does it better than Java.