61–70 of 108 posts
Laws are the be broken, and C/C++ is the wild west in this respect - cowboy programming is welcomed.
And I love it :)
Earlier 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…
You certainly could define some basic things to make the language safer. For example, make variables always be initialized to zero if not explicitly initialized, and force accessing beyond the bounds of an array to be a fault rather than undefined behavior.
Earlier 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…
Even modern C++ has very unsafe parts.
Earlier quoted context omitted.
You should not switch your apps. You should stop creating new projects in C++ once Rust is mature enough for your liking. The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating n…
Exactly, it's a chicken and egg problem. C++ has tons of libraries, while Rust has barely any. Rust can use external C bindings, but not C++ ones yet. I think if they solve the issue of using C++ libraries from within Rust, the transition will be much easier, and meanwhile more native Rust libraries will be created.
Earlier quoted context omitted.
Exactly, it's a chicken and egg problem. C++ has tons of libraries, while Rust has barely any. Rust can use external C bindings, but not C++ ones yet. I think if they solve the issue of using C++ libraries from within Rust, the transition will be much easier, and meanwhile more native Rust libraries will be created.
Is the C++ ABI issue ever going to be solved?
Earlier quoted context omitted.
I've been working my way through the Rust tutorial. As much as I like the power and control it gives me, they really need to take a note from Go on the syntax. Some of the even fairly contrived examples are an eye-sore. I need to give it more time but yeesh there's a lot of syntax to look out for.
Can you give some specific examples? I myself have been known to bikeshed with the Rust devs on occasion. :P
Then again I also understand that because the language changes and evolves, maintaining more code in the docs means more effort. However, this is one of the few things I've felt bugging me as an end-user. Of course I believe this can be expected to change for the better in the future as the language matures and stabilizes, but I figured I'd voice this out given this perfect opportunity. :)
C++11 added many changes intended for "do-it-yourself" crowd, like auto, new function syntax, lambdas. It didn't add much in terms of "let the compiler do the work for me" crowd (one notable exception being variadic templates, something that was in my own XL programming language since 2000). In C++, you are still supposed to do the boring work yourself.
For example, C++11 still lack anything that would let you build solid reflexion and introspection, or write a good garbage collector that doesn't need to scan tons of non-pointers.
If you want to extend C++, it's just too hard. C++11 managed to add complexity to the most inanely complex syntax of all modern programming languages. Building any useful extension on top of C++, like Qt's slots and signals, is exceedingly difficult. By contrast, Lisp has practically no syntactic construct and is future proof. My own XL has exactly 8 syntactic elements in the parse tree.
So in my opinion, C and C++ are already left behind for a lot of application development these days because they lack a built-in way to evolve. If you are curious, this is a topic I explore more in depth under the "Concept programming" moniker, e.g. http://xlr.sourceforge.net/Concept%20Programming%20Presentat....
Earlier quoted context omitted.
You certainly could define some basic things to make the language safer. For example, make variables always be initialized to zero if not explicitly initialized, and force accessing beyond the bounds of an array to be a fault rather than undefined behavior.
Initializing variables to zero doesn't buy you much in terms of safety, IMHO. The value 0 isn't necessarily any more valid than an arbitrary value. Better is Java/ML/Haskell's rule whereby variables must be explicitly initialized before use. This can be implemented with a simple compiler pass.
If 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…
Citation needed. This is a wishful thinking idea that ignores tons of pragmatics in application development.