Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
1–10 of 118 posts
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#2Unmanageable really has a context and depending on the use case sometimes C is the best option…
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#3I love C. It's what I learned after learning MASM style Intel assembly.
I have a project still at the planning stage. I have many Rust crates lined up. So far I really like the bits of Rust I have learned. C plus generics? Sign me up! But damn, after coming from really awesome IDEs like Visual Studio, it just seems like it's taking me forever to make progress.
Right now I'm asking myself, does Rust save me time in the long run from chasing down bugs? I'm not really sure, because I think I'm already decent at avoiding C foot guns.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#4Unmanageable really has a context and depending on the use case sometimes C is the best option…
The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#5Unmanageable really has a context and depending on the use case sometimes C is the best option…
The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.
Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption.
I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#6Earlier quoted context omitted.
The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.
Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption. I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.
Congrats on providing yet another reason why software should be at least open source (if not actually libre)
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#7I love C. It's what I learned after learning MASM style Intel assembly. I have a project still at the planning stage. I have many Rust crates lined up. So far I really like the bits of Rust I have learned. C plus generics? Sign me up! But damn, after coming from really awesome IDEs like Visual Studio, it just seems like it's taking me forever to make progress. Right now I'm asking myself, does Rust save me time in th…
The use-case for Rust is not the same as C.
In general, C is a better option if you find you are escaping to macro defined Assembly or other memory ops (glib back-ported data structures for C highly recommended). Rust likes to keep unsafe operations organized, but is a persistent pain if a problem scope requires many "unsafe" operations.
I'd wager Rust will end up like Boost... really cool.. but too chaotic to trust past 10 months. =)
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#8Unmanageable really has a context and depending on the use case sometimes C is the best option…
I lol every-time someone quotes their favorite JIT language that is essentially a meta-circular compiler for C library bindings.
“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” ( Albert Einstein )
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#9Earlier quoted context omitted.
The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.
Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption. I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.
Well I guess it's a good thing no one ever had a double free in C :)
> They mean you can never tell what `delete` does.
Can you elaborate on this? A destructor is a function that's built into an object. It's really not more complicated than that. If malloc/free are functions that should be used in pairs, then the constructor/destructor pair tries to provide a convenient and structured way to know where malloc/free go. You would call new in the constructor and delete in the destructor.
I'm curious to know what you prefer?
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#10Earlier quoted context omitted.
Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption. I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.
Well I guess it's a good thing no one ever had a double free in C :) > They mean you can never tell what `delete` does. Can you elaborate on this? A destructor is a function that's built into an object. It's really not more complicated than that. If malloc/free are functions that should be used in pairs, then the constructor/destructor pair tries to provide a convenient and structured way to know where malloc/free go…
Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere.
Somewhere down the line these other objects are freed again, causing double free.