By the way, I prefer your latter version for C++. Constructors really shouldn't do anything that can fail gracefully. A separate init() method encourages reuse of objects, making it easier to make them members by reference or value.
Exception enabled code used to be slow, especially in GCC. These days it is much faster.
Yes, exception-enabled code is fast, until you actually have to process an exception. Merely enabling exceptions typically also doubles the footprint of code, without a single actual exception handler or exception thrown, simply because the compiler has to emit cleanups to unwind each and every stack frame, from each and every scope, in case an exception *is* thrown somewhere. Code to actually work with exceptions then add on top of this.
Given the outrageous expense of processing exceptions, anything that resembles normal or non-exceptional should never be handled as an exception. This includes things like TCP FIN (*all* connections end with it), EOF, poll timeouts, event processing (yes, I've seen it done!), not to mention regular C library and syscall error returns. I've seen people wrap things like mkdir() with an error check that throws an exception if it returns -1. Well, the program that used the wrapper of course used mkdir() all over the place just to make sure a directory existed (and to create it if didn't). So it got an exception in the TYPICAL case. Every call point was then wrapped in an exception handler that, well, did nothing! I consider that borderline incompetent. But I digress. On the other hand, the things that really ARE exceptional - heap corruption, out of memory, deadlock detection, out of file descriptors, thread creation failure, unmounted root fs, kernel resource errors, etc, etc - there's nothing to be done about. And any attempt to do anything at all will likely aggravate the problem. In the case of say a heap corruption, or stack overflow, it's unlikely that attempting to process an exception is going to do anything more than crash. And serve only to make it harder to debug because it crashed somewhere in a runtime routine that walks a table with links to procedures to unwind the stack, not the place where it was actually first discovered. You're IMO better off simply calling a panic routine that stops then and there rather than attempt to do anything else that would only aggravate the problem further (possibly leading to real data loss - "oh, a corrupt heap... lets try to save the document before bailing" or similar brilliance). Between the two, and given the footprint overhead and the inevitable abuse in the absence of adult supervision, it's best not to use them at all. The sliver of cases between the two where exceptions are useful is so narrow that it's no longer meaningful formalism.
Note that you typically don't get away from the error check of a return value. Instead you move it further down the tree, to the position where you conditionally throw the exception, instead of at the return of the function. The difference is there, but trivial.
I think it greatly depends on your domain. If you're a C programmer with 20-25 or more years experience with operating systems you're eminently employable. Extremely so, in fact. If your experience is application software on the other hand, then you're almost certainly in trouble. However, since this is about IT and not technology companies I think the finger is squarely on the second group. C is probably on its way out of IT - as a systems programmer I think that makes a ton of sense, myself. It may never be out of the systems space though.
As for COBOL, I think he's flat out wrong. If you can program COBOL you'll have a job - programmers are retiring faster than the systems they maintain. And, no, it wouldn't make any sense for someone new in the field either, because chances are good they'd outlive the systems. I bet just about every COBOL shop is hiring.
Oh, I didn't know that. Is it very different from emacs lisp? It would make sense to stick with one extension language.
Elisp isn't an extension language for emacs - it's the implementation language. Lisp, in particular, is problematic as an extension language since it expects an interpreter with the top loop implemented in lisp, as well as a large global context. It's not something where you just load a small file and execute it, say an MTA mail filter, from within the context of a different program. You do it from within the global interpreter context. The state changes to the interpreter are then permanent. A lisp (or scheme) interpreter is far too expensive to instantiate as needed, say to filter each mail message. An MTA that effectively uses Guile to run all sort of extensions and plugin modules would by necessity have to be more or less implemented in Guile itself. That makes it an implementation language, not an extension language.
The elasticity of demand curve for Apple products peaks at a higher point in Australia than in the U.S. This is how all prices are set. Charge more and you lose enough sales to lose money; charge less and demand doesn't increase proportionally. Maybe remedial economy 101 for the labor party would also help them understand why there aren't any large, successful technology companies in Australia.
In Wrath as a tank your dungeon Q was instant, as a healer, 2 minutes at most, and usually closer to instant. As DPS? 30 minutes easily. This tells you that despite needing 3 DPS for 1 each tank and healer, there were still many more DPS. I mean on my druid I'd Q as tank and DPS and I never, ever, not even once, was chosen for DPS. The game always needed tanks.
This is even more the case in Cata (or at least was before I bailed). The dungeons are harder, but dps requirements low. I tanked heroics where as a tank I did more dps than two of the dps - and not gettting past bosses because dps simply couldn't burn them down before heals ran out of mana. Second, because the dungeons are harder if you run into a tank who says they've never played this dungeon before, could someone help them with pointers? - they will soon be the only one left. Because unless the dps is monumental or heals infinite, there will be lots of wipes. And repair bills. And "wasted" time - dps and heals will ask themselves if they'd rather queue another 30min or spend 90min wiping with nothing to show for it? Most tanks either stfu about not having ever run a particular dungeon before (and learn fast and blame others for wipes if there's finger pointing, and nobody likes to blame the tank anyway, with 30min queue times and whatnot), avoid queueing until they're ridiculously overgeared to compensate for not knowing it (which adds to the lack of dungeon tanks), or they have a guild or friends who will patiently show them the ropes (seeing it as an investment). The latter probably only happens if you're in a hardcore raiding guild. None are really satisfactory.
It becomes no fun to play a class when you know that you have wasted all your time levelling it to 85 and gearing it out, while someone who spent the same time with a dual/triple purpose class will always have a raid spot... and do as much, if not more DPS.
This isn't really true. Tanking dungeons is vastly quicker in terms of queue time, but it's also more demanding and you're not just going to roll more than 2 or 3 back to back before you need a mental break. As dps you can play for hours and it's no big deal. Tanking can't be simplified to rotation with a few variations, and watching single-target threat level. Second, it's actually harder to find a raid spot as a tank than dps; guilds aren't inclined to put the weight of their raid night on the shoulders of some random pickup, but they will happily pug a substitute dps or even heals - assuming they don't already have a ton of members eager for a chance to play the content they're paying for.
Even better - if a raid is short a player, throw in a bot until a player joins! I'd pick up WoW again in an instant if Bliz would give it an L4D style game so you can simply start a raid, and then as you're cleaning trash with a bunch of bots other can join in. People in your friends list who are currently not in a raid could get an automatic notification when you're in a raid with open slots.
WoW raiding. There is something I came to loathe. I seen the 40 man vanilla days at MC, it was sick. I would go along with a my guild if I had to, but I detested the need for massive socialization in order to feel like you done something in the game. WoW is like a hobby, a social life and sometimes a job all rolled up in one.
This. Exactly why I quit WoW - I'm a social player and will play either pve or pvp, although I prefer co-op pve games. I don't even mind the grind. But I hate all the guild shit... Just let me join a game and play whenever I feel like it, when I have time, and then leave as I see fit. To me my friends list is more critical than guild membership - don't care what guild someone is in, or even what faction they are (as a horde player, let me team up with alli; wtf do I care about the lame 2p mythology they've invented). Create a raid finder. Lobbies. Raid browsers. Make the content slightly malleable so a 10-man raid can be 9 or even 8-manned by scaling the environment slightly - so as people leave and join the game can continue. It's not easy finding a competent guild that actually needs players - they may be recruiting, but they don't actually have space for you to play. This got even worse in Cata where guilds were made even more central. No guild, no game. That's the reason I stopped playing it, not because of lack of fresh content (heck I don't even play the latest games now, I still enjoy L4D/L4D2 in plain expert campaign/pve mode).
RAII is the main thing. It lets you make all code exception safe, and never have another memory leak or file handle leak, with none of that annoying garbage collection. Code becomes so much more readable (and secure) when errors are dealt with as exceptions, instead of every damn function call being an if block.
Allocating global memory for local scratch space and string operations, for example, blows my mind.
Note that this is the default behavior for some template libraries. They do permit replacing the allocator. And with C++11 lambdas you can perhaps provide a one-off allocator that returns a static/auto array. (At least in some cases. For some implementations of some containers.) That said, the STL and boost are overengineered horrors IMO, and I avoid using either. In 10+ years of programming in C++ I've seen STL algorithms used *once* - to random shuffle a vector. And jeez, I can write a random shuffle function and a test for it in 15min. I can't remember seeing any use of iterators where [] wasn't just as good; iterators are mainly used to iterate containers that don't serve any real purpose (like stl::list; useless for large data sets even compared to say a deque or f-heap, too inefficient compared to an stl::vector or a C++ array for small sets). The little things, like vectors (or static arrays with bounds checks) I roll my own in, oh, an hour or two. For the *big* data sets... well, those tend to be core to a program and demand attention beyond pulling a hashmap off a shelf. Like concurrency might really matter, freelisting of nodes, etc. Doing it with something off the shelf is more complicated than rolling it yourself. And it probably won't be a template. Boost is impossible to debug, failures are utterly mysterious. And it can make a lean 100k C++ executable bloat to 5M just like that. Its asynchronous network connections... *shudder*! How hard is it to implement a reactor/proactor pattern? Not very, at least for a good network/systems programmer who has done it a few times before.
The things skilled programmers worry about is not how a language reads, or where it's meta this or that. Those are problems for college students. What matters is making the computer to *do* what it's supposed to - the quality of which is largely measured by 1) whether its full capacity is dedicated to the problem (e.g. by threading and not getting stuck around global locks or pipeline hazards), and 2) how little other work it does (like copying memory where no copy is needed, including cache fills). The resultant ratio of effort to quality is a function of programmer ability, in particular experience and deep understand of the problem domain.
I refused to switch from C to C++ for the longest time exactly because of misperceptions like it making automatic memory allocations - well, it doesn't. Some libraries do, but the same applies to C libraries. Just like there are C libraries I don't touch with a 10 foot pole there are C++ template libraries to avoid. C++ exceptions are mostly useless and cause grief and bloat - but they don't have to be used. The problem with exceptions is that they get used for things that aren't exceptional, like a TCP RST, while they can't recover from problems that truly are exceptional (e.g. out of memory, stack overflow, bus alignment error, wedged spinlock, lost interrupt). Between the two is a ridiculously thin error handling domain that really doesn't warrant its own language feature. RTTI is useless anyway, except dynamic_cast is useful for debug builds and some assert-level instrumentation. (Basically, it allows making type-based runtime asserts, in addition to the common value-based.) If I had had a an experienced programmer explain to me how to use C++ I would have switched much sooner. The code is so much cleaner. But I also refused to switch to C from assembler in the 80s, because of performance and code size. But eventually the value of code reuse won out and eventually I came to realize C compilers do nice things automatically; like if I make a small change it can completely reassign all register usage and enable/disable inlining, whereas manually I wouldn't bother until it got beyond a certain level or I really wanted to optimize some code path. Similarly, the stronger type formalism of C++ gives the compiler more information. Theoretically C++ also helps making better inlining decisions. If compilers could actually handle volatileness correctly as well then that should help code generation.
Also, it can be useful in places where no one has to yield at you, like a two-way stop at a busy street. Just walk the bike onto the crosswalk and you now have the #1 right of way.
There are shitty riders out there, just like there are shitty drivers. There are even shitty walkers, too...I've spent upwards of 20 minutes at various lights all over the downtown area because I had the bad luck of being at that intersection during change of classes and the 12,000 students in the building started streaming across the street whether there was a WALK symbol or not.
But if you're on a bike you can always step off and become a pedestrian yourself: walk across, then get back on and continue on your way. I do this a frequently myself at some intersections and to take a few shortcuts (stairs).
Agreed, obesity is the most efficient form of carbon sequestering at our disposal.
It's not really sequestering, it's just slowing down of the C cycle. The effects of slowing or speeding the C cycle are relatively minor (second order) compared to reintroducing fossil carbon (which is sequestered) into it.
Good point. When I ride my bicycle I'm never bothered by slower cyclists. When I ride my motorcycle I'm never 'stuck' behind bicyclists. However, in both cases do I get stuck behind slow cars. Cars can't pass slower vehicles because of their sheer size, and they block everyone behind them as well - something rarely on the mind of drivers. The problem isn't the slowness of others, the problem is the sheer size of the car. Basically, it's proportioned for 4-5 people with some amount of luggage, regardless of whether it's used for that or not. By comparison, it's not even legal for two cyclists to ride side by side and talk. Cars have passenger seats that take up that space even if it's unoccupied! The same car operator then has the stomach to complain about 'slow' cyclists.
When I drive my car it's because I'm either going out of town and carry things or go places where other forms of transportation are impractical (like skiing, or carrying a few people and their packs to a trailhead). I know it's not going to be as fast or convenient as a MC. But it's a conscious decision made based on practical trade-offs. I know I may drive for a bit at 15mph behind a cyclist, may miss light cycles, have to circle for parking, etc. I know all the two-wheelers will filter past me when traffic slows down. All that comes with my choice of vehicle - it's all self-imposed, not anything others are doing to me.
While the "idea" obviously isn't new, just having ideas isn't worth squat. This is the first time T cells have been effectively primed (including memory T cell production) to completely wipe out all traces of cancer. And not only a tiny amount, in a dish, or in a mouse; the human tumor masses were measured in pounds. This makes it big news. Someone realizing something completely new and reporting on it, is infinitely more interesting than yet another daydreamer having an idea that turns out impossible even before it leaves the napkin.
You're going to have to go over that one in more detail, Sparky. I can share my 500,000 LOC document control system between users with Windows XP 32 and 64 bit and Windows 7 32 and 64 bit. There's no reason not to expect Vista would work as well, although there's also no real reason to try.
Only in the MS COM universe does a document sharing system need 500k LOC. 475000 of those LOC will consist of handling COM objects.
In the embedded world, the most common is that a watchdog timer hard resets the device.
This only works if the watchdog poke isn't inside the infinite loop.
I actually think this is an excellent tool, not so much to notify users but as a debugging and test aid. Add it to valgrind/helgrind. Tell me when an iteration of a loop doesn't result in a change in state - this is clearly an anomaly and tells me it is dependent on an external condition to unwedge. Loops which are intended to wait for external events (like a spin lock or other atomic operation) I can flag as such to exempt from the instrumentation. This encourages factoring out such behavior into small more easily verified and debuggable/portable units - a good idea to begin with. I think the instrumentation sounds excellent - add it to valgrind!
1000W at 200mm distance equals (10/200)^2*1000 = 2.5W at 10mm. Cell phones burst at 3-5W (depending on local regulations). The oven is directional while the phone is omnidirectional, but the short distance means it can't be discounted.
- Light does have a mass, even if it is near 0. What speed could a particle with no mass attain then?
This is utterly silly. Photons have no mass at rest because they only exist in motion. E=MC^2; the mass (intertia) of a photon like any other particle, or body, is its energy. In fact, there is no difference between energy and inertia; they are the same thing. A photon might have "low mass" because it has low energy. A particle with lower energy would have lower inertia. Zero inertia only occurs at zero energy, which is empty space. I.e., what you get when you remove everything. If C could vary for photons, then there would be a hidden variable (state) x, such that E=MC(x)^2. Or energy and intertia are two different things. Good luck constructing a working theory of physics that 1) fits observations, and 2) predicts something E=MC^2 doesn't. (I.e. finding a case where the x is actually necessary.) But never has a particle been observed where E=MC^2 is violated, so you'd very likely be wasting your time...
So, typing 500 watts * 1 year * (10 cents / (kilowatt*hour)) into Google: about $482. Taking their $1,666 one year profit figure (mining profits - cost of card), it is now really a cost of $1,184. Which isn't as bad as I thought it'd be.
You mean it's a profit of $1182.
Problem is, $1182 is in the "hobby" domain, and not really enough to be considered an investment. If you think it's fun or interesting, do it. If not, don't bother since $1182 over a year isn't going to be worth the trouble.
To actually run it as a business, you'd deal with boxes like this by the 100s. You have real estate costs, heat to get rid of, infrastructure, and wages. (If you make $150k/yr as a senior eng or manager someplace, this is the wage you should consider since it's what you forego.) To make this doable, you'd have to locate someplace with cheap power and cheap real estate. And cheap, moderately skilled labor. (Need to be able to assemble and manage racks and racks of PCs.) You can probably save on the hardware costs as well since you can negotiate volume pricing. Personally, I'd put it in Washington.
As for someplace to spend money I think this is a minor concern. Heck, if I were to sit on a ton of BTC or run a large-scale mining operation I'd open a store myself if nobody else does. It would instantly increase the value of my hoard. This tells me once there's enough BTC out there this is going to happen.
Even if a mine isn't profitable today, it could be when combined with a retail business, and if BTC takes off you have a very valuable company. (Not a 'cashflow' business, but a 'stategic value' business.) OTOH, I suspect if you're not out there building a business this _today_ you've already missed the boat.
Slashdot Mirror
Oops, meant former, the f.init() version.
By the way, I prefer your latter version for C++. Constructors really shouldn't do anything that can fail gracefully. A separate init() method encourages reuse of objects, making it easier to make them members by reference or value.
Exception enabled code used to be slow, especially in GCC. These days it is much faster.
Yes, exception-enabled code is fast, until you actually have to process an exception. Merely enabling exceptions typically also doubles the footprint of code, without a single actual exception handler or exception thrown, simply because the compiler has to emit cleanups to unwind each and every stack frame, from each and every scope, in case an exception *is* thrown somewhere. Code to actually work with exceptions then add on top of this.
Given the outrageous expense of processing exceptions, anything that resembles normal or non-exceptional should never be handled as an exception. This includes things like TCP FIN (*all* connections end with it), EOF, poll timeouts, event processing (yes, I've seen it done!), not to mention regular C library and syscall error returns. I've seen people wrap things like mkdir() with an error check that throws an exception if it returns -1. Well, the program that used the wrapper of course used mkdir() all over the place just to make sure a directory existed (and to create it if didn't). So it got an exception in the TYPICAL case. Every call point was then wrapped in an exception handler that, well, did nothing! I consider that borderline incompetent. But I digress. On the other hand, the things that really ARE exceptional - heap corruption, out of memory, deadlock detection, out of file descriptors, thread creation failure, unmounted root fs, kernel resource errors, etc, etc - there's nothing to be done about. And any attempt to do anything at all will likely aggravate the problem. In the case of say a heap corruption, or stack overflow, it's unlikely that attempting to process an exception is going to do anything more than crash. And serve only to make it harder to debug because it crashed somewhere in a runtime routine that walks a table with links to procedures to unwind the stack, not the place where it was actually first discovered. You're IMO better off simply calling a panic routine that stops then and there rather than attempt to do anything else that would only aggravate the problem further (possibly leading to real data loss - "oh, a corrupt heap... lets try to save the document before bailing" or similar brilliance). Between the two, and given the footprint overhead and the inevitable abuse in the absence of adult supervision, it's best not to use them at all. The sliver of cases between the two where exceptions are useful is so narrow that it's no longer meaningful formalism.
Note that you typically don't get away from the error check of a return value. Instead you move it further down the tree, to the position where you conditionally throw the exception, instead of at the return of the function. The difference is there, but trivial.
I think it greatly depends on your domain. If you're a C programmer with 20-25 or more years experience with operating systems you're eminently employable. Extremely so, in fact. If your experience is application software on the other hand, then you're almost certainly in trouble. However, since this is about IT and not technology companies I think the finger is squarely on the second group. C is probably on its way out of IT - as a systems programmer I think that makes a ton of sense, myself. It may never be out of the systems space though.
As for COBOL, I think he's flat out wrong. If you can program COBOL you'll have a job - programmers are retiring faster than the systems they maintain. And, no, it wouldn't make any sense for someone new in the field either, because chances are good they'd outlive the systems. I bet just about every COBOL shop is hiring.
Oh, I didn't know that. Is it very different from emacs lisp? It would make sense to stick with one extension language.
Elisp isn't an extension language for emacs - it's the implementation language. Lisp, in particular, is problematic as an extension language since it expects an interpreter with the top loop implemented in lisp, as well as a large global context. It's not something where you just load a small file and execute it, say an MTA mail filter, from within the context of a different program. You do it from within the global interpreter context. The state changes to the interpreter are then permanent. A lisp (or scheme) interpreter is far too expensive to instantiate as needed, say to filter each mail message. An MTA that effectively uses Guile to run all sort of extensions and plugin modules would by necessity have to be more or less implemented in Guile itself. That makes it an implementation language, not an extension language.
Heh, yeah - I thought it was either a joke or the wrong neuron fired. :)
Hydrogen, helium, lithium and trace amounts of everything else.
Lithium??? I must be missing an internal joke here. The third most abundant element of course is oxygen. In order: H, He, O, C.
The elasticity of demand curve for Apple products peaks at a higher point in Australia than in the U.S. This is how all prices are set. Charge more and you lose enough sales to lose money; charge less and demand doesn't increase proportionally. Maybe remedial economy 101 for the labor party would also help them understand why there aren't any large, successful technology companies in Australia.
In Wrath as a tank your dungeon Q was instant, as a healer, 2 minutes at most, and usually closer to instant. As DPS? 30 minutes easily. This tells you that despite needing 3 DPS for 1 each tank and healer, there were still many more DPS. I mean on my druid I'd Q as tank and DPS and I never, ever, not even once, was chosen for DPS. The game always needed tanks.
This is even more the case in Cata (or at least was before I bailed). The dungeons are harder, but dps requirements low. I tanked heroics where as a tank I did more dps than two of the dps - and not gettting past bosses because dps simply couldn't burn them down before heals ran out of mana. Second, because the dungeons are harder if you run into a tank who says they've never played this dungeon before, could someone help them with pointers? - they will soon be the only one left. Because unless the dps is monumental or heals infinite, there will be lots of wipes. And repair bills. And "wasted" time - dps and heals will ask themselves if they'd rather queue another 30min or spend 90min wiping with nothing to show for it? Most tanks either stfu about not having ever run a particular dungeon before (and learn fast and blame others for wipes if there's finger pointing, and nobody likes to blame the tank anyway, with 30min queue times and whatnot), avoid queueing until they're ridiculously overgeared to compensate for not knowing it (which adds to the lack of dungeon tanks), or they have a guild or friends who will patiently show them the ropes (seeing it as an investment). The latter probably only happens if you're in a hardcore raiding guild. None are really satisfactory.
It becomes no fun to play a class when you know that you have wasted all your time levelling it to 85 and gearing it out, while someone who spent the same time with a dual/triple purpose class will always have a raid spot... and do as much, if not more DPS.
This isn't really true. Tanking dungeons is vastly quicker in terms of queue time, but it's also more demanding and you're not just going to roll more than 2 or 3 back to back before you need a mental break. As dps you can play for hours and it's no big deal. Tanking can't be simplified to rotation with a few variations, and watching single-target threat level. Second, it's actually harder to find a raid spot as a tank than dps; guilds aren't inclined to put the weight of their raid night on the shoulders of some random pickup, but they will happily pug a substitute dps or even heals - assuming they don't already have a ton of members eager for a chance to play the content they're paying for.
Even better - if a raid is short a player, throw in a bot until a player joins! I'd pick up WoW again in an instant if Bliz would give it an L4D style game so you can simply start a raid, and then as you're cleaning trash with a bunch of bots other can join in. People in your friends list who are currently not in a raid could get an automatic notification when you're in a raid with open slots.
Hopefully this is how Diablo 3 will work.
WoW raiding. There is something I came to loathe. I seen the 40 man vanilla days at MC, it was sick. I would go along with a my guild if I had to, but I detested the need for massive socialization in order to feel like you done something in the game. WoW is like a hobby, a social life and sometimes a job all rolled up in one.
This. Exactly why I quit WoW - I'm a social player and will play either pve or pvp, although I prefer co-op pve games. I don't even mind the grind. But I hate all the guild shit... Just let me join a game and play whenever I feel like it, when I have time, and then leave as I see fit. To me my friends list is more critical than guild membership - don't care what guild someone is in, or even what faction they are (as a horde player, let me team up with alli; wtf do I care about the lame 2p mythology they've invented). Create a raid finder. Lobbies. Raid browsers. Make the content slightly malleable so a 10-man raid can be 9 or even 8-manned by scaling the environment slightly - so as people leave and join the game can continue. It's not easy finding a competent guild that actually needs players - they may be recruiting, but they don't actually have space for you to play. This got even worse in Cata where guilds were made even more central. No guild, no game. That's the reason I stopped playing it, not because of lack of fresh content (heck I don't even play the latest games now, I still enjoy L4D/L4D2 in plain expert campaign/pve mode).
RAII is the main thing. It lets you make all code exception safe, and never have another memory leak or file handle leak, with none of that annoying garbage collection. Code becomes so much more readable (and secure) when errors are dealt with as exceptions, instead of every damn function call being an if block.
Agreed, RAII is an excellent reason to use C++.
Allocating global memory for local scratch space and string operations, for example, blows my mind.
Note that this is the default behavior for some template libraries. They do permit replacing the allocator. And with C++11 lambdas you can perhaps provide a one-off allocator that returns a static/auto array. (At least in some cases. For some implementations of some containers.) That said, the STL and boost are overengineered horrors IMO, and I avoid using either. In 10+ years of programming in C++ I've seen STL algorithms used *once* - to random shuffle a vector. And jeez, I can write a random shuffle function and a test for it in 15min. I can't remember seeing any use of iterators where [] wasn't just as good; iterators are mainly used to iterate containers that don't serve any real purpose (like stl::list; useless for large data sets even compared to say a deque or f-heap, too inefficient compared to an stl::vector or a C++ array for small sets). The little things, like vectors (or static arrays with bounds checks) I roll my own in, oh, an hour or two. For the *big* data sets... well, those tend to be core to a program and demand attention beyond pulling a hashmap off a shelf. Like concurrency might really matter, freelisting of nodes, etc. Doing it with something off the shelf is more complicated than rolling it yourself. And it probably won't be a template. Boost is impossible to debug, failures are utterly mysterious. And it can make a lean 100k C++ executable bloat to 5M just like that. Its asynchronous network connections... *shudder*! How hard is it to implement a reactor/proactor pattern? Not very, at least for a good network/systems programmer who has done it a few times before.
The things skilled programmers worry about is not how a language reads, or where it's meta this or that. Those are problems for college students. What matters is making the computer to *do* what it's supposed to - the quality of which is largely measured by 1) whether its full capacity is dedicated to the problem (e.g. by threading and not getting stuck around global locks or pipeline hazards), and 2) how little other work it does (like copying memory where no copy is needed, including cache fills). The resultant ratio of effort to quality is a function of programmer ability, in particular experience and deep understand of the problem domain.
I refused to switch from C to C++ for the longest time exactly because of misperceptions like it making automatic memory allocations - well, it doesn't. Some libraries do, but the same applies to C libraries. Just like there are C libraries I don't touch with a 10 foot pole there are C++ template libraries to avoid. C++ exceptions are mostly useless and cause grief and bloat - but they don't have to be used. The problem with exceptions is that they get used for things that aren't exceptional, like a TCP RST, while they can't recover from problems that truly are exceptional (e.g. out of memory, stack overflow, bus alignment error, wedged spinlock, lost interrupt). Between the two is a ridiculously thin error handling domain that really doesn't warrant its own language feature. RTTI is useless anyway, except dynamic_cast is useful for debug builds and some assert-level instrumentation. (Basically, it allows making type-based runtime asserts, in addition to the common value-based.) If I had had a an experienced programmer explain to me how to use C++ I would have switched much sooner. The code is so much cleaner. But I also refused to switch to C from assembler in the 80s, because of performance and code size. But eventually the value of code reuse won out and eventually I came to realize C compilers do nice things automatically; like if I make a small change it can completely reassign all register usage and enable/disable inlining, whereas manually I wouldn't bother until it got beyond a certain level or I really wanted to optimize some code path. Similarly, the stronger type formalism of C++ gives the compiler more information. Theoretically C++ also helps making better inlining decisions. If compilers could actually handle volatileness correctly as well then that should help code generation.
Not really. The main advantage of objects is the loose coupling.
No, the main advantage of objects is namespace hygiene.
Also, it can be useful in places where no one has to yield at you, like a two-way stop at a busy street. Just walk the bike onto the crosswalk and you now have the #1 right of way.
There are shitty riders out there, just like there are shitty drivers. There are even shitty walkers, too...I've spent upwards of 20 minutes at various lights all over the downtown area because I had the bad luck of being at that intersection during change of classes and the 12,000 students in the building started streaming across the street whether there was a WALK symbol or not.
But if you're on a bike you can always step off and become a pedestrian yourself: walk across, then get back on and continue on your way. I do this a frequently myself at some intersections and to take a few shortcuts (stairs).
Agreed, obesity is the most efficient form of carbon sequestering at our disposal.
It's not really sequestering, it's just slowing down of the C cycle. The effects of slowing or speeding the C cycle are relatively minor (second order) compared to reintroducing fossil carbon (which is sequestered) into it.
Good point. When I ride my bicycle I'm never bothered by slower cyclists. When I ride my motorcycle I'm never 'stuck' behind bicyclists. However, in both cases do I get stuck behind slow cars. Cars can't pass slower vehicles because of their sheer size, and they block everyone behind them as well - something rarely on the mind of drivers. The problem isn't the slowness of others, the problem is the sheer size of the car. Basically, it's proportioned for 4-5 people with some amount of luggage, regardless of whether it's used for that or not. By comparison, it's not even legal for two cyclists to ride side by side and talk. Cars have passenger seats that take up that space even if it's unoccupied! The same car operator then has the stomach to complain about 'slow' cyclists.
When I drive my car it's because I'm either going out of town and carry things or go places where other forms of transportation are impractical (like skiing, or carrying a few people and their packs to a trailhead). I know it's not going to be as fast or convenient as a MC. But it's a conscious decision made based on practical trade-offs. I know I may drive for a bit at 15mph behind a cyclist, may miss light cycles, have to circle for parking, etc. I know all the two-wheelers will filter past me when traffic slows down. All that comes with my choice of vehicle - it's all self-imposed, not anything others are doing to me.
This isn't "new news" so much as it is a follow-up on old news.
No, it's new news. While some parts of the trial started as much as a year ago, the result of the trial were presented yesterday (8/10): http://stm.sciencemag.org/content/3/95/95ra73.abstract
While the "idea" obviously isn't new, just having ideas isn't worth squat. This is the first time T cells have been effectively primed (including memory T cell production) to completely wipe out all traces of cancer. And not only a tiny amount, in a dish, or in a mouse; the human tumor masses were measured in pounds. This makes it big news. Someone realizing something completely new and reporting on it, is infinitely more interesting than yet another daydreamer having an idea that turns out impossible even before it leaves the napkin.
You're going to have to go over that one in more detail, Sparky. I can share my 500,000 LOC document control system between users with Windows XP 32 and 64 bit and Windows 7 32 and 64 bit. There's no reason not to expect Vista would work as well, although there's also no real reason to try.
Only in the MS COM universe does a document sharing system need 500k LOC. 475000 of those LOC will consist of handling COM objects.
In the embedded world, the most common is that a watchdog timer hard resets the device.
This only works if the watchdog poke isn't inside the infinite loop.
I actually think this is an excellent tool, not so much to notify users but as a debugging and test aid. Add it to valgrind/helgrind. Tell me when an iteration of a loop doesn't result in a change in state - this is clearly an anomaly and tells me it is dependent on an external condition to unwedge. Loops which are intended to wait for external events (like a spin lock or other atomic operation) I can flag as such to exempt from the instrumentation. This encourages factoring out such behavior into small more easily verified and debuggable/portable units - a good idea to begin with. I think the instrumentation sounds excellent - add it to valgrind!
C'mon... 1000W microwave versus cell phone?
1000W at 200mm distance equals (10/200)^2*1000 = 2.5W at 10mm. Cell phones burst at 3-5W (depending on local regulations). The oven is directional while the phone is omnidirectional, but the short distance means it can't be discounted.
- Light does have a mass, even if it is near 0. What speed could a particle with no mass attain then?
This is utterly silly. Photons have no mass at rest because they only exist in motion. E=MC^2; the mass (intertia) of a photon like any other particle, or body, is its energy. In fact, there is no difference between energy and inertia; they are the same thing. A photon might have "low mass" because it has low energy. A particle with lower energy would have lower inertia. Zero inertia only occurs at zero energy, which is empty space. I.e., what you get when you remove everything. If C could vary for photons, then there would be a hidden variable (state) x, such that E=MC(x)^2. Or energy and intertia are two different things. Good luck constructing a working theory of physics that 1) fits observations, and 2) predicts something E=MC^2 doesn't. (I.e. finding a case where the x is actually necessary.) But never has a particle been observed where E=MC^2 is violated, so you'd very likely be wasting your time...
So, typing 500 watts * 1 year * (10 cents / (kilowatt*hour)) into Google: about $482. Taking their $1,666 one year profit figure (mining profits - cost of card), it is now really a cost of $1,184. Which isn't as bad as I thought it'd be.
You mean it's a profit of $1182.
Problem is, $1182 is in the "hobby" domain, and not really enough to be considered an investment. If you think it's fun or interesting, do it. If not, don't bother since $1182 over a year isn't going to be worth the trouble.
To actually run it as a business, you'd deal with boxes like this by the 100s. You have real estate costs, heat to get rid of, infrastructure, and wages. (If you make $150k/yr as a senior eng or manager someplace, this is the wage you should consider since it's what you forego.) To make this doable, you'd have to locate someplace with cheap power and cheap real estate. And cheap, moderately skilled labor. (Need to be able to assemble and manage racks and racks of PCs.) You can probably save on the hardware costs as well since you can negotiate volume pricing. Personally, I'd put it in Washington.
As for someplace to spend money I think this is a minor concern. Heck, if I were to sit on a ton of BTC or run a large-scale mining operation I'd open a store myself if nobody else does. It would instantly increase the value of my hoard. This tells me once there's enough BTC out there this is going to happen.
Even if a mine isn't profitable today, it could be when combined with a retail business, and if BTC takes off you have a very valuable company. (Not a 'cashflow' business, but a 'stategic value' business.) OTOH, I suspect if you're not out there building a business this _today_ you've already missed the boat.