every time I've looked into this I've found the documentation severely lacking in examples of how one would go about incrementally migrating a c project to better c. does someone have a pointer to a blog post or even a git commit that illustrates the first step of migrating a single c file, with all the attendant makefile changes?
Better C – A subset of D Programming Language
231–240 of 360 posts
Re: Better C – A subset of D Programming Language
#232One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
Im annoyed that you have to spell out auto all over the place. It should be implicit. The compiler should automatically add auto if you have not specified something else.
Re: Better C – A subset of D Programming Language
#233Earlier quoted context omitted.
I think a lot of people would argue that many C++ features, like OO, are not strictly improvements. Also C++ is a massive language, and part of the beauty of C is it's simplicity. I think what a lot of people would want is something which maintains that simplicity, but mainly delivers on basic QOL lessons we've learned in the past 40 years, like that it's nice not to have to pass around array lengths as separate vari…
> I think a lot of people would argue that many C++ features, like OO, are not strictly improvements. Sure, but D has those OO features, too, so that's an argument against both, not one. > like that it's nice not to have to pass around array lengths as separate variables. -betterC doesn't have dynamic arrays, though. That's one of the "unavailable features" currently. But that's also sommething C++ solved as well - s…
One thing that D does better and that on C++ depends pretty much on the team and which compiler toolchain you use, bounds checking for strings and arrays.
You can get them in C++, and VC++ does it by default on debug code, but not all compilers do by default and it isn't required by the standard unless you explicitly make use of the at() variants.
On the other hand, every attempt to bring bounds checking to C has failed, lets see how far Microsoft goes with Checked C.
Re: Better C – A subset of D Programming Language
#234Earlier quoted context omitted.
In rust this would be expressed as multiple impl blocks with different generic parameters which show up as such in the documentation. https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...
What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work…
> What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"?
No. The type which tells you that Vec works like a slice of T is https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-Deref
The others are separate abstract operations which are available (implemented) on vecs e.g. AsRef/AsMut denote that you can trivially get a (mutable) reference to the parameter from a vec. The implementations are similarly trivial (https://doc.rust-lang.org/src/alloc/vec.rs.html#2348-2374).
> I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.
Do you mean this one?
auto auto map(Range) (Range r)Re: Better C – A subset of D Programming Language
#235Earlier quoted context omitted.
D is a much better option for those that believe that it isn't a crime to have a GC on a systems programming language. It basically follows on the school of thought at Xerox PARC, ETHZ, and Microsoft Research. Now what it lacks is more more manpower to improve its runtime capabilities and having a big name actually pushing it forward. However this doesn't need to be a zero sum game, any language that helps to fix C i…
the betterC form of D does not use the GC (and the compiler will let you know).
I used to be a regular on D forums. :)
Yes, betterC does not use the GC, but I was speaking about the whole language, and many anti-GC folks eventually discover that they can stick to regular D and still deliver what they were trying to do.
You can imagine an OS written in D, where BetterC mode gets used in the layers that for whatever reason cannot afford a GC, while all the remaning layers can happily take advantage of it.
Re: Better C – A subset of D Programming Language
#236Earlier quoted context omitted.
Pascal is not better, it's just more verbose.
Just a couple of ways how it is better, using Turbo Pascal 7 for MS-DOS, released in 1992. - Units (modules) for separate compilation with strong type checking and not needing useless prefixes - A proper string type - Proper arrays with bounds checking, it has functions to retrieve upper and lower bounds - Allows the definition of numeric ranges - Enumerations are their own type, can be used as array indexes or data…
Unfair comparison: Turbo Pascal 7 is more like C++20.
Re: Better C – A subset of D Programming Language
#237Earlier quoted context omitted.
In D, you don't declare that a type X should have operations A, B, C. Instead, at the moment of template instantiation, you can verify if the provided type has operations A, B and C.
That makes for terrible docs and discoverability, which is the problem here. Maybe D should allow the user to name the return type (an existential variable) and static assert stuff on it: `SomeVar f(…) with isRange!SomeVar` or whatever. `auto` just means "you have to read the implementation because it can be literally anything"
Well, it is visible in documentation, but even those can be hard to parse:
uint startsWith(alias pred = (a, b) => a == b, Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range && (Needles.length > 1) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint));
Re: Better C – A subset of D Programming Language
#238Earlier quoted context omitted.
Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until…
Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until…
Templates don't exist until compile time, until you build the code, the IDE plugin doesn't have the full data on what types exactly are there. Java/C# generics are more limited in functionality, but it's a tradeoff in exchange for better ahead of time knowledge of types.
Re: Better C – A subset of D Programming Language
#239Earlier quoted context omitted.
Hard disagree. MyClass myVar = new MyClass() is not DRY. It also makes it practical to use complicated structures out of generics/templates without killing the developer With , Declarations>.
Hard disagree. If you are assigning a value that's the result of an expression you might have somewhat complicated logic. Being able to say what you expect returned is very useful. MyClass myVar = something ? SomeFunction() || somethingThatMightBeASubClassOfMyClass
Even if you have var/auto, you don't have to use it every time.
Re: Better C – A subset of D Programming Language
#240Earlier quoted context omitted.
What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work…
> What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? No. The type which tells you that Vec works like a slice of T is https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-Deref The others are separate abstract operations which are available (implemented) on vecs e.g…
No this one:
"Returns: A range with each fun applied to all the elements. If there is more than one fun, the element type will be Tuple containing one element for each fun."