41–50 of 73 posts
Earlier quoted context omitted.
I was under the impression the C++ standard moves in lockstep with C so that all valid C programs should also be valid C++ programs.
That's Objective-C. int* foo = malloc(sizeof(int)); Is invalid C++.
C++'s const correctness rules?
My biggest problem with the new standard is the awkward naming of the threading functions. "mtx" over "mutex" saves a whole 2 bytes. Now what's up with that? Trying to avoid a namespace clash with some existing widely used library or something?
Back when C was first pioneer'd this was an issue. However this is the 21st century and yes we could have better full names but the standard from before is kept for consistency. I think deprecation and renaming of everything is out of the question at this point as companies and developers have invested considerable amounts of time in building applications using the good ole "fprintf" or "malloc". I wonder what the ra…
Earlier quoted context omitted.
If you don't like it use a typedef to make your code more "readable". Or a macro that will replace every occurrence of mutex in your code with mtx. However if you want to share your code with other people, I would go with the standard names.
Shouldn't the standard be as readable as possible and then use a typedef if u r 2 lazy 2 type 2 mo lettrs?
Designing for people that don't know anything about what they do isn't a goal worth pursuing, the only thing you might succeed with is tricking someone into thinking they know something - in which case you've just made it worse.
Earlier quoted context omitted.
Shouldn't the standard be as readable as possible and then use a typedef if u r 2 lazy 2 type 2 mo lettrs?
Is mutex more readable than mtx? Readability only matters for the programmer that is supposed to know what mtx/mutex is (regardless of the name) and the name itself of course, naming it mtx rather than mutex incurs no extra overhead to learn or understand. If anything the code is less cluttered and more to the point (without sacrificing anything (IMO)), but I don't see why I'd care. Designing for people that don't kn…
Also, "mtx" could just as well be "matrix" as another posted mentioned they had used in their code. "mutex" can never be "matrix"
Would anyone here be interested in a shim to play with this stuff before the compiler vendors add support? We've got a library that mirrors a lot of this functionality really closely already.
I would bet that most people who want to use it also have a similar library. For the thread stuff I just adhered to the pthread interface, and for atomic operations, I grabbed similar functions from the Linux kernel. (If you need code to do a low-level systems thing, chances are the Linux kernel needs it too. Fantastic resource.) I see this as a standard that's less providing new things, but providing consistent name…
But yes, I do agree with your first paragrpah. And we're always open to friendly emails--see profile for contact info.
Earlier quoted context omitted.
That's Objective-C. int* foo = malloc(sizeof(int)); Is invalid C++.
I don't really know C++ as well as I know C - could you explain? I always thought that the only real reason C++ wasn't a superset is because of the additional keywords.
int* foo = (int*)malloc(sizeof(int));
Earlier quoted context omitted.
Is mutex more readable than mtx? Readability only matters for the programmer that is supposed to know what mtx/mutex is (regardless of the name) and the name itself of course, naming it mtx rather than mutex incurs no extra overhead to learn or understand. If anything the code is less cluttered and more to the point (without sacrificing anything (IMO)), but I don't see why I'd care. Designing for people that don't kn…
Yes, it definitely matters I think. It's just an extra little bit of work to understand, which when you are debugging you needs as little mental clutter as possible. Why make something more work than it needs to be? Code is read more often then it is written therefore one ought to optimise for reading. Also, "mtx" could just as well be "matrix" as another posted mentioned they had used in their code. "mutex" can neve…
The only reason an "if" or "while" statement makes sense to every programmer isn't because it is readable but because you must know the syntax and semantics of the language you program. And having a good shorthand is faster to read and since mtx isn't a word it isn't associated as anything that could be a word but you instantly see it as a language construct (kind of like syntax highlighting) and thus reduces the work of mentally parsing the code (one advantage of not writing your code in English is that you subconsciously see the language constructs differently than any of the code that you wrote yourself, not saying that I prefer to do this or recommend it (on the contrary)).
Again, this example alone isn't one I'd really care about - just questioning that "mutex" would be more readable than "mtx" (as a language construct).
Earlier quoted context omitted.
C/C++ is used to build the fundation of pretty much everything you use every day. I don't think a fast moving standard would be a good thing.
A fast moving standard is not necessarily a bad thing, provided that changes don't break backwards compatibility. In some ways, I'd like the C standard to move a bit faster, to keep up with things like multi-threading (although there's an argument to be had over whether that should be defined as part of the language or left to vendor-specific libraries).
Another problem is that the standard becomes irrelevant. This is a concern for HTML5, because a 'rapidly evolving' standard means that things can be added prematurely - but once something is in the standard, it can't be removed (easily). At some point, you run the risk of having more companies go the Microsoft route and just abandon the standard altogether, and either stick with an older version, or just fork it into their own new language.
Earlier quoted context omitted.
This is annoying. This will conflict with the matrices in my code.
mtx_init and mtx_destroy might. The rest of the mtx_* keywords don't seem like they'd be used for a matrix library. (Keep in mind: identifiers ending in _t are reserved by POSIX. http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh... )