Slashdot Mirror
Comparing the C++ Standard and Boost
Nerval's Lobster writes "The one and only Jeff Cogswell is back with an article exploring an issue important to anyone who works with C++. It's been two years since the ISO C++ committee approved the final draft of the newest C++ standard; now that time has passed, he writes, 'we can go back and look at some issues that have affected the language (indeed, ever since the first international standard in 1998) and compare its final result and product to a popular C++ library called Boost.' A lot of development groups have adopted the use of Boost, and still others are considering whether to embrace it: that makes a discussion (and comparison) of its features worthwhile. 'The Standards Committee took some eight years to fight over what should be in the standard, and the compiler vendors had to wait for all that to get ironed out before they could publish an implementation of the Standard Library,' he writes. 'But meanwhile the actual C++ community was moving forward on its own, building better things such as Boost.'"
There, I've said it. It's obscuratist beyond all reason and results in incomprehensible code of the type that any professional programmer should be ashamed of.
what are the odds.
instead of verbose vagueness need to have lists of comparisons between standard libraries and boost. is this author practicing to be paid by the word?
I just cannot embrace the mess C++ became anymore. Life is too short to learn C++. Basically I'm using "C with classes" today, without STL, Boost or any of these aberrations.
"... unzipped the .hpp files span 9000 files and 90MB."
Do you even lift?
These aren't the 'roids you're looking for.
We had decent (not perfect) C++ support. Now we go and fragment the industry by inventing a new standard. Code developed to the 0x11 standard won't work on legacy systems with legacy compilers.
Meanwhile boost and Qt worked around the C++ limitations without introducing any compiler differences. I think that was the right approach. True not all things could be delivered without messing with the compiler, but a good many were.
Now my only problem is that Qt (the leading C++ library aside from stl) and boost are not compatible. Boost has the more permissive license, but it is its own license, and boost additions can be under their own license. The Qt library is now LGPL (or commercial), and as of Qt5, Qt is divided into even smaller modules.
I hope the community does not fork again (C++ vs 0x11) with boost vs Qt. I cannot decide whose library should be adopted. But whatever comes to pass, I hope either Qt adopts boost or boost adopts Qt, to prevent further fracturing of C++ community.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
If you wait for another decade to come up with an update to the standard, you'll find even more independent libraries and implementations. People need to solve their problems now, they can't wait for somebody else to decide what to include into a standard. Example: a native string object must exist in a language of 21st century, so must a list, a set and a map.
You can't handle the truth.
boost::asio::wew::hew::fuck::you
I don't consider myself a "professional" programmer, though I've certainly programmed things that are used in my workplace, saved quite a lot of money for employers by doing so, and programmed things since I was a child on any number of languages. If I see a program and can't work out how it does what it does, I'm quite happy to tear it apart just to see how they did it, and even - when source isn't available and reverse-engineering isn't practical - re-create my own version to see if my hunches were right.
C++, to me, is just gibberish. I sat and read any number of books on how great OOP was and how C++ use these things and I have to admit, for many years, I was convinced. It was only when I got out of contrived examples and tried to understand another programmer's code that I realised that - actually - C++ just gets in the way. Boost even more so. I'm sure there is a way to make it lovely and I'm sure if you do it day in, day out and nothing else, that you get used to it and begin to see it - like reading music or anything else.
But a programming language is a LANGUAGE - something that facilitates communication. That's not *always* just between the computer and a human, but between two humans using computers, for instance. And there, C++ really falls down. I've seen projects that were created in C, built up in C, got famous in C and then converted to C++. I followed everything in them, even sending patches and hacking my own code into them, right up until they converted. And then they became a mess that I didn't like to touch, and certainly couldn't contribute patches to any more.
I get a lot of flak for that opinion, but I can write C99 code that does just about anything I ever want. I haven't yet thought "What this really needs is C++". I've even re-created object-oriented concepts in C99 and been perfectly happy with how they work and how to understand them.
And the fact is that a random bit of C99 code posted by a decent programmer - you can normally get the grasp of it quite quickly. A random bit of C++ code? You could be there forever checking overloaded operators and class declarations to see what the hell it actually does. Sure, you can obscure code in either language, but C++ seems to go out of its way to make even simple concepts obscure when expressed within it (don't even get me starting on templates).
I'm just not sure that the effort of "learning" C++ inside-out to the point where all that gibberish just becomes second-nature is actually worth it for the return, compared to just working a little harder on some basic C99 code to do the same things.
But the day I walked away from C++, Boost and MFC (mutha fucking classes) and joined a C# .Net shop was the happiest day of my life. Slam it all you like, but for UI development, Boost and MFC /Win32 is the worst platform to develop on unless you are a clueless sadomasochist that enjoys pain and suffering.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Metaphorically speaking, are you concerned about a future where everyone can assemble a house with prefabricated parts, but only the smallest minority know how to fabricate the parts? I fear as more high-level programming language jobs are created as entry level positions people become increasingly reliant on an entire layer of software they don't understand. Does that mean someone should have to know how to write a video driver to write a video game? Well, maybe. I don't know.
Help fight poverty: Punch a poor person.
Just ask Phil Greenspun.
It's obvious that both Boost and C++ come mostly from an academic environment. In a sense it's very general, but this makes it sometimes hard to apply to practical problems. For example, try to create a random number from 0 to 1. Any other language has a function for that. Not so C++, here you have to create two objects before you can generate a random number. Which makes it more versatile, but also more cumbersome. Same goes for the reference documentation: mostly incomprehensible because of all the template arguments, and a library is only as useful as it's documentation.
Boost and MFC /Win32
Agreed. Writing GUIs in C++ isn't that much fun, and GUI logic doesn't need the theoretical performance that C++ could give anyway. Just because C++ is not the right tool for every job does not mean that it is intrinsically bad.
Like all pain, suffering is a signal that something isn't right
The problem with your C99 comparison that, by comparison, a random bit of C99 code does trivial things described in great detail, whereas an equivalent bit of modern C++ code is able to execute orders of magnitude more business logic. Don't get me wrong: C99 is great for close-to-the-iron bit twiddling and severely resource constrained execution environments, but C++11 is able to offer equivalent performance, the ability to tackle complex problems and vastly greater expressiveness.
There is of course one major caveat: C++ requires more experience of the programmer to produce maintainable code. Otherwise, you are even more likely to end up with unmaintainable gibberish than you are in C99. But against poor programmers the gods themselves debug in vain.
boost.function, boost.asio, boost.optional, boost.foreach, boost.shared_ptr, boost.ptr_container
start using those libraries (at a minimum), and C++ coding starts to become as easy as scripting. Of course, you'd have to learn C++ first.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Actually, not re-inventing wheels is a virtue of the better programmer. There's enough dust to bite into apart libraries already written. It's tempting to have all source 'under your own control', it's also highly unproductive and a source of bugs and portability issues.
Is your problem with C++ specifically? Or are are you having trouble getting your head around object orientation? And no "re-created object-oriented concepts in C99" isn't real object orientation.
Have you actually done much with another real OO programming language? Java, Objective-C or C# for example?
Computer languages are meant to be read and written by people, yes. Your complaint, however, that "C++ really falls down", coming from someone who admittedly doesn't know the language and library, is a bit like me complaining that "French really falls down" when I haven't bothered to learn French. Or that idiomatic English constructs like "I couldn't care less" (which means exactly the opposite of its literal meaning) imply that "English really falls down". I can't read Lisp well ... but I don't have the temerity to blame its impenetrability to me on Lisp being a bad language.
Most of the projects I'm involved in use C++ because it excels at helping us to control the complexity of the massive applications we write and use every day. If we tried to write that code in C, we'd be rending our garments and gnashing our teeth. Use the right tool for the job. C++ isn't the right tool for every job, but neither is C or Python or any other computer language.
Unfortunately you simply don't understand C++ and how great it is. Of course you're not alone, most C++ programmers don't understand it either which is why so much bad C++ code is written. Maybe you've just been unlucky and only seen bad code. I have asked people with C++ on their resumes to explain to me what 'virtual' means and the success rate is 50%.
This should help
No colour or religion ever stopped the bullet from a gun
Fair warning: I program but am not a "programmer". That is to say, I have educational background in object oriented programming, STL constructs, and design patterns, but I'm not a software engineer so it doesn't get used much. What does get used is C, because in embedded systems it come sup quite a bit.
The issue I have with any argument about which tool is better is that the problems solved by C++ don't come up much for a large swath of problems, but they come up constantly for others. If the object-oriented version of your design would ultimately involve one uber-object, you shouldn't take an object oriented approach. If you're going to managing a lot of moving pieces in real time, you probably do want an object-oriented approach. If you want to tightly specify behavior at compile time so you know it will behave as expected at runtime, then templates are a good tool for bolting together well-tested parts to get a reliable new part. (When you're working with templated classes and methods, what you're really writing is a specification. You're not doing immediate work, but when work comes up you can put very tight bounds on how it is done. It's a different mindset than many other aspects of coding.)
Complaining about the lack of shiny new features in C/C++ is a lot like complaining that your MCU doesn't support an assembly STRCAT command, or that your Ethernet cable is bad about recognizing lost data and requesting it be re-sent. That's not their job. That's a higher-level problem for higher up in the stack. Trying to force features against type like duck logic only weakens the tool. When it rains don't ask your hammer to be an umbrella, use the hammer to build a house. Yes, that means you will often use non-C/C++ language to roll out an application. It also means that you need appreciate when those non-C/C++ languages create more trouble than going back to a rock-solid bit of C code would. Use the right tool for the job.
So how do you create generic arrays in C99?
By using #define's?
That's the way we used to do it, but thank heavens, we have templates now.
Yes, C++ is a mess, but please don't tell me that C99 is everything.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Nice try, Steve Ballmer.
na, you just haven't understood the language, that's the problem.
I would recommend starting with "C with classes" to get started, and use a C++ compiler so you can use the STL collections like map and list. (no more writing your own list class!)
C with classes is a great way to start getting into C++, instead of your usual 3 functions, init(), dowork(), and close(), you migrate those into functions within a class - just wrap them with class MyClass{ } and you're nearly there. Then rename the init into the class constructor, and the close into the class destructor... and your program stops being
and becomes
that's it. init and close stuff are handled automatically, and within scope rules so you no longer need to worry about when to call close, as will happen in more complicated programs. Once you get this concept, the rest will come easily. Its no more difficult than grasping the concept of pointers you had to do in order to grok C.
, or whatever, which is much shorter, less code for your to screw up and almost certainly bug free from being used/checked by thousands of others.
C code doesn't have to be procedural. You can implement classes and objects and what's more, you can actually understand how they work when you do. You can create just about anything you want (not everything, but very near.) You'll know what you are writing. You won't be including incredibly overweight code that bloats your app and slows it down. You can manage memory intelligently, you can construct very maintainable code, and you can be quite concise about it.
What you're running into, I suspect, is programmers that aren't experts in either C or OO. They know how to use the bits of OO that C++ "cans" for them, but if you told them to build such things... C++, like any HLL, has its place holding the hands of mediocre programmers, and also in empowering truly excellent programmers. But C is enormously capable and from my personal experience, it's hugely more maintainable, less verbose, and more to the point than C++ simply by virtue of the fact that the language space is much smaller -- only as large as it actually needs to be, with very few exceptions. A true object can be built in C without any of the cruft or "mommy" limits; it can be highly efficient in terms of both memory used and execution time. It won't end up being megabytes just to get a basic UI going.
The amount of "stuff" a programmer needs to know about a language gets in the way of the amount of "stuff" that same programmer needs to know about programming techniques in general and the specific task(s) at hand.
Every once in a while, I have to write in C++. I'm pretty good at it -- experts in C tend to have a good basis to add C++ concepts on top of. I even enjoy it. But contrary to your experience, I have found that most C++ code I have to deal with from others is very bad from the POV of maintainability, bugs (and they get a lot more obscure) and in being much more verbose (just a typical C++ header file makes that point rather well, without even getting into code.)
The worst thing I run into is the assumption on the part of OS documents that you will be writing in C++; pretty soon, you have to capitulate and get the C++ written, just so you can interface with the bloody system. All of a sudden, you're pulling in huge chunks of code you never heard of and have no interest in, and you have a form of the classic many-megabyte "hello whirled" program. Ugh.
I've fallen off your lawn, and I can't get up.
Some of your requests will never happen, and with good reasons, I'll explain:
e) Fix the macro language so it is type safe
The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
16/32 characters are fully supported in c++11, see char16_t and char32_t. I could be wrong, but I don't think I've seen a language which has 24-bit characters. It would likely be inefficient to support anyway since I'm not aware of any architectures which 24-bit access is properly aligned.
i) Fix the darn grammar so that compilers accept UNICODE source
Many compilers already do support UTF-8 in source code. But I do agree that this should just be standardized across the board.
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
NO. You will probably disagree, but this is part of the *strength* of both C and C++. By allowing something to be undefined or implementation dependent. The standard is allowing the compiler to choose the most efficient code to emit. If the standard were more specific in these places, we'd have a "one size fits all" solution which would be optimal for some architectures and very much sub-optimal for others. Better to let the compiler writers who know the arch best to decide these things.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
When is C++ going to add reflection support?
It probably won't because it's not well suited for how things work in the language. Here's (part of) the problem. With templates and optimizations, often there can be 100's of types created during compilation which are independent but get optimized away to literally nothing when finished. Should the compiler waste time and space generating reflection information for types which simply don't exist at runtime? Should the compiler emit reflection information for each and every template instantiation of std::vector that your program uses? You can't do one set of reflection's for each template, because different specializations can have different members! It spirals out of control really fast. Personally, I would not be apposed to an opt-in reflection system. You use some special syntax, let's say:
reflect class T { };
or something like that. Which would then add extra stuff to the std::typeinfo object associated with that type. So that way you could in theory do something like this:
typeof(T).methods(); to get a list of methods for T, IF you have opted in. But I don't think that will happen.
You can get that same warm feeling by writing good code in C, assuming only you have the skill to do it. Furthermore, when it is useful and appropriate to step outside the paradigms that C++ would force on you, but you can choose to use in C, you can. You'll understand why you did it, what you saved or cost yourself by doing it, and it won't be buried underneath some ridiculous, time-and-space wasting get/set layer, etc.
Not saying C++ is bad. Far from it. But I am saying that C is fully capable of supporting strong, highly correct programming, and that if C++ restrictions (or those of any other language) are the source of your feeling of having "done it" correctly... it's very likely there's more basic programming landscape for you to explore.
I've fallen off your lawn, and I can't get up.
The narrow niche would be most graphically intensive software. Which wouldn't be that narrow.
With libraries like QT, it's also quite handy for Desktop Apps and you can easily prototype in python (via bindings PyQt or PySide).
I still go back to the problem of programmers going at things the wrong way. The problem is that there are so many ways in c++ that you discover after years that you still had better means of achieving things.
In that sense, languages that force style and other decisions upon you (like Python or Go) will continue on the road to success and major adoption.
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.
How do I create generic arrays? I don't, because I don't use generics when I'm not required to. Aside from contrived examples and Thou Shalt coding standards, I've never actually needed a generic. Hell, the codebase of the project I'm working on now is Enterprise-y Java, with generics everywhere, but you know what? There is never a single place in the codebase where objects have an undetermined type. Everything implements interface upon interface, but every situation that operates on generics is, in practice, only operating on one type. The codebase could be shrunk to about 80% of the current size simply by explicitly unwrapping the generics, which is pretty amazing if you think about it. It would also prevent all the pointless instanceof comparisons we do on both sides of the method call.
map and list etc. are great, but the error messages when you get some detail wrong are something to behold. It's as if someone wanted to make it hard to keep their jobs.
Nullius in verba
There has been some uptake in C# usage. Even more significant is Java is now back as king-of-the-heap (at least according to TIOBE). I put this down to two factors: enterprise projects deferred in the worst part of the recession now need to be implemented, and: not only does 'Java' include Java-the-language, it also includes Groovy (good for those who like the dynamic language tightrope walk) and Java-for-Android.
While C# has some very nice language features it can never make up for the fact that fundamentally it is single platform (the Mono project won't/can't implement some important libraries that would make codebases truly cross-platform, as stated by Mono's own project page).
I'm always amazed how many still prorgram in C++. After developing in it for around two decades I am glad to leave it behind except for some specialist embedded work - which is becoming increasingly unnecessary; with 32-bit systems on a chip you can use real Java and Linux to develop more complex [eg. multi-threaded networked] apps in a quarter of the time.
If C++ or C# is your preferred language then that's cool. However, if you want to get complex apps out the door as quickly as you can that utilize of lots of the modern multi-core processing power available then it is very very hard to go past Java or Groovy or any of the cross-platform languages that now run on the JVM (eg. Scala). C++ is going nowhere because it adds unnecessary complexity to solving your problem (except in cases where your available memory is measured in kilobytes; which is very rare these days). Those who still program in C++ may do so to show off their programming credentials - but they are missing the point of good design: get your app out the door as fast as you can (with as few defects as possible, which is easy given the JVM instrumentation and the fantastic JVisualVM). Oh yeah, the combination of smart Sun/Oracle engineers, runtime profiled JIT, and easy use of multi-core means a properly written Java program will outperform most single-threaded C++ programs (multi-threaded programs in C++ are less common than in Java due to the pain of using the third-party C++ resource and thread management).
While I agree with you on the whole that Microsoft is quite adept at killing things, and that one of their sharpest tools is in fact getting people to use their software, I think you'd have a pretty difficult time getting actual competent people to do so.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this.
Do you know why not? This seems like such a simple operation.
Give me Classic Slashdot or give me death!
You are joking, right? Graphically intensive programs use OpenGL/GLSL and don't do it in software. Only a shitty designer chooses C++ to do graphics *in software*. I'm writing a modern multi-threaded jet combat flight simulator in Java and find that Java has several huge advantages over C++: muti-threading and in-particular multi-threaded resource management is easier in Java than C++; my development time for pieces of work is much faster than when I used to use C++ for development; I have much better tooling (I *love* JVisualVM, that comes with the JDK); with judicious use of libraries (eg. JoGL, Input, JOAL) my simulator is already cross-platform (Mac, Linux, Windows, and soon Android) with little extra effort; the runtime performance is fantastic, I'm never CPU bound because it is easy to be multi-threaded and use all the core available (modern multi-core CPUs are so powerful the GPU is always the bottleneck on my sim no matter the age of the CPU).
But let us pretend you are not doing a high-performance 3D app (where muti-threaded Java+JoGL+OpenGL kicks C++'s ass in development time) and instead want to do plain 2D. Then you can use the Adobe-designed Java2D API built into standard Java. It has very many 'advanced' features (convolutions for filtering/effects; affine transforms; easy gradients; font manipulation; composition operations; image i/o in lots of common formats etc.). Using the usual fantastic abstracted design of Java the implementation of Java2D was swapped from software to hardware in 2008. That means *all* the graphics you do with Java2D are hardware accelerated using DirectX on Windows and OpenGL everywhere else (and you don't have to change any lines of code for your graphics program to work pretty-much-seamlessly between platforms). With Java2D you can also mix with JoGL/OpenGL 3D very easily (I use this to provide 2D transparent overlays for in my 3D simulator; it is very easy to do).
This is why Java developers are astonished people are still using C++ believing it has better speed for things like graphics. If you are doing graphics in software in C++ then not only are you not hardware accelerated like Java2D, you also have more work to do to get/maintain cross-platform, have a hard time being multi-threaded to use all the CPU cores you have, and your development time is much more frustrating (easy to have macro/template issues in C++) and takes much much longer to produce something working, tested and stable. If you are still choosing C++ over Java for graphics performance you are half-a-decade out of date (eg. bad at architectural design and bad at business; since it takes more time to develop with C++, which means the same functionality costs more money).
So if you are doing graphics in C++ believing it is speedy I suggest you take a look at Java2D and JoGL (for 3D). A good Java graphics developer can make very very fast *hardware accelerated* graphical programs in little development time.
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
I agree with most of your points, but I can't really agree with your logic on these. Hardware floating point support wasn't common until the 486 days. A lot of lower end CPUs used to omit support for division. That didn't stop C/C++ from including support for those features.
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it. They were probably left out originally to keep things simple in the early days of C. Now the standard committee seems very hesitant to make changes to the syntax of language, so they probably just look at these things as nice to have but not worth changing syntax over.
The Boost guys seem to be grinding some sort of axe with respect to the FSF. All over their site are little digs about how awful the GPL is, etc. The benefits of various licenses are open to question, of course, but their little snipes just seem unprofessional.
Also, bjam. If you have to write your own make replacement just to compile your code, you're doing it wrong. Ugh.
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
I think if you asked people how big a short or long is, 99% would answer it's a fixed size and of the 1% that in theory knows it's CPU-dependent 99% of them don't use it to create any intentionally different behavior on different CPUs. The 0,01% that really use this could have something like a set of typedefs in a platform configuration file, while the other 99,99% won't get bitten in the ass by flawed assumptions that a short will always be 16 bit. Nobody but C/C++ has this ambiguity in their most basic units that are used in pretty much every example, pretty much all other languages, databases etc. have found it sane to define them exactly. Sorry, but this is a horrible part of C/C++ even if you happen to like it.
Live today, because you never know what tomorrow brings
How I have seen the phrase "I could care less" is as one with an implied clause beginning with "but" following it.
ie.... "I could care less [but then I would have to work at disliking it]" or something similar. Slight emphasis is implied on the word "could".
Taken by itself, literally, it makes no sense, of course.
File under 'M' for 'Manic ranting'
e) Fix the macro language so it is type safe
The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.
C11 introduced Generic Selection which allows type control in macros. Too bad C++ diverged so much from C.
Why do you use uppercase in the first function name and lowercase in the second function name?
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it.
Both the GP and you are wrong about this. Hardware support for exponentiation is completely irrelevant to it being a built-in operator rather than a function call.
FORTRAN, famously, has some extremely efficient tricks for implementing exponentiation by small integer exponents (up to 7, if memory serves) that are independent of MPU support. They are handled by the compiler. Why C/C++ doesn't have this is beyond me, and writing these things efficiently for a given architecture is non-trivial and better handled by the people porting the compiler than application developers.
Blasphemy is a human right. Blasphemophobia kills.
>When is C++ going to automatic garbage collection WITH the ability to tell the garbage system how many milliseconds you are allowed to use (inclusive from ZERO.)
And how exactly is that supposed to work? Garbage collection that's not allowed to run = no garbage collection, and you've just converted your program into one huge memory leak. If you want low-overhead "garbage collection" use smart pointers.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
C-like-C++ kinda combines the worst of both worlds.
At that point, I think you'd be better off using straight C (which I like a lot and think is the best tool for most jobs), or full C++ (which bugs me, but I admit I like the STL better than C collections).
b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,
I'm not quite sure what you mean here. Do you mean generate compiler/platform independent code (some IR like bytecode/LLIR)? Or do you mean ntoh/hton and the like?
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
i) Fix the darn grammar so that compilers accept UNICODE source
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Should both be fixed with C++11. Except 24-bit characters, which I've never heard of before.
k) Add a proper exponent operator
l) Add a proper wedge operator, along with inner and outer product operators
Seem rather special-cased here.
m) Add proper multiple return types
You can do this by returning a std::pair, a std::tuple, or a structure you build. However, I don't believe there is an easy syntactic way to split a pair/tuple into multiple local variables.
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
Never going to happen. Most of those "undefined/implementation dependent" items are features, and compilers take advantage of them to optimize code. It does make some quirky edge cases, but makes a lot of code optimization techniques in use today possible.
When is C++ going to automatic garbage collection WITH the ability to tell the garbage system how many milliseconds you are allowed to use (inclusive from ZERO.)
Do you know a system that does this max time? Because it sounds ridiculously difficult, and would lead to cases where a program would have to fail because it has no memory yet is not allowed to do a full garbage sweep/reclaim.
The problem with that C++ is not that you can't write simple code, but is that the languages makes it easy to write verbose bloated code.
I actually don't believe this is the problem with C++ - you can write verbose, bloated code in most languages. The problem I see is that C++ was made to be as strict a superset of C as possible, and inherited an audience who want full control of things like object size, and memory allocation/deallocation behavior. Because of this, generialized code requires way more knobs to be tweaked than you expect, and templates have evolved to be a hacked-together functional programming language to determine optimal operation. In order to generate an optimal, generic library you have to make the code itself incredibly difficult to maintain.
I am a professional programmer, who finds C++ to be very useful in larger projects. I have some idea how these would work in C, and it isn't pretty. C is simply a much less expressive language. It's great when you can afford to pay attention to all the details, and breaks down when they get overwhelming. For example, it's far easier to get memory management right in C++. Similarly, OOP is a very powerful tool when applied properly (and it would appear that you never saw it used well).
C++ is a very good language for competent programmers and medium to large projects. It's not a good language in the hands of the incompetent, as there's very many things that can be easily abused.
You've been looking at badly written C++ if you talk about "checking overloaded operators and class declarations to see what the hell it actually does". If you have to check an overloaded operator to see what it actually does, the C++ programmer has screwed up. Checking class declarations is much like checking C functions - if you can't get a basic understanding of what's going on from the names, the program is not well written.
As far as you're concerned, if you find that some basic C code suits your needs, and you're not a professional programmer, then it probably isn't worth it for you to learn C++. When the complexity piles up, and you no longer know where to write free(), C++ is there for you.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
>> a) Add a PROPER 'alias' and a PROPER 'type-def'
>Define "PROPER"
First, there are times:
a) When you _need_ strict type safety
b) When you _don't_ need strict type safety
Second, read up on C++ mangling/demangling because if you don't understand that you won't understand my point.
http://en.wikipedia.org/wiki/Name_mangling
Agner is a guru of assembly language and has written a great document; specifically the section "The need for standardization"
http://www.agner.org/optimize/calling_conventions.pdf
Here is the usage case where we want BOTH (a) and (b):
Does this make sense?
At least C++ treats SomeVoidFunc() and SomeVoidFunc(void) as being mangled the same now.
Don't even get me started on how C++ ignores the return type for the mangling! There are times when it would be _extremely_ handy to call a different function based on the return type. Sadly C++ lacks this.
>> c) STANDARDIZE the pragmas
>You've missed the point of pragmas.
And you've missed the pain and agony of having to support multiple compilers because the idiotic compiler writers were too SHORT SIGHTED to understand customers do NOT want proprietary vender lock-in having to support yet-another-compiler.
Do you understand the purpose of having a _common_ way to specify structure alignment and packing??
e.g. How you disable the compiler warning about "unused variables" in Microsoft Visual Studio, GCC/G++, Intel C/C++ Compiler, etc?
We standardized the width of train tracks for a REASON.
We standardized the traffic lights even though everyone drives different vehicles from 2 wheels, 3, wheels, 18+ wheels, etc.
As programmers we are forced to solve the same dam problem over and over in everyone's "pet syntax". When is this insanity going to stop??
>> d) STANDARDIZE the error messages
> Compilers differ. This might not be possible.
I'm not interested in political excuses. I
Yeah, I didn't catch that until I hit submit. :-/
Sorry for the inconsistent func names. :-(
>> b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,
> I'm not quite sure what you mean here.
This .pdf explains why this important:
http://www.agner.org/optimize/calling_conventions.pdf
Particularly: 3 Data representation
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
Because, when a function is not inlined, the ABIs for passing structures around are broken and usually force you to put the structure in memory, and only pass a pointer around. I mean, come on, on a 64 bit architecture you can pass a 64 bit structure right in a register. Most of those architectures have so many registers that passing 128 bits of a struct in two registers isn't out of question either. Yet, instead, all that you pass is a 32 or 64 bit pointer. Many compilers do not ever promote elements of a structure to registers, so even using a struct for automatic variables to make code more readable is a performance no-no. That's why making such performance-changing choices implementation defined and not standardized is a big back-assward stupid move. Yeah, it's "portable C" or "portable C++" but you can get wild performance regressions just because you use innocuous-looking abstractions.
A successful API design takes a mixture of software design and pedagogy.
It doesn't matter if all CPUs have it or not. Lightweight syntax hardly ever results in lightweight machine code, so it's a moot point IMHO.
A successful API design takes a mixture of software design and pedagogy.
"I could care less" is usually used sarcastically, but, as we are seeing here, many people take it literally and then complain about it without thinking what the actual words mean.
cf. "could of" - Try diagramming a sentence with that construction. "of" is a verb?
Using "suppose" instead of "supposed", as in "I'm supposed to understand my language well enough to use it correctly."
Think about what the word means in the context... then you realize "suppose" doesn't make sense.
You are in a maze of twisty little passages, all alike.
string fuck = "y" << "o" << "u";
Is more penetrating.
Views expressed do not necessarily reflect those of the author.
That's why so many commercial 3D engines are implemented in Java, not C++, right?
A good Java graphics developer can make very very fast *hardware accelerated* graphical programs in little development time.
That's because C and C++ code is doing all the real work behind the scenes.
I just did a string search in my large C++ project for template, and it's in 3 classes only. One is a generic event handling mechanism (quite powerful), one is a generic vertex template and the third is a cache friendly storage base class. Most people who are experienced C++ programmers don't use templates. They're used by library writers a lot, but talk of their over-use in production software is a bit of a fallacy.
I agree with this. C# is a joy to code with, especially the system libraries. Part of its niceness, in Visual Studio at least, is the way intellisense actually works. It's very hit and miss with C++ because of the complexities of nested header files and so on.
Strong typing? In C++? Did they completely overhaul the language when I wasn't looking? C++ is statically typed, and the re-purposed "auto" keyword certainly removes a lot of the annoyances that introduces, especially where templates are concerned - I assume that's what you're referring to. C++ is however still a weakly typed language - defining characteristics of which include implicit type conversions and ad-hoc polymorphism (aka operator overloading/function overloading)
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I have asked people with C++ on their resumes to explain to me what 'virtual' means and the success rate is 50%.
That's nothing, and actually it may very well be irrelevant to peoples' expertise with C++. In a prior job years ago, I participated in some phone interviews of contractors; we were looking for people who could do both Perl and C++ programming. I'm no C++ expert (and was even less so at the time, more like a junior programmer), but I made up some ridiculously simple questions, such as: "What is a class? Please describe a class and what it's for." The success rate on that question, for people claiming "C++ expert" on their resumes, was much less than 50%, probably less than 25%.
This doesn't show that C++ programmers don't understand C++ well. This just shows that there's a bunch of liars out there who claim to be experts in things they have zero experience or expertise in, just so they can get a job.
Of course, the last time I wrote this little anecdote on Slashdot, I had a bunch of people telling me that there's lots of perfectly good reasons a C++ expert wouldn't be able to tell me what a "class" is (just like an expert auto mechanic might not be able to tell me what a "piston" or a "steering wheel" is when grilled on it in an interview). Let's see what happens today.
There is of course one major caveat: C++ requires more experience of the programmer to produce maintainable code. Otherwise, you are even more likely to end up with unmaintainable gibberish than you are in C99. But against poor programmers the gods themselves debug in vain.
Back in the day, before C++ was so popular, people were perfectly capable of writing the most awful C code, full of leaks and pointer violations. Truly poor programmers do not let anything so trivial as a language get in the way of creating excrable code.
Also, I really hope said gods simply smite those programmers.
SJW n. One who posts facts.
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
It's been done the C++ way: add the generic tool, and natural uses flow freely.
e.g.:
tuple foo() ... ...
{
return make_tuple(1, 2, 3);
}
int a, b;
float f;
tie(a, b, f) = foo();
And with move constructors, it's efficient too!
SJW n. One who posts facts.
Is this a joke? You're making a real-time flight simulator in Java instead of C++ because your actual *rendering* is hardware accelerated and threads are easier in Java? You do realise that the unit of parallism on your graphics card is the *warp* (a bunch of pixels), not the driver, don't you? It doesn't matter how many threads you throw at the problem, the driver will mutex your concurrent calls to hell and it won't be any quicker.
Worse, you have no fine control over cache line efficiency in Java, which you do in C++, so it's probable your multiple threads will give the appearance of maxing your cores, but those cores will actually be sitting waiting on a cache line most of the time. I've seen a "multi-threaded solution" running on 6 cores that was only 1.5 faster than a single core solution because of this. If you want performance, C++ gives you the tools to make your code performant. Java abstracts all of that stuff away so you have no control over it. This is why C++ isn't going to die any time soon. Developers at the bleeding performance edge need it too much.
Actually, they *are* part of the language:
the standard specifially allows C and C++ to do "weird shit" (ok not eh actual wording) with standard library components if it wishes. That very much includes pow and things like memcpy, etc.
Check the asm to see what's been emitted: gcc has lots of special things for standard library functions.
But yeah, I don't see why an overload for ^ and floats couldn't be included.
SJW n. One who posts facts.
You can do this by returning a std::pair, a std::tuple, or a structure you build. However, I don't believe there is an easy syntactic way to split a pair/tuple into multiple local variables.
std::tie, as in:
int a, b;
tie(a,b) = make_pair(1,2);
Works for tuple as well.
SJW n. One who posts facts.
Because C++ is not intended as a mathematical expressions language? Such things belong in a library. Or you could allow any UNICODE operator to be an operator and support infix and postfix method invocations/operator definitions. But then you are moving into different-language country...
Bzzzzt. Use of Qt presumes some sort of GUI. Not all applications need a GUI. Why would a loader need Qt? For the puzzled, a loader is /lib/ld.so* and is the key bit of code which manages where your application sits in Virtual Memory, along with the statically bound dynamic libraries. For general application developers, It is something well beyond your capacity to understand, so stick with your burger-flipping.
C++ is however still a weakly typed language - defining characteristics of which include implicit type conversions and ad-hoc polymorphism (aka operator overloading/function overloading)
Ad-hoc polymorphism is not the same thing as operator & function overloading, although the latter two can play a part in it. In any case, ad-hoc polymorphism does not enter into the picture in C++ unless and until you start writing class and function templates. Any non-template C++ code is strongly typed.
FORALL X, most programmers writing in/using X don't understand X.
(this is true for languages, frameworks, libraries, and practically anything else that can be conceivably used in programming)
This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation.
Riiight. Every time I mention that as a big disadvantage of op-overloading, I get just ignored or called stupid to not see how great op-overloading is.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Are you sure? Perhaps I need to refresh my language-property vocabulary, it has been a while since it got much use.
Implicit typecasting though most definitely conflicts with strong typing, and is buried deep in the guts of the C++ spec. For virtually all built in non-pointer types
Foo(int x); // valid = weak typing
void main(){
bool c;
Foo(c);
}
And for classes (though it does default to pseudo-strong typing) // implicit A->B typecasting // implicit B->A typecasting ...
class A {}
class B{ public:
B(const A&);
A operator A();
};
void Bar(B);
A a;
Bar( a );// valid
I might have some syntactic details wrong for the B->A line, been a while since I used it, but the point is it exists. Moreover the A->B implicit typecasting is the default behavior unless you remember to specifically disallow it with "explicit" - can't tell you how many bizarre errors I've traced back to that oversight. Which is exactly the point - strong typing gives you certain guarantees when analyzing code for correctness, and C++ doesn't provide those guarantees.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Such things belong in a library.
Of course, there's no contradiction with it both being a built-in operator and being in a library. typeof, anyone? But, of course, then the naysayers would just complain that C++ is even more bloated.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
You're being too vague. Some things mathematical belong in a library, eg the special functions or even exp and log. However, the C++ language explicitly supports the elementary mathematical operations of addition, subtraction, multiplication and division. Exponentiation is clearly a natural and very simple iteration of multiplication and therefore optimizing it falls in the purview of the C++ language. It is no different than eg optimizing a loop
int i = 0; while(i < 10) i++; // same as int i = 10;
I don't particular care about C++, but despite NOT being an American - or, for that matter, a native English speaker -, I'm completely opposed to Unicode characters outside of comments and strings.
It's exactly because not everyone uses the same language that we should standardize on a limited subset, and ASCII is the most common and well supported of those, and also part of the de-facto International Language (English), which any decent programmer has to understand, at least minimally.
And by the way, that you can't use $ in your variables has nothing to do with Unicode support, of course.
Dilbert RSS feed
I actually just had to utilize unsigned shorts the other day. I've got a file with a header every 1024 bytes and I have to modify an unsigned short in that header. The file can be several gigabytes so it kind of makes sense just to skip to the first header, write the short, and then skip forward every 1024 bytes thereafter and set the header until I reach the end of the file. The last guy seemed to think it'd be OK to read the entire goddamn thing in and write it back out again. On slow NFS. With Perl.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
That's why there's stdint, and that's why it's recommended to use it. Use int32_t and the like for types that should be a certain size, use size_t for platform-specific, and arguably it's still ok to use int when you really want the natural integer type for the platform and it's doesn't matter how many bits.
Thanks for your comment. I'm afraid I must have been unclear. The multi-threading is for all the non-rendering tasks. On 8-cores none of them get above 20% usage, which means there is very low jitter in the frame rate (which is the critical fact in what users notice). The rendering is all deferred and is not done of the CPU at all (aside from the commands to submit textures etc already in VRAM).
This is why C++ isn't going to die any time soon. Developers at the bleeding performance edge need it too much.
I agree with you. C++ is great for some niches. That niche is smaller and getting smaller. What I was saying is that for an application that is far more intensive than most (a multi-player combat flight simulator with realistic flight modelling etc) the extra development time of C++ is not worth it. For most applications C++ is not worth it. For some it is - but these are fewer than most people realise (especially many C++ proponents whose mental model of Java's speed is at least half a decade out of date). Java should be your first choice for implementation, only if you have niche requirements would C++ be worth it.
Are you sure? Perhaps I need to refresh my language-property vocabulary, it has been a while since it got much use.
Yes. Any sort of type polymorphism is when a given single piece of code can operate on values of different types. "Ad-hoc" specifically refers to the fact that it is not type checked in any way - i.e. the language does not restrict what things you can do with the types, but lets you do anything that sticks, with either compile-time resolution (as in C++ templates) or run-time resolution (as in duck typing as seen in most dynamic PLs). A polymorphic function in, say, ML is not ad-hoc because you can't call random functions on something that's just 'a - it won't type-check.
Implicit typecasting though most definitely conflicts with strong typing, and is buried deep in the guts of the C++ spec. For virtually all built in non-pointer types
I wouldn't call either of your examples weak typing - both are implicit widening, in that they pass a value of a subset (e.g. a subclass) where a superset is expected; remember that C++ bool is defined as just an integral type with 0 and 1 as the only two valid values. So there are no correctness issues here, and LSP is satisified.
Now the fact that it'll implicitly cast double to int, or int to char, is more damning. But that is pretty much only the case for numeric types; all pointer and reference types, as well as all aggregates, are fully sound, and won't implicitly convert unless you make them (by introducing conversion operators). And most C++ compilers will warn about implicit narrowing conversions, and all sane C++ programmers compile with warnings-as-errors.
> That's not a downcast.
If you wish to be pedantic, yeah, technically it is an automatic-demotion. C/C++ will also silently do automatic-promotion to doubles. i.e. printf().
> Implicit signed to unsigned casts can be much worse
Agreed.
Is there a better way compilers could catch the mistake you gave? IIRC some languages (usually functional ones) have design-by-contract that (force?) allow the user to specify the valid ranges and do range-checking at compile time.
Most C/C++ compilers will warn about signed/unsigned comparisons these days, usually that is enough to catch the mistakes above.
>ad hoc
Okay, you got me questioning myself so I looked it up and every source I find disagrees with you. From http://en.wikipedia.org/wiki/Ad_hoc_polymorphism
In programming languages, ad hoc polymorphism[1] is a kind of polymorphism in which polymorphic functions can be applied to arguments of different types, because a polymorphic function can denote a number of distinct and potentially heterogeneous implementations depending on the type of argument(s) to which it is applied. It is also known as function overloading or operator overloading. The term "ad hoc" in this context is not intended to be pejorative; it refers simply to the fact that this type of polymorphism is not a fundamental feature of the type system.
So for example in the following code Foo is polymorphic, naming three unrelated pieces of code where the specific implementation invoked will depend on the invocation context. It's a concept almost completely unrelated to polymorphic class hierarchies, and in the presence of implicit type conversions the two types of polymorphism can interact in some extremely ugly ways if you're not careful.
void Foo(int i) {...}
void Foo(Apple a) {...}
void Foo(SomeBigDataStructure& s) {...}
>implicit widening
Not at all, notice that there was no inheritance in my example. let me try a less generic example to be more clear:
class Bitmap{
Bitmap(int initial_buffer_size);
};
void Draw(Bitmap);
elsewhere... // perfectly valid - 7 will be implicitly typecast to a Bitmap
Draw(7);
I hope it's obvious how in a more complicated scenario that could cause some really well-camouflaged bugs of a type not possible in a strongly typed language.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
It's really just a matter of semantic quibbling. Arguably, the identifier "Foo" in your example is polymorphic, in that it's bound to three different functions, and which one to use is chosen depending on the type of argument. But none of those functions themselves are actually polymorphic, because all types are fully defined in the body of each one.
Your example with the class is not an example of weak typing, it's an example of a user-defined implicit conversion being applied. Yes, it is not readily obvious that any single-argument constructor defines such a conversion, but that is a syntactic clarity issue, not a type system issue - if, say, the default would be explicit, and there would be a keyword like "implicit" to specify otherwise, it would be a purely syntactic change with a simple one-to-one transformation, not a semantic one.
Then again, the whole concept of "strongly typed" vs "weakly typed" is really blurry. There are some languages that are obviously one (Haskell) or the other (Rexx, Tcl) - but for most of them, it's hard to tell for sure. Is Java weakly typed because you can add an int to a string? Is SML weakly typed because + is overloaded for ints and floats? Is Python weakly typed because its "print" will accept a value of any type and do something useful with it? I find it to be a classification that's too murky to be actually useful - as opposed to, say, static vs dynamic typing, which can be precisely defined.
The funny thing is - decision to use particular language or tool which is done at the beginning of a project or new product line is done by the evil gurus i.e. those that do not know how to work in big teams and organize things efficiently. So what you write is correct. C++ will allow you to do things you can do in other languages in very convoluted way only in C++ your average developer cannot or does not want to do it in not convoluted, maintainable way because that would not be glorious and we are into C++ for the glory of it - right? This is the attitude prevalent in C++ community to the point that makes me puke when I have to go to work in the morning. The theoretical gains the language gives are nothing if they are offset by malpractice and incompetence (this being social as well as in engineering and organisation). Why bother then? I think any reasonable project managers (do we still have some) should think twice if s/he has a choice to use glorious tools or tools that his/her team can handle.Theoretical benefits are exactly this i.e. theoretical unless your team can produce code that shows them to exist and that is sadly not the reality in majority of cases.
Java can't be your first choice for implementation on the desktop. It is a single-vendor product with an uncertain future.
False. There are numerous implementations of Java: Oracle/Sun; OpenJDK, IBM, GNU GCJ+CLasspath; Apache Harmony (for libs); Kaffe; etc etc. You couldn't be more wrong. It is suprising you posted something that is so obviously false.
It isn't supplied with the major desktop OSs and many users would pick a native over Java app if given a choice.
Mostly false. All of the Java desktop apps I've supplied have been trouble free installs for users that looked better than their native counterparts (especially using things like the Nimbus theme and 'filthy rich client' Java2D hardware accelerated effects for nice aesthetics). My apps also perform very well since multi-threading (particularly resource management and object lifecycle in a multi-threaded environment is much easier in Java than C++) Given the fact that most native apps don't look like each other it is no suprise that users like Nimbus (and now JavaFX) interfaces (consider how different that newer versions of Microsoft Office look from their predecessors, yet users can cope with this). Your argument are a decade and a half out-of-date. It is clear you don't know much about modern Java at all and are just parroting anachronistic falsehoods. Time to see the new reality - after a long time computing is getting more hereterogenous, not less (both in terms of operating system and hardware eg. x64 vs ARM etc). The best technology to use is that designed to be platform neutral and Java is fairly unique in having that as a central design goal (not only for the language, but also for the huge number of standard libraries). Haters are always gonna whinge about Java (especially if they believe the bullshit Microsoft markering pumped out from a decade ago to keep you locked on Windows) - however, the Java devs are quietly getting on with solving problems once for all systems (rather than re-inventing for each target system) and *making money* through wisely choosing long-lived platform-neutral technology.
People who wrote code which smoothly made the transition from 32-bit to 64-bit w/o requiring a rewrite yet was still able to take advantage of increased width don't think it was a waste. Or whose portable code can work on a desktop machine with 8-bit bytes, or on embedded DSPs with 16-bit bytes....
What exactly do you mean by take advantage?
Do you just mean that, in well-written C, an increase in bus width is only ever a good thing, and at the same time it enables efficient DSP code?
In, say, Java, moving to 64 bit will have no effect on program semantics because of the fixed-sized primitives (i.e. unlike C, it just about guarantees you won't see any new bugs from the transition), but might enable one to take advantage of a larger heap.
There's also the non-trivial matter of
People who wrote code which...
which certainly isn't all C programmers. Reflects C's unusually pro-performance design, I guess. Interestingly it looks like the D programming language has no support for C-style CPU-dependent primitives, only fixed-sized.
are you concerned about a future where everyone can assemble a house with prefabricated parts, but only the smallest minority know how to fabricate the parts?
I'm concerned with a future where the parts cartel controls access to parts by adding organizational requirements for use of their parts that discriminate against students, amateurs, home-based businesses, and various forms of lean startup company. In some parts of the software industry, this has already happened *cough*games*cough*.
Bzzzt.
None of QtCore, QtSQL, Qt Network, Qt...need I continue? Only QtGUI presumes a GUI. QtCore is just datatypes, of which they have advanced storage classes and signals and slots (and event loops) and threading.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
i) Fix the darn grammar so that compilers accept UNICODE source Many compilers already do support UTF-8 in source code. But I do agree that this should just be standardized across the board.
This is implementation-defined in C++11, a compiler could in theory support multiple input types, see ISO 14822:2001, S2.1.1 and S2.3.
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.
This is required in C++11, see S2.11, Annex E.1 for allowed codepoint ranges, Annex E.2 for initially disallowed codepoint ranges (this is in addition to the ascii nondigit & digit rules). After the initial translation, pretty much all subsequent internal compiler work is done with UTF32.
"Two, the junior programmers (and even the senior ones you know who shouldn’t have been promoted) are less likely to make the same old mistake of writing things like for (i=0; i=length;i++) and then ask you why the code seems to sort of work some of the time, while other times it crashes inside the other function the loop is calling." Well is it really better to write an osbcur function instead of understanding why? Such shortcuts conduced to choose some languages like Java which try to do by itself everything a "junior" programmer don't want to do. And we now have thousands of applications programmed in Java whereas it's absolutely unusefull and which run 1/10th of the expect speed. For example, I want to speak about Androïd where Java is absolutely unusefull because we can't expect any portability from or to other systems and which have been choosed only because of the large number of potential programmers. What a pity! Sorry to have posted a comment a bit out of the subject. Regards, Alain