The abhorrent 🔥 rites of C
-
you can just pass the pointer directly
I did mention that. But to pass the pointer directly you have to extend the interface and add a function (or set of functions). That's the elegant way to do it, certainly but there re costs to it, particularly if the URL argument is passed through a non-trivial call chain before being parsed. Another alternative is to replace the string arg with some sort of tagged union / variant type, but again that's a major bit of refactoring.
As I said, it kludgy, and favours convenience over elegance. But its not unspeakably bad.
NB: If you don't control both endpoints, then the whole interface falls apart, because you need to be in the same address space for that pointer to be meaningful.
-
Oh right; and when I said "cow" you should have known I was including goats, sheep, chickens, etc. You must have telepathy to discuss things with mega-genius Ronin. Reading his posts without engaging your telepathy is not allowed!
It's common to use Unix to refer to Unix-like operating systems.
The important part to me is that you said the PS4 ran on Unix, which is blatantly untrue. But now I've learned the fault was mine, as I did not properly engage my telepathometer while reading your post.
You realize what you're arguing over, right? Had I said Unix-like, what would have changed? Also I clarified what I meant in a follow up post. Unix-like is a term used by many people. It is used to refer to Linux, BSD, Solaris and operating systems that share a Unix heritage and/or are modelled after Unix concepts. I'm not engaging in some esoteric vodooo wordplay here. It's an accepted and widely used terminology.
It kind of defeats your "Unix is so important to the success of the PS4" argument. Pretty thoroughly, I'd say.
I used Unix as an umbrella term. But since you like to nitpick I'll rephrase my argument.
You're right, Unix-like operating systems are definitely not used in commercial products all arround the world, like the PS4 or WhatsApp servers, or smartphones.If that doesn't qualify as "doing shit" to you I don't know what is.
Please, note the highlighted part, where I emphasise how Unix-like operating systems and C are used to actually make useful things that are used in the real world by lots of people. That was my point.
It's not.
Fair enough, why bring up Mac Classic then? There doesn't seem to be anything special about its use of pascal, it couldn't have been a very useful choice of language. Otherwise modern OS X versions would use it instead of C.
You need a kernel. Just like a car needs a chip to control the engine timings.
Which is used to actually do shit. Like message passing and socket comunication and all the low level things you can't do un userspace. The scheduller works in kernel space and there are differences from using one scheduller or the other.
But it doesn't need to be that kernel, and none of the customers would notice or care if it switched from that kernel to another kernel.
As I pointed out above, there can be differences in speed,or security, the system being demonstrably correct or having support for filesystems that avoid data corruption (like ZFS).
You seem to think of the customers as regular home users that do not care what OS their computer uses as long as they can use Skype, Facebook and Steam. There is a whole range of other people (sysadmins, researchers, etc...) that do not have the same priorities.
-
@gwowen said:
Since you control both end points, who cares if its a bit Heath-Robinson?
If you control both sides, you can just pass the pointer directly. No loss of safety by comparison with what they're doing (which is already utterly unsafe), but a heck of a lot less screwing around!
Just because you control both sides doesn't mean you also control the middle. And you can't always cut out the middleman (let's say there's your architecture's middleware scheduling library, mandated by company policy, standing between you and
pthread_create()).
-
At least I've grown up since.
That happens after you go back to fix that code a year later and go "oh fucking christ, what was I smoking then?!?"
-
It's pretty fucking simple in C#. Either
It's so simple in C# that Microsoft had to say this about the upgrade to .NET 2.0:await/asyncorlock()yo shit. (And yes,lock()isn't super-performant, but it's better than not writing worker threads at all because you're huddled into a ball in the corner shivering with fear.)There are also many applications that will fail because they have race conditions that will be exposed once the performance characteristics of the runtime have changed.
(used to be referenced from http://social.msdn.microsoft.com/Forums/en-US/0ff1a105-35ba-4658-a202-a56454497d75/net-backwards-compatibility?forum=xnaframework until 2014 or so but the page has disappeared)
Apparently people relied on undocumented performance characteristics of the runtime so their code worked by coincidence or most of the time, but stopped working when it was optimized.
Of course it did: they didn't understand the underlying problems but thought sprinkling some magic async-lock-foo dust over their code would fix things.
-
Apparently people relied on undocumented performance characteristics of the runtime so their code worked by coincidence or most of the time, but stopped working when it was optimized.Of course it did: they didn't understand the underlying problems but thought sprinkling some magic async-lock-foo dust over their code would fix things.
So, basically, shit developers wrote shit code.
-
It's so simple in C# that Microsoft had to say this about the upgrade to .NET 2.0:
Right; here's a counter-argument quoted from Agrippa the Skeptic, 1st century AD:
Apparently people relied on undocumented performance characteristics of the runtime so their code worked by coincidence or most of the time, but stopped working when it was optimized.
Stupid people do stupid things.
Of course it did: they didn't understand the underlying problems but thought sprinkling some magic async-lock-foo dust over their code would fix things.
Async/await didn't exist in .net 1.1 or .net 2.0.
-
It has survived through 30 years being used as the language for programming operating systems for a reason
Moot argument. It survived for 30y because there was no real alternative and later there was a metric ton of legacy code. And that led to our C vicious circle.
In fact, name one modern operating system that isn't programmed in C.
Another moot argument for the same reason. Windows has a very large portion written in C++. There was some system (can't remember the name) written in C++.
No one is going to use a CGI library programmed in C to make a website, but no one is going to use C# for low level programming.
And no sane person in 2016 will use C for that also. You have type and memory safe (unless forced otherwise) languages like C++.
If You think so, here's an exercise. Try to reimplement the Minix kernel in C#. Or Unix device drivers in Java. Or userland utilities like grep in Haskell. Then measure the speed and see how it scales.
Thank you, I'll rather do it in C++ with even more performance than C (yes, google it - especially the standard library stuff) and safety AND productivity it provides.
-
Moot argument. It survived for 30y because there was no real alternative and later there was a metric ton of legacy code. And that led to our C vicious circle.
If there was a sufficiently compelling alternative, projects would have switched and new projects would have started from scratch. There wasn't. And the current alternatives are debatable at best. C++ is not an alternative to C for systems programming.
Windows has a very large portion written in C++.
And another large portion written in C, and another large portion written in C#. Do you have any statistics as to what is the percentaje of C++ regarding C and C#?
You have type and memory safe (unless forced otherwise) languages like C++.
Any language that supports arbitrary pointer arithmetic is not memory safe. Yes, that includes C++. You can't say "safe language" and "C++" in the same sentence. In fact, C++ allows you to violate many OOP concepts (e.g: friend functions) for an OOP language, it's not even good at that.
Windows is partly written in C because C is inescapable when writing operating systems. There are some low level parts that can't be written in C++ and the OO capabilities of C++ turn into baggage when writing low level code for that reason. Also for a lot of things you have to restrict yourself to use C (which is not a strict subset of C++) when coding operating systems.
C++ is a joke regarding safety and garbage collected languages aren't really suitable for low level programming unless you are willing to write a lot of assembly.
If you wanted to use an example of a type and memmory safe alternative you should have brought up either Rust or Go, not C++. It's doubtfull someone will make a successful OS out of them in the near future, but at least they are actual attempts to replace C. For one, Rust actually implements memory safety and OOTB unicode support (personally I'd put my money on Rust, since I actually like the language).
with even more performance than C (yes, google it - especially the standard library stuff)
The claim that it is "faster" (funny you should bring it up, its usually the other way arround) comes mainly from the implementation of
qsort(). Perhaps you can prove to me that it is faster for the general case, do feel free to point me towards benchmarks.
-
No, it's been chosen time and time again by experienced programmers to build operating systems from scratch.
No, it wasn't. And I'm a person who actually is involved in making an OS (a shitty one, but still). You either have legacy stuff, or system experts who came to experience on legacy stuff.
I would. C is fast, battle tested and has useful abstractions. I move you do not understand operating systems.
You have alternatives, which are often faster, and provide memory and type safety - things which C lacks.
-
It was the best option available.
That's so true, but you put the emphasis on a wrong word. You should bold "was". It ain't anymore. It hasn't been for years. What you have is a ton of legacy stuff, which just wait for another CVE bulletin to happen, because some C guru who likes clever code touched the memory in a wrong way, or used a too small buffer or something similar, unknown to the sane world. Or forgot the he should free memory with some magic function instead of standard free(), because the compiler wouldn't tell him. Oh, the glorious C!
-
-
If there was a sufficiently compelling alternative, projects would have switched and new projects would have started from scratch. There wasn't.
You are constantly using the argument of "there wasn't an alternative". Sure, there wasn't, but it's not an argument for the quality of the language itself. Less shitty language is a better choice than more shitty, but it's still shit.
And the current alternatives are debatable at best. C++ is not an alternative to C for systems programming.
No, they are not debatable, unless you want to debate with some C cultists, who will never changed their mind, even when threatened death. And yes - C++ is an alternative for systems stuff. Been doing that for some years now, while you haven't.
And another large portion written in C, and another large portion written in C#. Do you have any statistics as to what is the percentaje of C++ regarding C and C#?
Why do I need statistics, when you claim there is no alternative to C. I just need to point examples where other languages are being used, to prove you wrong.
Any language that supports arbitrary pointer arithmetic is not memory safe. Yes, that includes C++.
If you read what I wrote in () you'd understand my sentence. If you don't do explicitly dumb stuff , which usually require much work and much compiler cries, you have a safe language. Sure, you can manage memory in C++ by hand, but why would you? Are you an idiot to do that? Sure, you can use owning raw pointers in C++, but why would you? Are you an idiot to do that? Sure, can friend every class with every one, and ignore all the good programming practices, but why would you? Are you an idiot?
In C you get all those bad things by default.
Windows is partly written in C because C is inescapable when writing operating systems.
Oh, I would just love to see the arguments for that. Or will just leave it as a dogma?
There are some low level parts that can't be written in C++ and the OO capabilities of C++ turn into baggage when writing low level code for that reason.
Nobody is forcing you to use OO when it's not applicable for some reason. Yet, you still have all the good stuff of C++ when writing plain functions. That's the advantage of multi paradigm language, you know.
C++ is a joke regarding safety and garbage collected languages aren't really suitable for low level programming unless you are willing to write a lot of assembly.
And this deserves an award for ignorance. Garbage collection in C++? Nice way of proving you don't actually know what you're talking about.
The claim that it is "faster" (funny you should bring it up, its usually the other way arround) comes mainly from the implementation of qsort() . Perhaps you can prove to me that it is faster for the general case, do feel free to point me towards benchmarks.
Effective STL
“This is Effective C++ volume three – it’s really that good.” – Herb Sutter, independent consultant and secretary of the ISO/ANSI C++ standards committee “There are very few books which all C++ programmers must have. Add Effective STL to that list.” – Thomas Becker, Senior Software Engineer, Zephyr...
C++ std::sort being 670% faster, you can extrapolate the reasoning for other algorithms. That's another point towards your ignorance of the topic. If you make a claim, at least do a quick googling to find it it's true.
-
Also, how is Pascal better than C? What features help you write an operating system? Why do you think its better than C for the task?
For one, it has a real string type.Actually, scratch that "for one."
It's been said that everything in quantum physics can be extrapolated from pondering sufficiently on the ramifications of the Double Slit Experiment. Likewise, it seems to me that (nearly) everything that makes C utterly unsuitable as an OS development language can be extrapolated from pondering sufficiently on its completely broken handling of strings, arrays, and array pointers.
-
I hope I did this right:
-
projects would have switched
Because it's so easy and beneficial to everyone to rewrite millions of lines of code just because now a better language appeared. There is no "switching" in large projects. All of the mainstream OSes are codebases that are decades old.
C++ is not an alternative to C for systems programming.
You listened to one Torvalds rant too many.btw popular != good, successful != technologically superior, benchmarks != useful.
-
I hope I did this right:
Yup. I don't normally (personally) bother with the staff colour though.
-
Is there a whisper in this thread?
-
That was me.
-
:facepunch:
-
C++ is not an alternative to C for systems programming.
Right. Alternative would imply they're on equal footing. C++ makes C obsolete for systems programming.
Any language that supports arbitrary pointer arithmetic is not memory safe. Yes, that includes C++. You can't say "safe language" and "C++" in the same sentence. In fact, C++ allows you to violate many OOP concepts (e.g: friend functions) for an OOP language, it's not even good at that.
C++ is not an OOP language. It's a multi-paradigm language. It tries to give you the tools to create the abstractions that best describe the solution to the problem, instead of taking a "one size fits all" approach.C++ is a joke regarding safety
Every hole in C++'s safety mechanisms is there to accommodate C. Or is your argument that C++ shouldn't be used because it can be as unsafe as C? Where does that leave C?Perhaps you can prove to me that it is faster for the general case
Easy: there's no C construct that can't be replicated in C++ (and in general, you can simply copy-paste the code and it'll probably produce the same object code), which means that C++ can never be slower than C. However, there are plenty of constructs that you can write in C++ that can't be written in C.For example, templates and now constexpr functions, which are evaluated at compile time (can't get faster than not running code at all). For C to match them, you'd have to hardcode the results. There are also optimization opportunities that are available to C++ that C can't take advantage of because the type system contains information that the compiler understands and can make use of.
So, since it can never be slower but it can be faster, it's on average faster.
If there was a sufficiently compelling alternative, projects would have switched
http://developers.slashdot.org/story/12/08/15/1338212/gcc-switches-from-c-to-c
One of the most widespread C compilers switched to C++. Game, set, match.
-
C++ makes C obsolete for systems programming.
Pascal made C obsolete for systems programming, before C even existed, in theoretical terms at least. In practical terms, the Morris Worm made C obsolete for systems programming. We've known since 1989--over a quarter-century now!--that the language isn't safe to use for any software that presents an attack surface, particularly network-facing software.In any other branch of engineering, if you used materials that were known to be structurally unsound, and then your structure collapsed, you'd end up facing serious liability, most likely including criminal negligence charges. In any sane world, the C language would have been dead by 1990 because of this.
-
-
https://books.google.pl/books?id=RPnWe6QKnCcC&pg=PA203&lpg=PA203&dq=effective+stl+670%&source=bl&ots=ionDDVdhRp&sig=AUMfiGJv-Gee8Edg1_lCW3BLK4M&hl=pl&sa=X&ved=0ahUKEwjHtvbdg_3KAhXJQpoKHS16Bp4Q6AEIOTAD#v=onepage&q=effective stl 670%&f=false
C++ std::sort being 670% faster, you can extrapolate the reasoning for other algorithms. That's another point towards your ignorance of the topic. If you make a claim, at least do a quick googling to find it it's true.
http://i.imgur.com/SJ8wou8.png
I might have given the servercancercootiesby uploading a ~4k screenshot... oopsEDIT: the damn uploading spinner wont disappear..
-
C++ is not an alternative to C for systems programming.
?Right. Alternative would imply they're on equal footing. C++ makes C obsolete for systems programming.
QFFT
C++ is not an OOP language
…and OOP doesn't even cost anything unless you call virtual functions.
-
Have we considered using whispers to stealth-grant badges, I wonder?
-
…and OOP doesn't even cost anything unless you call virtual functions.
Depending on how you look at it, it doesn't even cost anything if you do call virtual functions, because accomplishing the same thing without language-level support for virtual methods would require manually implementing your own dynamic dispatch with at least the same level of overhead.
-
because accomplishing the same thing without language-level support for virtual methods would require manually implementing your own dynamic dispatch with at least the same level of overhead.
There are many developers who will happily use inheritance when they don't need it. People who started with Java often believe that presorting your data by type is somehow evil and that you should use inheritance instead.
-
Citation Fucking Needed.
You're right. I have no idea if they would have done so, had they thought other language was better. Newer projects would have used other alternatives had they been so good.
Or forgot the he should free memory with some magic function instead of standard free(), because the compiler wouldn't tell him.
What do you mean by this? Why wouldn't you use standard
free()?*p = malloc(<insert number here>); free(p);Why would you use a non standard function? For the laughs?
And yes - C++ is an alternative for systems stuff. Been doing that for some years now, while you haven't.
Explain why then. Don't use an argument from authority. C++ was created in the 80's. Windows NT was created in 1993. If it is such a no brainer , why didn't Microsoft programmers use C++ entirely instead of going for a mixture of C++ and C (and C#)?
Incidentally, which OS are you developing?
Why do I need statistics, when you claim there is no alternative to C. I just need to point examples where other languages are being used, to prove you wrong.
I claimed that there was no better alternative. I pointed out other operating systems written in...not C (Djikstra's THE was one). I concede that I could have been more clear, though. You can find operating systems written in Java or Haskell. How many of those caught on?
And this deserves an award for ignorance. Garbage collection in C++? Nice way of proving you don't actually know what you're talking about.
The "garbage collected languages" part was not referring to C++, but to the likes of Java and C#.
Oh, I would just love to see the arguments for that. Or will just leave it as a dogma?
It is not impossible to write an operating system that doesn't use C. The alternatives didn't seem to catch on however, and the landascape is dominted by C. If the advantages are so many that one would have to be insane to ingore the tradeoff why do so many people choose to do so? You cannot chunk it all to argumenting cruft or programmer ignorance since there are systems that started from scratch and didn't adopt C++.
C++ std::sort being 670% faster, you can extrapolate the reasoning for other algorithms. That's another point towards your ignorance of the topic.
Can I extrapolate this to ALL the algorhythms and not just sort and sqrt?. I know some functions in the STL were faster in C++ than in C, but so is asking for the first element of a 10 000 element list in haskell (or the first element of an infinite list, for that matter). What I meant was how fast was in the general case of running programs. As it turns out, this depends on the compiler and the implementation and not on the language itself. What compiler are you using? GCC, LLVM, Intel C++ Compiler?
This is assuming that speed is the only factor, of course and somehow the curve of learning C++ (which is steeper than C) is worth it.
Sure, you can manage memory in C++ by hand, but why would you? Are you an idiot to do that?
So, you're claiming that when writing low level code, you do not need to manage memory by hand? What do you use instead?
Sure, you can use owning raw pointers in C++, but why would you? Are you an idiot to do that?
So what's C++ alternative to owning raw pointers?
Sure, can friend every class with every one, and ignore all the good programming practices, but why would you? Are you an idiot?
Because people want performance more than they want a sane language I guess. If no one should use it under any circumstance...why is it even a thing?
If you make a claim, at least do a quick googling to find it it's true.
You made the claim that C++ was more performant and safe in the first place. The burden on proof is on you, not on me.
-
What do you mean by this? Why wouldn't you use standard free() ?
Many times, C interfaces will give you pointers to refer to a resource of some kind. A FILE pointer, for example (right out of stdio.h, so you can't blame bad designers for this) has to be cleaned up with a call to fclose, not free. Even though it's a pointer.So what's C++ alternative to owning raw pointers?
std::unique_ptr when you know at compile time how long the object has to live for, std::shared_ptr when it depends on runtime factors (like passing an object to several detached threads and wanting it cleaned up when the last thread is done with it). unique_ptr in particular should be as fast as an owning raw pointer most of the time.
Trivial example: https://goo.gl/VLlZBq You can see the assembly output for the raw pointer and the unique pointer is identical.
Added the c-like version of that: https://goo.gl/m4KKRY Notice how the C version does exactly the same as the C++ versions, but is a lot more verbose and error prone. And speaking of errors, the C version was given the advantage of not having to report any errors to the caller, which would actually make it even more verbose and complex. The C++ versions will throw a std::bad_alloc exception if the allocation fails, so you can't ignore errors by default, the way you can in C.
-
The optimizer was screwing with the output a bit (since the values were never really read) so I modified the functions a bit: https://goo.gl/lYUBr7
These three functions do essentially the same thing: They allocate a chunk of memory, initialize that memory to some value, return the value to the caller and report an error if allocating fails. The C-like function does what is the common idiom in C and uses the return value to signal errors, and an output parameter to return the value. The C++ functions are free to use the return value to return the value, since they report an error through an exception instead.
The C-like function has to check its output parameter isn't null, although I guess you could use a macro to disable that check in release versions, trust your callers to never pass a bad pointer, and get rid of the added safety for higher performance. When has a null pointer ever caused problems for a C program, right?
Notice how modern C++ is concise without being hard to understand. It does everything the other two versions do, is safer since it does the cleanup for you, and I would say is actually much more clear in its intent than the more verbose examples. The C-like version, on the contrary, mostly consists of clean up code. Miss one line, and you have a security vulnerability. And lets hope your caller will check your return value before reading from the output parameter. The caller of the C++ versions, on the other hand, can read the return value without worrying.
-
The major problems with C++ as an ecosystem are:
- The language has changed quite a bit recently, which can lead to problems with the language runtime (which is quite a bit thicker than for C) not matching up with the version of the language understood. This shouldn't happen, but it does and it is an entirely mysterious failure mode when it occurs.
- The language is less encouraging of a stable ABI, since use of inlined functions/member-methods and templates really binds the particular version of the library into the build of the consuming code. Exceptions might also have an impact here; that's not something I've studied in great depth.
Yes, it is possible to criticise C, but it fits its particular niche (a thin layer over assembly code with a relatively obvious mapping) very nicely.
(That said, if you're not writing classes or complex templates, and can avoid the problems I mention above, C++ is not a bad language to use.)
-
Yes, it is possible to criticise C, but it fits its particular niche (a thin layer over assembly code with a relatively obvious mapping) very nicely.
I'll agree that if you're writing a library, and you don't expect your clients to compile your code, providing a thin C wrapper over your C++ library is very helpful. You can even provide a header with helper classes to manage any resources you expose through the C interface so you have the portability of C and the resource management of C++.
Speaking of resource management, my previous examples were very simple because they only allocated once, so they didn't have to deal with the case of experiencing an error after you had allocated some resource that you need to then free. So I created an example to show how poorly manual error handling scales: https://goo.gl/76s2Dy I am willing to concede that the C-like function edges out the raw pointer version, since it doesn't repeat itself. It uses gotos but it's easy to understand what it is doing. The raw pointer version may be improved, maybe? I don't write code like that often enough to be up to date with the best bad practices.
The modern C++ version, however, beats both hands down. Perfectly safe, no resource leaks, concise and the point of the function isn't hidden below layers and layers of error handling.
-
Pascal wasn't a viable systems programming language (or, frankly, a viable programming language) for quite some time because of misfeatures like the size of an array or string being part of its type, a complete lack of bitwise operators, forcing ordering of declarations, no short-circuiting of Booleans (or more accurately, the order of evaluation is undefined), no break/continue, no return, weird semicolon behavior, etc.. See Why Pascal Is Not My Favourite Programming Language.
It wasn't a usable language until quite a bit later, when someone other than structured programming zealots got to fix the language. And mostly they fixed it by adding extensions to their compiler that were incompatible with other people's compilers.
-
So, basically, shit developers wrote shit code.
Yup. As I said, they believed they understood it because it's pretty fucking easy as Blakey & Co. told them. Alas, they didn't because it ain't.Stupid people do stupid things.
Smart people can write perfectly OK thread code in C. If something merits the label "easy", that means you don't have to be particularly smart to use it correctly.@LaoC said:
lock() did. Which is arguably a lot easier than async programming but obviously not easy enough.Of course it did: they didn't understand the underlying problems but thought sprinkling some magic async-lock-foo dust over their code would fix things.
Async/await didn't exist in .net 1.1 or .net 2.0.
-
Windows is partly written in C because C is inescapable when writing operating systems. There are some low level parts that can't be written in C++ and the OO capabilities of C++ turn into baggage when writing low level code for that reason. Also for a lot of things you have to restrict yourself to use C (which is not a strict subset of C++) when coding operating systems.
ISTR they tried to a pretty large extent in BeOS. Didn't work, even though I don't think even these guys were crazy enough to do stuff like pass C++ exceptions from kernel to user space—which sounds like a cool thing to have at first look, get rid of magic return values and all, but if you think it through in consequence from interfacing to other languages to how to avoid recompiling all your userland when you change the kernel it's just
-
Many times, C interfaces will give you pointers to refer to a resource of some kind. A FILE pointer, for example (right out of stdio.h, so you can't blame bad designers for this) has to be cleaned up with a call to fclose, not free. Even though it's a pointer.
Point taken, you are not using free (though it sounds more like OP was talking about freeing a struct with a dedicated function or something of the sort). I fail to see how that is an issue, though. You
open()a file and youclose()it. The interface is perfectly consistent. File pointers are different because on most operating systems you have a limited number of files that you can open simultaneously, so the special handling is justified.These three functions do essentially the same thing: They allocate a chunk of memory, initialize that memory to some value, return the value to the caller and report an error if allocating fails.
int * cptr(int * out) { if(*out == NULL) return FALSE; void * ptr = malloc(sizeof(int)); if(ptr != NULL) return FALSE; *ptr = 10; *out= *ptr; return TRUE; }(Since it seemed like you were using C++ idioms I rewrote the program in pure C).
It honestly doesn't seem so illegible . Of course the C++ version is more succint. This is something that you get the higher you go. You can do quicksort in haskell with exactly 1 line of code. The question is if the tradeoff is worthy. The tradeoff in legibility seems not really worth it (again, we can go higher up the language ladder and we get more readabilty at the cost of performance).
The C-like function does what is the common idiom in C and uses the return value to signal errors, and an output parameter to return the value. The C++ functions are free to use the return value to return the value, since they report an error through an exception instead.
C++ does a lot of stuff behind the scenes to make that happen. Doing that in high level applications is good. Dealing with stack unwinding and exceptions in low level code is not so ideal. This is why e.g Rust doesn't have classes (though it does have something similar) and IMHO it has a real shot at replacing C.
The C-like function has to check its output parameter isn't null, although I guess you could use a macro to disable that check in release versions, trust your callers to never pass a bad pointer, and get rid of the added safety for higher performance. When has a null pointer ever caused problems for a C program, right?
In theory this sounds horrible, but in practice, it's not such a huge problem. C was intended for low level usage and this kind of "unsafe semantics" were intentionall. Most tools would detect uses after free, tough (if you bother to use them).
If you want absolute safety, you can allways go higher up the ladder. Haskell programs can be proven for termination (and correctness according to a spec) and don't deal with pointers at all. They take quite the performance hit but if you don't mind that your code can be secure and probably correct (there are ways to demonstrate that a specially . Almost no one bothers, though. I'll take the ocassional bad pointer over the overhead of having to deal with exceptions and unwinding of the stack.
-
You don't pay for exceptions unless you actually throw one.
-
Since it seemed like you were using C++ idioms I rewrote the program in pure C
Why are you returning a pointer to int? And assigning literal int constants to them? What happens when someone tries to dereference that?Fine, you saved yourself some squiggly lines. Did you try compiling it in gcc? Just change the -std= parameter to c11 or whichever version you like. Can you show how the assembly performs better than the C++ assembly? Because if it matters, C++ can slum it and behave like C, but C can't decide to be safer and more concise.
-
It was written by someone who doesn't know how to make sscanf do what he wanted it to do. This is all you need:
[code]
ret = sscanf(filename, "%*s://%p"; &ffpipe);
[/code]You're overestimating
scanf: %s cannot do that.
-
Windows is partly written in C because C is inescapable when writing operating systems. There are some low level parts that can't be written in C++
What low-level parts exactly cannot be written in C++ but can be written in C? C is not a subset of C++ language-wise (yeah, I too know lots of C constructs that won't compile in C++), but feature-wise C90 is a subset of C++ (because none of the aforementioned constructs are irreplaceable).
In my understanding, an OS's low-level parts that can't be written in C++, can't be written in C either and have to be written in assembly language instead.
-
Haskell programs can be proven for termination
Citation Needed, in the face of a program that says this (pseudocode) :
[code]
while the termination detector says this program terminates:
do nothing.
[/code]By all that's holy, Diskarse sucks donkey balls.
-
@Steve_The_Cynic said:
It was written by someone who doesn't know how to make sscanf do what he wanted it to do. This is all you need:
[code]
ret = sscanf(filename, "%*s://%p"; &ffpipe);
[/code]You're overestimating
scanf: %s cannot do that.Correct. I need to check my code more thoroughly before posting it. Given that the URI schemes being detected are all lower-case alphabetics, this works:
[code]
ret = sscanf(filename, "%*[a-z]://%p"; &ffpipe);
[/code]You can make it more resilient to weird schemes by elaborating on what is in the []. In particular,
[a-zA-Z0-9]has promise.
-
This post is deleted!
-
Citation Needed
Actually, it's stronger than that. There are Haskell programs can't be (simply) proven to terminate because they will only terminate of some unproven conjecture of mathematics is true: an example might be a program that searches for the first even number (greater than 2) that does not satisfy the Goldbach Conjecture. It's not difficult to write such a program, but proving either termination or non-termination is really extremely non-trivial.
-
You can make it more resilient to weird schemes by elaborating on what is in the []. In particular,
[a-zA-Z0-9]has promise.Or possibly
%*[^:], but at this point that's mostly up to personal preference.But I'll second @Steve_The_Cynic, proper use of
?scanf()solves this easily. People should get to know it better, because there's tons of shit code that one call to one of the scanfs could neatly replace.
-
Hmm. OK, but those are merely hard to prove whether or not they can terminate since they rest on an unproven conjecture. The version I proposed is more cunning(1) - it is the computer-science equivalent of Gödel's Incompleteness Theorem, and the program CANNOT be proven to either terminate or loop.
(This type of manipulation is directly equivalent to sentences like "This sentence is false", whose truth or falsity is not decidable.)
EDIT:
(1) And not my invention.
-
-
Have we considered using whispers to stealth-grant badges, I wonder?
The point of the badges are that they're visible. Otherwise we'll get more redundant flags once they've been awarded than we get at the moment, because they haven't been seen to be awarded yet..
-
@PleegWat said:
Is there a whisper in this thread?
No. HTH, HAND....
Two whispers, then.
Goddamn mods talking about us behind our backs. Mod abuse if I've ever seen one.
