What's a "real name"? The name that you insist everyone calls you would be my definition. "Don't call me by my government"
Real name policies are BS anyhow - very Western Firstname Lastname centric, ignorant of cultures where the only unique name for someone is the list of all the names they're known by (which, as you might imagine, makes printed phone books less than useful).
One of the great truisms of software development is that there's no universal way to break down a persons name into components, and people get really pissed when you get their name wrong.
Thanks - useful tool. I guess we can do some tuning to see if there's anything useful to alarm on (we allocate a very large list very few minutes, and if the list grows too large everything fails - but possibly everything we care about will be "young", which makes this all non-trivial.
What does my example code do, would you say? It's tripped up many good programmers over the years.
Copy constructors or operator= don't add any "obscurity" to C++.
Wait, what? Are you replying to the right post?
The problems of macros and compiler arguments has nothing to do with C versus C++ programming/reading/debugging
Source debuggers and macros mix poorly, was my point, because what you really want is to step-by-step debug through the pre-processor, not the generated code, to see how the heck that got generated, or in the really bad cases, to have a clue what got generated.
Right, you don't call virtual functions during member initialization, you do that in the body of the constructor if you have to. Or am I misunderstanding your point?
The biggest mistake you can make in any language is to catch an OOM error and proceed (except in the very special case of deliberately exhausting memory in a single-threaded process to get the biggest possible buffer or whatever). It's more general in Java: don't catch throwable unless you then exit. No, not even then. Restarting is fine, but proceeding often leads to undefined behavior.
I thought you said sane C++ doesn't leak resources?
If you've never worked on code that can exhaust memory of even a big server without leaking resources, perhaps that explains why you think it's safe to catch throwable.
Nothing you said was language-specific (except that C offers the smallest toolkit of any language). Only use special-purpose tools for the purpose they were specially built for - don't go looking for excuses to use them elsewhere. If the only non-C part of C++ you ever use is the automatic clean-up of objects when you exit scope, you have a huge win just from that. Half the lines of code at least in a well-written C program vanish, and the actual logic of functions emerges from the clutter.
I swear, when some people think C++ all they know is "huge poorly documented class hierarchy I'll be forced to use", which is entirely not the point of the language (a decade of MS brain damage nonwithstanding).
Unortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
My experience differs. I've used C++ to greatly simplify many of those issues. "Placement new" is perfectly suited for slab allocation. What's more, you can switch a specific struct between slab allocation and normal allocation (or vice versa, more likely) without a significant re-write. Locking constructs are just objects, and number one advantage of C++ over C -- automatic object cleanup on scope exit -- is the greatest boon ever to lock management. Sure, no real difference for the various alloc types, (though all the C++ standard library container classes support custom allocators, it's rarely the right choice).
Yeah, sure there's plenty of stuff like thinking through deadlocks and priority inversions that no low-level language is going to help with, but there's also plenty of stuff where C++ is simply less error-prone than C, and involves less boilerplate, making algorithmic mistakes perhaps easier to see without the clutter.
Thanks - first piece of helpful advice in the thread! I'll definitely try out "G1 stopping the world" as a warning sign.
I'd also say this - if you're capable of writing C++ without any resource leaks you're capable of writing Java without any resource leaks. In which case memory usage will be predictable and simple load testing will show you how big a heap you need to allocate.
Our memory usage scales with load. Our load scales with usage. Predictions about growth in popularity of our product are all very well, but no excuse for not monitoring for impending doom (especially since we have some legacy code that doesn't scale horizontally and so we have to keep throwing more memory at the problem for those services until we can fix that).
A better solution of course is to not use a language that requires stupidly huge amounts of memory to do anything, but I'm sort of stuck with Java. I'll be happy enough when we've killed all the Ruby with fire.
I suspect you haven't probed the dark corners of C++. It does all sorts of useful things. So many people think of C++ as "C with crazy OOP class hierarchies", which isn't the point of the modern language at all, ancient MS GUI crap nonwithstanding.
Some neat things that C++ makes easy: "slab" allocation, strings and arrays that know about page boundaries for explicit page management, a system where whenever you de-reference a pointer to an important struct, you automatically check the validity of the struct (really is the type you think it is, hasn't been freed and/or re-allocated), That's all stuff I've been involved in doing the hard way, which was quite silly of us.
Well, one way, you can monitor heap usage and trend the usage immediately following full GCs.
The other way to look at it is as a function of time.
None of that applies to modern server-centric garbage collection (GC1). "Stop the world while I collect garbage" makes a server worthless if you have 64 GB and GB takes minutes, which is why the default GC for the server SDK hasn't worked that way since mid Java 7.
You must be totally unfamiliar with obfuscated code, and its natural emergence in a code base over time. With C macro craziness, you can of course run only the pre-processor on the C code to see what the macros actually expand into, but who knows that command-line argument without looking it up? Seeing the object is a couple of key-strokes in a modern IDE.
With C++, the language is too large for anyone to be familiar with all its dark corners, so when you discover that some oddball thing you're trying to do is already there in the language, but you've never seen that language feature before, and your attempt didn't behave as you expected? You can try reading the standard, if you have it handy and are good at standardese, or again a couple of keystrokes and you see what's up.
And I'd like to see anyone who gets bitten by if (BIT_FLAG == foo & BIT_MASK) and doesn't spot the problem right away figure that one out without looking at the object.
Most people have Artist --> Album --> Song. With a database you could navigate by all three and Genre and Composer and so on.
Obviously, you can do both. There's no reason, none at all, not to keep the actual mp3s in a sensible file tree, and all the relevant meta-data in the mp3s directly (so that you can scan anything copied to the filesystem directly and provide whatever clever interface you desire to them).
You do realize a playlist is just a file, right? And they can be auto-generated based on whatever - directory structure, tags, etc? Whatever algorithm the player has to organize sings into playlists will work just fine with playlist files too.
Unless the problem domain is quite simple, you need complex code to solve complex problems. And complex code always evolves into mysterious cruft, given sufficient time and coders involved.
Sure, sure, some "code base" that one guy wrote in a few months? Very obvious and clear results are possible. But a real project with a few programmer-centuries of code? I've worked on assembly code where looking at the object was the only way to be sure of what it did (to see what the macros expanded into). And C is no angel when it comes to clarity of poorly-written code!
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated
Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!
Every sufficiently large C project re-invents key portions of C++, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion. In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz. In Java, even with the better garbage collector designed for servers, "bouncing off the roof" is the norm, and it's quite hard to tell when danger is approaching.
I'd be interested in any/.er advice here - is there some dependable way with Oracle Java to measure "real heap size" - the total size of objects actually in use? The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
The fine is appropriate if you buy that they were willful but not malicious. If they were honestly trying to keep the WiFi working for presenters at the convention, and this was the only way, for example. OTOH, if this was some money-making scheme, that's malice in my book, and the FCC should have demolished the hotel such that no brick stands upon another, and salted the earth as a lesson to generations to come (or, just fined them enough that the CEO resigns, if you want to get all modern about it).
The sense of taste is mostly the sense of smell. What does that say for the life expectancy of Windows? I guess we'll have to see whether they're capable of regaining their sense of taste in the next release, as the clock started ticking with Metro.
Hand-coded assembly will always beat compiled code,
That's just wrong on modern processors, unless you count instructions so new the compiler team hasn't caught up with them yet (or, obviously, a platform too new for the compiler to have platform-specific optimization). Simple, in-order execution (like the first Atom)? Fine, you might tie the optimizer. But something like Core? The fastest way to do any simple operation depends on what the previous several operations were, in a very complex way.
For example, what's the best way to multiply a number by 8? Well, when are you going to reference the result? When's the most recent instruction that would tie up the silicon used for shifting? When's the next instruction that needs that same silicon? Maybe 3 adds is faster than a shift, maybe not. Heck, just multiplying is just as fast if it takes you long enough to use the result (everything's one clock, even division, if you wait long enough to touch the output).
Modern human-driven optimization is about minimizing conditional branching and maximizing locality of reference (often competing goals), which you can do in C as easily as ASM. Lots of old tricks like 256-byte lookup tables to shortcut bytewise computation are (usually) bad ideas on modern chips.
You can't copyright scents, or colors. You can't copyright instructions, such as game rules or recipes (though you can copyright some specific presentations of them). You can't copyright anything made without human creative input - no machine writing, no photographs where there's not even the slimmest claim of artistic composition or whatever.
Also, of recent note: monkey selfies have no copyright protection, nor presumably would any other picture taken by monkeys no matter how interesting.
But porn is certainly covered. There was a huge wave of porn-related copyright trolls recently.
Slashdot Mirror
What's a "real name"? The name that you insist everyone calls you would be my definition. "Don't call me by my government"
Real name policies are BS anyhow - very Western Firstname Lastname centric, ignorant of cultures where the only unique name for someone is the list of all the names they're known by (which, as you might imagine, makes printed phone books less than useful).
One of the great truisms of software development is that there's no universal way to break down a persons name into components, and people get really pissed when you get their name wrong.
Thanks - useful tool. I guess we can do some tuning to see if there's anything useful to alarm on (we allocate a very large list very few minutes, and if the list grows too large everything fails - but possibly everything we care about will be "young", which makes this all non-trivial.
Touche! A fair point.
The code example you gave is pretty clear.
What does my example code do, would you say? It's tripped up many good programmers over the years.
Copy constructors or operator= don't add any "obscurity" to C++.
Wait, what? Are you replying to the right post?
The problems of macros and compiler arguments has nothing to do with C versus C++ programming/reading/debugging
Source debuggers and macros mix poorly, was my point, because what you really want is to step-by-step debug through the pre-processor, not the generated code, to see how the heck that got generated, or in the really bad cases, to have a clue what got generated.
Right, you don't call virtual functions during member initialization, you do that in the body of the constructor if you have to. Or am I misunderstanding your point?
The biggest mistake you can make in any language is to catch an OOM error and proceed (except in the very special case of deliberately exhausting memory in a single-threaded process to get the biggest possible buffer or whatever). It's more general in Java: don't catch throwable unless you then exit. No, not even then. Restarting is fine, but proceeding often leads to undefined behavior.
I thought you said sane C++ doesn't leak resources?
If you've never worked on code that can exhaust memory of even a big server without leaking resources, perhaps that explains why you think it's safe to catch throwable.
Nothing you said was language-specific (except that C offers the smallest toolkit of any language). Only use special-purpose tools for the purpose they were specially built for - don't go looking for excuses to use them elsewhere. If the only non-C part of C++ you ever use is the automatic clean-up of objects when you exit scope, you have a huge win just from that. Half the lines of code at least in a well-written C program vanish, and the actual logic of functions emerges from the clutter.
I swear, when some people think C++ all they know is "huge poorly documented class hierarchy I'll be forced to use", which is entirely not the point of the language (a decade of MS brain damage nonwithstanding).
Unortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
My experience differs. I've used C++ to greatly simplify many of those issues. "Placement new" is perfectly suited for slab allocation. What's more, you can switch a specific struct between slab allocation and normal allocation (or vice versa, more likely) without a significant re-write. Locking constructs are just objects, and number one advantage of C++ over C -- automatic object cleanup on scope exit -- is the greatest boon ever to lock management. Sure, no real difference for the various alloc types, (though all the C++ standard library container classes support custom allocators, it's rarely the right choice).
Yeah, sure there's plenty of stuff like thinking through deadlocks and priority inversions that no low-level language is going to help with, but there's also plenty of stuff where C++ is simply less error-prone than C, and involves less boilerplate, making algorithmic mistakes perhaps easier to see without the clutter.
Thanks - first piece of helpful advice in the thread! I'll definitely try out "G1 stopping the world" as a warning sign.
I'd also say this - if you're capable of writing C++ without any resource leaks you're capable of writing Java without any resource leaks. In which case memory usage will be predictable and simple load testing will show you how big a heap you need to allocate.
Our memory usage scales with load. Our load scales with usage. Predictions about growth in popularity of our product are all very well, but no excuse for not monitoring for impending doom (especially since we have some legacy code that doesn't scale horizontally and so we have to keep throwing more memory at the problem for those services until we can fix that).
A better solution of course is to not use a language that requires stupidly huge amounts of memory to do anything, but I'm sort of stuck with Java. I'll be happy enough when we've killed all the Ruby with fire.
However you want your music software to organize files? Represent the result with playlist files and ID3 tags. Now it's 100% device independent.
I suspect you haven't probed the dark corners of C++. It does all sorts of useful things. So many people think of C++ as "C with crazy OOP class hierarchies", which isn't the point of the modern language at all, ancient MS GUI crap nonwithstanding.
Some neat things that C++ makes easy: "slab" allocation, strings and arrays that know about page boundaries for explicit page management, a system where whenever you de-reference a pointer to an important struct, you automatically check the validity of the struct (really is the type you think it is, hasn't been freed and/or re-allocated), That's all stuff I've been involved in doing the hard way, which was quite silly of us.
Well, one way, you can monitor heap usage and trend the usage immediately following full GCs.
The other way to look at it is as a function of time.
None of that applies to modern server-centric garbage collection (GC1). "Stop the world while I collect garbage" makes a server worthless if you have 64 GB and GB takes minutes, which is why the default GC for the server SDK hasn't worked that way since mid Java 7.
You must be totally unfamiliar with obfuscated code, and its natural emergence in a code base over time. With C macro craziness, you can of course run only the pre-processor on the C code to see what the macros actually expand into, but who knows that command-line argument without looking it up? Seeing the object is a couple of key-strokes in a modern IDE.
With C++, the language is too large for anyone to be familiar with all its dark corners, so when you discover that some oddball thing you're trying to do is already there in the language, but you've never seen that language feature before, and your attempt didn't behave as you expected? You can try reading the standard, if you have it handy and are good at standardese, or again a couple of keystrokes and you see what's up.
And I'd like to see anyone who gets bitten by
if (BIT_FLAG == foo & BIT_MASK)
and doesn't spot the problem right away figure that one out without looking at the object.
Most people have Artist --> Album --> Song. With a database you could navigate by all three and Genre and Composer and so on.
Obviously, you can do both. There's no reason, none at all, not to keep the actual mp3s in a sensible file tree, and all the relevant meta-data in the mp3s directly (so that you can scan anything copied to the filesystem directly and provide whatever clever interface you desire to them).
You do realize a playlist is just a file, right? And they can be auto-generated based on whatever - directory structure, tags, etc? Whatever algorithm the player has to organize sings into playlists will work just fine with playlist files too.
Unless the problem domain is quite simple, you need complex code to solve complex problems. And complex code always evolves into mysterious cruft, given sufficient time and coders involved.
Sure, sure, some "code base" that one guy wrote in a few months? Very obvious and clear results are possible. But a real project with a few programmer-centuries of code? I've worked on assembly code where looking at the object was the only way to be sure of what it did (to see what the macros expanded into). And C is no angel when it comes to clarity of poorly-written code!
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated
Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!
Every sufficiently large C project re-invents key portions of C++, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion. In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz. In Java, even with the better garbage collector designed for servers, "bouncing off the roof" is the norm, and it's quite hard to tell when danger is approaching.
I'd be interested in any /.er advice here - is there some dependable way with Oracle Java to measure "real heap size" - the total size of objects actually in use? The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
The fine is appropriate if you buy that they were willful but not malicious. If they were honestly trying to keep the WiFi working for presenters at the convention, and this was the only way, for example. OTOH, if this was some money-making scheme, that's malice in my book, and the FCC should have demolished the hotel such that no brick stands upon another, and salted the earth as a lesson to generations to come (or, just fined them enough that the CEO resigns, if you want to get all modern about it).
The sense of taste is mostly the sense of smell. What does that say for the life expectancy of Windows? I guess we'll have to see whether they're capable of regaining their sense of taste in the next release, as the clock started ticking with Metro.
Hey now, he's a complete fuckwit with good taste in music - props where they're due.
Hand-coded assembly will always beat compiled code,
That's just wrong on modern processors, unless you count instructions so new the compiler team hasn't caught up with them yet (or, obviously, a platform too new for the compiler to have platform-specific optimization). Simple, in-order execution (like the first Atom)? Fine, you might tie the optimizer. But something like Core? The fastest way to do any simple operation depends on what the previous several operations were, in a very complex way.
For example, what's the best way to multiply a number by 8? Well, when are you going to reference the result? When's the most recent instruction that would tie up the silicon used for shifting? When's the next instruction that needs that same silicon? Maybe 3 adds is faster than a shift, maybe not. Heck, just multiplying is just as fast if it takes you long enough to use the result (everything's one clock, even division, if you wait long enough to touch the output).
Modern human-driven optimization is about minimizing conditional branching and maximizing locality of reference (often competing goals), which you can do in C as easily as ASM. Lots of old tricks like 256-byte lookup tables to shortcut bytewise computation are (usually) bad ideas on modern chips.
Some larger trucks already do something like this (via the Peltier effect IIRC). 0.1 MPG is an important improvement for a big rig.
You can't copyright scents, or colors. You can't copyright instructions, such as game rules or recipes (though you can copyright some specific presentations of them). You can't copyright anything made without human creative input - no machine writing, no photographs where there's not even the slimmest claim of artistic composition or whatever.
Also, of recent note: monkey selfies have no copyright protection, nor presumably would any other picture taken by monkeys no matter how interesting.
But porn is certainly covered. There was a huge wave of porn-related copyright trolls recently.