if assembly was regular writing then C would be cursive. I would like to see D/go/rust succeed where C/C++ has failed.
C and C++ Aren't Future Proof
51–60 of 108 posts
Re: C and C++ Aren't Future Proof
#52Earlier quoted context omitted.
Much undefined behaviour can't be statically detected, unfortunately.
Is there a way to detect it dynamically, e.g. by running C code under a debug mode or in an interpreter that errors out when undefined behavior is encountered? I've occasionally wanted to have something like that to use in tests, so I could ensure that at least my common code paths aren't relying on undefined behavior. I know about gcc's -ftrapv and a few other options, but nothing comprehensive.
In theory, for sure. Valgrind can test for certain kinds of undefined behaviour - it runs the code in a special virtual machine.
You could also have the compiler insert checks. Obviously this isn't desirable for a lot of C projects by default, but (other than in places like kernel development etc.) it could be a nice debugging aid. I don't know of any good tools for doing this comprehensively.
Re: C and C++ Aren't Future Proof
#53Earlier quoted context omitted.
Much undefined behaviour can't be statically detected, unfortunately.
Is there a way to detect it dynamically, e.g. by running C code under a debug mode or in an interpreter that errors out when undefined behavior is encountered? I've occasionally wanted to have something like that to use in tests, so I could ensure that at least my common code paths aren't relying on undefined behavior. I know about gcc's -ftrapv and a few other options, but nothing comprehensive.
I've heard of several:
http://embed.cs.utah.edu/ioc/ http://code.google.com/p/c-semantics/
Haven't used either in anger though.
Re: C and C++ Aren't Future Proof
#54Earlier quoted context omitted.
"I'm saying sanely styled code does not have these issues in practice" Otherwise known as the "just do it right" argument. This is an argument that goes all the way back to the days of writing everything in assembly language, and it was just as wrong then as it is today. If only a restricted subset of a language can ensure that basic issues do not become serious problems, then the language should be restricted to tha…
I really don't have any difficulty finding programmers who have the discipline to not use the unsafe parts of the language all over the place. C++ has an issue with having a fragmented multitude of sane subsets, but any of them are fine if they get the job done. That said, I don't understand why you still keep putting up awful mostly-C code as if any trained C++ programmer wouldn't yell at you for doing it wrong, eve…
If those things are bad, why does the standard allow them? If any trained C++ programmer would know not to write that sort of code, what purpose does allowing it serve?
Re: C and C++ Aren't Future Proof
#55Earlier quoted context omitted.
"I'm saying sanely styled code does not have these issues in practice" Otherwise known as the "just do it right" argument. This is an argument that goes all the way back to the days of writing everything in assembly language, and it was just as wrong then as it is today. If only a restricted subset of a language can ensure that basic issues do not become serious problems, then the language should be restricted to tha…
>Otherwise known as the "just do it right" argument. Maybe, maybe not. Can you make a better example than arbitrary magic numbers used as pointers?
Hey, the standard allows it. Why are we excluding code that is allowed by the standard and that many programmers would write if we are not making the "just do it right" argument?
Re: C and C++ Aren't Future Proof
#56Earlier quoted context omitted.
Much undefined behaviour can't be statically detected, unfortunately.
But the the author of the original piece is mostly concerned with undefined behavior that can be detected statically - otherwise, compilers would not be able to exploit it to make optimizations.
Not so. Assuming that a piece of code isn't doing anything undefined is a lot easier than detecting that it is.
That's generally how compilers take advantage.
Re: C and C++ Aren't Future Proof
#57If all people started writing code with more RAII and Smart Pointers this would be a better world. Talking about C, well... it's unsafe by nature, let's face it.
If people treated C++ as a maintenance-only language and used it only for legacy code -- like COBOL -- the world would be a better place. The world would also save billions of dollars. This is not a matter of RAII or "smart" pointers (which are not even smart enough to deal with cyclic references unless the programmer explicitly breaks the cycle). It is a matter of a language whose high-level features are constrained…
You're ignoring the cost of actually running the applications in question. The benefits of reduced development costs can quickly be negated if performance starts to suffer.
We see this a lot with Ruby on Rails web apps, for instance. Perhaps they're quicker to develop in many cases, and maybe they're slightly less vulnerable to certain problems than C or C++ apps are, but they are much less efficient at runtime.
This inefficiency becomes visible when more hardware, or more powerful hardware, is needed to run such web apps. This inefficiency further becomes evident when users (it's worse when they're highly-paid employees) have to literally sit and wait for the web app to do its work. Over time, these costs can add up significantly.
It can be even worse for applications that are running on millions of systems. Even slight performance decreases can sum together to be very costly at such a scale.
C and C++ are still unmatched when it comes to producing efficient applications, both in terms of CPU usage and memory usage. Languages like Go and Rust may get close, but that'll be far in the future, if ever. I think it's safe to say that scripting languages like Perl, Ruby and Python will, in general, never be as efficient as C or C++.
Maybe you see C and C++ as a "waste of time and money", but they bring significant cost reductions for many of their users. That's why they're still being used today, and while they'll be used for a long time to come.
Re: C and C++ Aren't Future Proof
#58Earlier quoted context omitted.
I really don't have any difficulty finding programmers who have the discipline to not use the unsafe parts of the language all over the place. C++ has an issue with having a fragmented multitude of sane subsets, but any of them are fine if they get the job done. That said, I don't understand why you still keep putting up awful mostly-C code as if any trained C++ programmer wouldn't yell at you for doing it wrong, eve…
If those things are bad, why does the standard allow them? If any trained C++ programmer would know not to write that sort of code, what purpose does allowing it serve ?
The more powerful features of C and C++ can be "bad" when misused or abused. Yes, that can happen when in the hands of a beginner.
There are times, however, when an experienced, knowledgeable user does need the power these features provide. Amazing things can be accomplished that couldn't otherwise be done when using a language like Java, C#, Ruby, Python, Perl, Go, Haskell, or Scheme.
Re: C and C++ Aren't Future Proof
#59semi-oftopic: ...nice to know about Haskell++, never heard of it before. Hopefully the lung cancer C++ joke doesn't apply :)
Re: C and C++ Aren't Future Proof
#60Earlier quoted context omitted.
> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…
Ostensibly, a platform like Java or Rust is supposed to abstract stuff like the memory model. I haven't written a lot of Java code, especially not Java code that runs on many different native system / VMs, but from my perspective of blissful ignorance, it seems to have done the job? Same with other high-level VM based languages like Python...
Python is not future proof.
There are undefined sequences even in Python, where Jython and CPython output different programs.