Two types of C programmers
71–80 of 225 posts
Re: Two types of C programmers
#72Earlier quoted context omitted.
I've been using D for OS development and have found it very good for controlling low-level details. GDC is the GCC frontend for D, and has most/all of the same features for controlling this stuff as GCC. For example, you can use `@register("edx") ulong x;` to specify that a variable should be in a particular register, `@section("t1")` on functions to place them in certain sections, and the inline assembler is the sam…
Thanks for the information. Appears that it does support the section attribute from GCC too. I'll have to explore this a bit and see if I can use it, since it seems to have all or most the features I use. I did learn D some years ago when the standard library situation was not great, but might be worth looking at again.
import core.stdc.stdio;
extern (C) void main() {
printf("Hello world\n");
}Re: Two types of C programmers
#73Re: Two types of C programmers
#74Earlier quoted context omitted.
The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.
This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.
By install count, Linux runs on far more platforms than anything else: smartphones, tablets, servers, virtual machines, embedded devices, supercomputers, and spacecraft.
Re: Two types of C programmers
#75Earlier quoted context omitted.
The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.
This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.
Not even Android games get ported in any significant number to GNU/Linux.
The war of Linux Distributions is ten fold worse as the UNIX wars.
Re: Two types of C programmers
#76The post is kind of confusing regarding which sort is the "first sort", because they are presented in one order in the provocative thesis, and in the other order in the following paragraphs. But: > My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust. If in this context the "second sort" is the type who likes C on its own merits (rather t…
Re: Two types of C programmers
#77Earlier quoted context omitted.
The register support you describe is an extension, not really part of C. Gcc has lots and lots of C extensions, but they don't make the language simple. D's inline assembler does register management for you, i.e. it tracks register usage through the instructions, so you don't have to say which registers are read or written to. D does not support the "section" extension. I understand that certain gcc C extensions are…
Thanks. My root comment mentioned that it was not really the features of C that I depended on, but the GCC specific features. I'm interested in using D now as sibling comment mentions that I can use some of these features in gcd, but I'm not yet sure how much benefit I'd get over using C by using a subset of the D features which are compatible with the constraints of my VM.
Re: Two types of C programmers
#78Earlier quoted context omitted.
The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.
This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.
Re: Two types of C programmers
#79In some cases efficient memory management _is_ the problem to be solved. I'm not just talking about esoteric or embedded systems here. If you're developing for modern GPU's with a modern API, like Vulkan, you must manage GPU memory yourself. With direct memory access you can do many "unsafe" things, like memory aliasing, to improve performance. "Safe" languages, like Rust, will not help you here.
Re: Two types of C programmers
#80People who chose C as the best option at the time might not be even around the project anymore.