I meant "statically compiled language", not "statically typed language". I should have specified. I'm taking it as a given that Java is slower than C++ and C for real codes, and this is not rationally disputable. Memory use is part of performance.
If you added reflection to C++, you could optimize some of the performance overhead away, though probably not the memory use. And, if you're going to do it right, you'll have to carry around metadata per-object, not per-class; you'll at least need one pointer per object pointing to the class metadata like for RTTI. And unlike with RTTI, the overhead won't be limited to classes with vtables, because who knows what you might call this thing on?
All in all, it certainly wouldn't be possible to add reflection to C++, but I'm still not seeing why you'd want it. If you want to dynamically load libraries, just use dlopen().
A kilobyte per class is definitely significant for many applications, and not just deeply embedded ones. And, reflection requires more than tacking on data to class manifests. The power of reflection comes not from just being able to see your own type information, but from being able to invoke methods you didn't necessarily even know about at compile time based on it. In a static language, this is for obvious reasons extremely hard to do. I'm not saying it would be impossible to do for C++... but it's not at all obvious how such a system would interact with C++'s type system and just how it would work at runtime without causing slowdown. A kilobyte of data for every class definition is already VERY significant overhead in C++-land, and that's not all you would need. You'd need some sort of "magic" classes to provide the data requested to the classes and then do even more magic to invoke the discovered methods in some sort of reasonable way.
And what, exactly, would you get for your trouble for having done this? Java needs reflection for dynamic loading. C++ and C have a different system for dynamic loading based on the POSIX dlopen() and friends. In a very real sense, dlopen() is C++'s reflection system. Why do you think it needs another one?
If you tried to put Java reflection in C++, you would end up with Java slowdown in C++.
I guess there are cases where the compiler could be a little smarter rather than requiring forward declarations. I'm not sure whether that would be a good thing or would lead to more confusing error messages.
1. You were complaining about not being able to get the size of a C-style array in C++. If you're using C-style arrays, you're not getting bounds checking, so why would you complain that you're not getting bounds-checking with vector? It's the same as what you had with C-style arrays. And, I'm aware.at() does bounds checking. That's why I never use it. The performance penalty is not at all trivial; you're talking like a 2x slowdown in array accesses. There is no need to force your program to suffer that in production just for some slight convenience while debugging. If you want bounds checking while debugging, use []s like normal and just pass the special flag to GCC to enable run-time STL debugging..at() is for special cases, which is why it's syntactically awkward. If it were meant to be used in the general case, it would have been defined as the [] operator and the non-bounds-checked version would be.at().
2. I wrote my own tokenizer a decade ago. It's about 20 lines of code. Maybe I should publish it if it's that Earth-shattering.
3. I've never found myself wanting more reflection than what's provided by RTTI. In fact, I don't often use RTTI, either. Reflection is for dynamic languages; it's just not appropriate in this space.
4. It's never bothered me, but I can see it being a pet peeve. Yeah, I guess it's a holdover from earlier times. However, you can include the same function definition twice. Just use inline:) Whether the universe breaks depends on whether the definitions are identical.
1. Dude... if you want to query the size of an array, use a vector. No, it doesn't make your code less readable. And, no, you don't have to use.at() everywhere: C++ has this thing called operator overloading. Maybe you've heard of it. You can use array syntax with vectors. Use vectors.
2. I'd like to know what functionality you think you need string.h for when using C++ strings. I've found the standard library string type quite feature-complete.
3. C++ isn't an interpreted language; of course it won't have much reflection.
4. Forward declarations are not for saving the compiler time. They are for declaring a linkage interface with external code. If you ever even thought seriously about writing a C++ compiler you would know the language is not designed to make doing so easy.
5. C++11 is awesome. Any old language will have some cruft, but C++ has managed to keep it where you don't run into the cruft unless you're dealing with old code. That's the best you can hope for.
Umm, you're describing a parliamentary democracy, which the US is not. And the reason the President calls himself the Commander in Chief at times is because the Constitution, Article II Section 2, states explicitly that The President shall be Commander in Chief of the Army and Navy of the United States... If he calls himself the Commander in Chief in a speech or something, it's less likely to be crowing -- because, duh, of course you are -- than an attempt to indicate understanding of the serious responsibility of his position.
Perhaps you're not from the US. If that is the case, well, we do have our problems, and both recent and not-so-recent Presidents exercising power they might not legitimately possess is one. Probably the single most egregious example is not recent at all: Andrew Jackson infamously defied the Supreme Court with regard to Native American relocation. Google "Trail of Tears" if you haven't heard of it.
However, you might want to work to understand our system a little bit better before criticizing it, because the President is definitely supposed to be a very powerful individual and not at all supposed to be Congress's lapdog. Our system partly depends on a balancing act we call "checks and balances" where the President and Congress (and the Supreme Court) are all supposed to be able to stop each other from doing anything too out-of-hand. The reason we all learn about the "Trail of Tears" in our history classes -- in addition to the humanitarian disaster it was -- is because the system failed quite spectacularly in that instance. But, more often than not, it actually works pretty well. And it avoids the Prime Minister getting replaced every 6 months when the unstable parliamentary coalition that appointed him unravels. Every system has its faults.
If you read the article, it explains that many states' laws are more strict than the federal law... but they were preempted by the federal law in that the police department could decide to opt into the Equitable Sharing program and then not be bound by those restrictions. It's not the end of this horrible practice, but it's a good start.
So far the only actual Systemd issue I've had is that it screws up pulse audio on one of my machines (works fine on the laptop screws up on my desktop).
To spell it out for you, even though you must be being intentionally dense since literacy is inconsistent with being as stupid as you appear to be right now, the unsupported claim is "there's more". You gave a link to Nature. You claimed there was more, with no support, and then said anyone not willing to make your argument for you was an idiot.
I could probably find evidence to support your argument if I wanted. I could also probably find evidence to help make a counterargument to it if I wanted to. But I don't care to do either of those things. You don't get to pass the work of supporting your own claims off to others. At least not without me calling you out on it.
Your comment added nothing to the discussion, because you made a claim and, rather than backing it up, invited others to back it up for you and insulted any who declined your invitation. You are the noise that others must sift through to get to the signal. Your words fork no lightning. May God have mercy on your soul.
But the professional part isn't as interesting in this context to me as perhaps it is to you.
Yeah, not going to be lectured by you, and not scared of you, either. I know enough to ignore you, and end-run around you, without violating the rules. For instance, I would have tethered my phone, not set up my own router. Although long-term I probably would have quit a company so dysfunctional it doesn't provide wireless its employees. Not for that, but because dysfunction in one area usually correlates with dysfunction everywhere.
And that was my point. You were part of a dysfunctional system in this case, and you don't appear to have been helping.
And if your home routers are frying 2-3 times a year, you should have your electricity checked or not keep them next to the radiator or something. I've never had a wireless router die on me even once.
I don't know... you could try to, you know, help him achieve his goals in a better way that doesn't violate the rules. Suggest setting up an isolated intranet for wireless. If you're in charge of the network, why would you not set up WiFi to begin with; that just sucks.
It seems to me you're making yourself part of the problem, rather than the solution, by just blocking people. You do that, of course people will try to get around you. And, if that guy wants wireless enough, he'll eventually look up how to do it in a way such that you don't catch him, and then you won't know about it or be able to manage it. Like I said earlier, it's not that hard to do. You don't even need dd-wrt really, just a stick that supports master mode. I've done this before, though I've never had reason to at an employer. It works just fine, and you'd never catch it.
Also, Cisco crap is way overpriced, why would you require people to buy just that to begin with. They probably charge like $300 for a $20 wireless router.
That's the conservatives' charitable interpretation. We still don't know whether Reagan actually believed Star Wars was going to work.
The "testicular history of the cold war" posted above, puerile though it is, makes a good point about provoking a crippled Soviet Union. The Soviet Union was falling apart economically on its own years before Gorbachev took office. Was it really smart to provoke a politically and economically unstable -- but militarily capable and having a superpower-level nuclear arsenal -- supranational power as its government disintegrated? Or might it have been smarter to not make the Soviet people feel threatened from the outside right as their government lost power and there was a credible threat an anarchist mob of some sort might take control of the most deadly weapons ever forged?
Yeah, nothing bad happened. The Soviet Union fell peacefully and dissolved into new, mostly stable and democratic governments. Well, stableish, democraticish. About the best the world could hope for, really. But maybe it would have been more likely nothing bad would happen if the US pursued a non-confrontational policy rather than ratcheting up the pressure. A people that feels threatened from the outside is more likely to unite behind an undemocratic "strong man" leader than one that does not.
Just because you played Russian roulette and won, doesn't mean it was a good idea to play Russian roulette.
Games can do all sorts of unnecessary and stupid things, including loading 12 CPUs and consuming 500 watts so Duke Nukem's whiskers waft with the prevailing winds in the virtual environment.
They are a model for no type of problem except themselves.
It's certainly not the case that "almost all" problems decompose into data parallelism. Likewise, while there are some tasks that GPUs can do very well, there are others where they don't do well at all. What Linus is arguing is that the cases where they don't do well at all dominate. I concur. Programming this stuff typically locks you deeply into a single GPU's architecture, and, oh, you have zero cache, zero pipelining. There are other problems, too. A good overview of the technology as a whole is here: http://cstar.iiit.ac.in/~kkish...
GPGPU's have had some impressive successes, but CPUs are still more versatile, and, like Linus says, I don't see Intel giving up single core performance so people can program a bunch of tiny little ant-processors that can't communicate with each other in less than 500 cycles.
I'm not going to look at all your links because they prove nothing other than that computer-controlled systems sometimes fail. Of course they do, nothing is 100% reliable. But it is possible to fail gracefully. For instance, antilock brake systems have two identical computers doing the same calclations; if they disagree on what to do, the system fails gracefully and reverts to manual brake control. In the case of an automated car failure, graceful failure would be using a backup system to pull over to the side of the road, brake, and turn on emergency flashers. If this also fails, simply braking or disengaging the accelerator would be the next failure mode. i have no idea why you would assume that professional engineers would consider a car "randomly swerving at 70 miles an hour" an appropriate response when one of the 2-5 redundant primary computers failed, but I assure you they would not. There are many other ways to ensure the creation of reliable software; there is an entire field here and won't post a literature survey here. I'll just leave you with this: to be safer than human control, computers don't have to fly a plane perfectly, just better than the average pilot. To be safer than human control, computers must only drive safer than the average driver.
Yes. That's why the safety record of airliners has plummeted as computers control more and more of the cockpit and air traffic control towers, why antilock braking systems controlled by computers are universally derided as dangerous, why robotic surgery is outlawed in every civilized country, and why pacemakers were outlawed after a brief, tragic experiment with them ended in the computer putting a virus in the victim's brain and using the host as a primitive version of Skynet.
Or maybe... just maybe... the software controlling critical safety systems is written to a different standard of quality than the software controlling fucking Twitter.
Well, the problem with QuickSort is that if you're unlucky with your pivot choice you can get O(n^2) runtime. The problem with MergeSort is that you have to copy the array, which, for n in the millions, could be an issue.
For such a case I would recommend heapsort or introsort (which is just "quicksort unless I'm getting unlucky, then I do heapsort instead").
Sorry, the thief/embezzler bit came out a lot harsher than I intended. I'm not cynical/bitter. Merry Christmas.
You're right; I don't do much traveling on business. I'm rather glad of that:)
Re thief/embezzler, if the company's aware and okay with what you're doing, I guess it's okay, though I'd rather the company just give me the money than a non-monetary "perk" like that. Per diem sounds like a good way to do it although I don't think that's how my employer does it (not sure, haven't traveled on business with this employer yet).
If you got most of your status through your credit card... you spent over $500,000 on your credit card and could have gotten $5000-$10,000 in cash back with a 1% card. $5000+ for a lifetime membership in AA's rewards program? Not worth it for me; Southwest is better and cheaper anyway.
Slashdot Mirror
The are multiple implementations of Python. One is, in fact, written in Python: http://pypy.org/
The original Python interpreter is written in C for speed, not because an implementation in Python would be impossible.
I meant "statically compiled language", not "statically typed language". I should have specified. I'm taking it as a given that Java is slower than C++ and C for real codes, and this is not rationally disputable. Memory use is part of performance.
If you added reflection to C++, you could optimize some of the performance overhead away, though probably not the memory use. And, if you're going to do it right, you'll have to carry around metadata per-object, not per-class; you'll at least need one pointer per object pointing to the class metadata like for RTTI. And unlike with RTTI, the overhead won't be limited to classes with vtables, because who knows what you might call this thing on?
All in all, it certainly wouldn't be possible to add reflection to C++, but I'm still not seeing why you'd want it. If you want to dynamically load libraries, just use dlopen().
I'm pretty sure I do.
A kilobyte per class is definitely significant for many applications, and not just deeply embedded ones. And, reflection requires more than tacking on data to class manifests. The power of reflection comes not from just being able to see your own type information, but from being able to invoke methods you didn't necessarily even know about at compile time based on it. In a static language, this is for obvious reasons extremely hard to do. I'm not saying it would be impossible to do for C++ ... but it's not at all obvious how such a system would interact with C++'s type system and just how it would work at runtime without causing slowdown. A kilobyte of data for every class definition is already VERY significant overhead in C++-land, and that's not all you would need. You'd need some sort of "magic" classes to provide the data requested to the classes and then do even more magic to invoke the discovered methods in some sort of reasonable way.
And what, exactly, would you get for your trouble for having done this? Java needs reflection for dynamic loading. C++ and C have a different system for dynamic loading based on the POSIX dlopen() and friends. In a very real sense, dlopen() is C++'s reflection system. Why do you think it needs another one?
If you tried to put Java reflection in C++, you would end up with Java slowdown in C++.
I guess there are cases where the compiler could be a little smarter rather than requiring forward declarations. I'm not sure whether that would be a good thing or would lead to more confusing error messages.
1. You were complaining about not being able to get the size of a C-style array in C++. If you're using C-style arrays, you're not getting bounds checking, so why would you complain that you're not getting bounds-checking with vector? It's the same as what you had with C-style arrays. And, I'm aware .at() does bounds checking. That's why I never use it. The performance penalty is not at all trivial; you're talking like a 2x slowdown in array accesses. There is no need to force your program to suffer that in production just for some slight convenience while debugging. If you want bounds checking while debugging, use []s like normal and just pass the special flag to GCC to enable run-time STL debugging. .at() is for special cases, which is why it's syntactically awkward. If it were meant to be used in the general case, it would have been defined as the [] operator and the non-bounds-checked version would be .at().
2. I wrote my own tokenizer a decade ago. It's about 20 lines of code. Maybe I should publish it if it's that Earth-shattering.
3. I've never found myself wanting more reflection than what's provided by RTTI. In fact, I don't often use RTTI, either. Reflection is for dynamic languages; it's just not appropriate in this space.
4. It's never bothered me, but I can see it being a pet peeve. Yeah, I guess it's a holdover from earlier times. However, you can include the same function definition twice. Just use inline :) Whether the universe breaks depends on whether the definitions are identical.
1. Dude ... if you want to query the size of an array, use a vector. No, it doesn't make your code less readable. And, no, you don't have to use .at() everywhere: C++ has this thing called operator overloading. Maybe you've heard of it. You can use array syntax with vectors. Use vectors.
2. I'd like to know what functionality you think you need string.h for when using C++ strings. I've found the standard library string type quite feature-complete.
3. C++ isn't an interpreted language; of course it won't have much reflection.
4. Forward declarations are not for saving the compiler time. They are for declaring a linkage interface with external code. If you ever even thought seriously about writing a C++ compiler you would know the language is not designed to make doing so easy.
5. C++11 is awesome. Any old language will have some cruft, but C++ has managed to keep it where you don't run into the cruft unless you're dealing with old code. That's the best you can hope for.
Umm, you're describing a parliamentary democracy, which the US is not. And the reason the President calls himself the Commander in Chief at times is because the Constitution, Article II Section 2, states explicitly that The President shall be Commander in Chief of the Army and Navy of the United States... If he calls himself the Commander in Chief in a speech or something, it's less likely to be crowing -- because, duh, of course you are -- than an attempt to indicate understanding of the serious responsibility of his position.
Perhaps you're not from the US. If that is the case, well, we do have our problems, and both recent and not-so-recent Presidents exercising power they might not legitimately possess is one. Probably the single most egregious example is not recent at all: Andrew Jackson infamously defied the Supreme Court with regard to Native American relocation. Google "Trail of Tears" if you haven't heard of it.
However, you might want to work to understand our system a little bit better before criticizing it, because the President is definitely supposed to be a very powerful individual and not at all supposed to be Congress's lapdog. Our system partly depends on a balancing act we call "checks and balances" where the President and Congress (and the Supreme Court) are all supposed to be able to stop each other from doing anything too out-of-hand. The reason we all learn about the "Trail of Tears" in our history classes -- in addition to the humanitarian disaster it was -- is because the system failed quite spectacularly in that instance. But, more often than not, it actually works pretty well. And it avoids the Prime Minister getting replaced every 6 months when the unstable parliamentary coalition that appointed him unravels. Every system has its faults.
If you read the article, it explains that many states' laws are more strict than the federal law ... but they were preempted by the federal law in that the police department could decide to opt into the Equitable Sharing program and then not be bound by those restrictions. It's not the end of this horrible practice, but it's a good start.
So far the only actual Systemd issue I've had is that it screws up pulse audio on one of my machines (works fine on the laptop screws up on my desktop).
You win Irony of the Week award.
I think the Tor developers personally keep track of who's running the exit nodes. They've been able to catch fake exit nodes and ban them before.
To spell it out for you, even though you must be being intentionally dense since literacy is inconsistent with being as stupid as you appear to be right now, the unsupported claim is "there's more". You gave a link to Nature. You claimed there was more, with no support, and then said anyone not willing to make your argument for you was an idiot.
I could probably find evidence to support your argument if I wanted. I could also probably find evidence to help make a counterargument to it if I wanted to. But I don't care to do either of those things. You don't get to pass the work of supporting your own claims off to others. At least not without me calling you out on it.
Your comment added nothing to the discussion, because you made a claim and, rather than backing it up, invited others to back it up for you and insulted any who declined your invitation. You are the noise that others must sift through to get to the signal. Your words fork no lightning. May God have mercy on your soul.
HAND.
There's more. If you want to find them, you will. If you can't find it, you're not intelligent enough to understand any studies on the topic anyway.
See the quoted part there? That's the unsupported bald assertion.
Please try to show some reading comprehension.
Bald, unsupported assertion followed by ad hominem poisoning the well if anyone dares disagree with you.
-2 points.
But the professional part isn't as interesting in this context to me as perhaps it is to you.
Yeah, not going to be lectured by you, and not scared of you, either. I know enough to ignore you, and end-run around you, without violating the rules. For instance, I would have tethered my phone, not set up my own router. Although long-term I probably would have quit a company so dysfunctional it doesn't provide wireless its employees. Not for that, but because dysfunction in one area usually correlates with dysfunction everywhere.
And that was my point. You were part of a dysfunctional system in this case, and you don't appear to have been helping.
And if your home routers are frying 2-3 times a year, you should have your electricity checked or not keep them next to the radiator or something. I've never had a wireless router die on me even once.
I don't know ... you could try to, you know, help him achieve his goals in a better way that doesn't violate the rules. Suggest setting up an isolated intranet for wireless. If you're in charge of the network, why would you not set up WiFi to begin with; that just sucks.
It seems to me you're making yourself part of the problem, rather than the solution, by just blocking people. You do that, of course people will try to get around you. And, if that guy wants wireless enough, he'll eventually look up how to do it in a way such that you don't catch him, and then you won't know about it or be able to manage it. Like I said earlier, it's not that hard to do. You don't even need dd-wrt really, just a stick that supports master mode. I've done this before, though I've never had reason to at an employer. It works just fine, and you'd never catch it.
Also, Cisco crap is way overpriced, why would you require people to buy just that to begin with. They probably charge like $300 for a $20 wireless router.
You sound a little like a control freak.
dd-wrt in client mode. And MAC spoofing. And fuck you ;)
That's the conservatives' charitable interpretation. We still don't know whether Reagan actually believed Star Wars was going to work.
The "testicular history of the cold war" posted above, puerile though it is, makes a good point about provoking a crippled Soviet Union. The Soviet Union was falling apart economically on its own years before Gorbachev took office. Was it really smart to provoke a politically and economically unstable -- but militarily capable and having a superpower-level nuclear arsenal -- supranational power as its government disintegrated? Or might it have been smarter to not make the Soviet people feel threatened from the outside right as their government lost power and there was a credible threat an anarchist mob of some sort might take control of the most deadly weapons ever forged?
Yeah, nothing bad happened. The Soviet Union fell peacefully and dissolved into new, mostly stable and democratic governments. Well, stableish, democraticish. About the best the world could hope for, really. But maybe it would have been more likely nothing bad would happen if the US pursued a non-confrontational policy rather than ratcheting up the pressure. A people that feels threatened from the outside is more likely to unite behind an undemocratic "strong man" leader than one that does not.
Just because you played Russian roulette and won, doesn't mean it was a good idea to play Russian roulette.
Chuck Norris backs up his computer to single-write BD-Rs. Then he roundkicks your face.
I also do that, but not the face-kick part.
Games can do all sorts of unnecessary and stupid things, including loading 12 CPUs and consuming 500 watts so Duke Nukem's whiskers waft with the prevailing winds in the virtual environment.
They are a model for no type of problem except themselves.
It's certainly not the case that "almost all" problems decompose into data parallelism. Likewise, while there are some tasks that GPUs can do very well, there are others where they don't do well at all. What Linus is arguing is that the cases where they don't do well at all dominate. I concur. Programming this stuff typically locks you deeply into a single GPU's architecture, and, oh, you have zero cache, zero pipelining. There are other problems, too. A good overview of the technology as a whole is here: http://cstar.iiit.ac.in/~kkish...
GPGPU's have had some impressive successes, but CPUs are still more versatile, and, like Linus says, I don't see Intel giving up single core performance so people can program a bunch of tiny little ant-processors that can't communicate with each other in less than 500 cycles.
I'm not going to look at all your links because they prove nothing other than that computer-controlled systems sometimes fail. Of course they do, nothing is 100% reliable. But it is possible to fail gracefully. For instance, antilock brake systems have two identical computers doing the same calclations; if they disagree on what to do, the system fails gracefully and reverts to manual brake control. In the case of an automated car failure, graceful failure would be using a backup system to pull over to the side of the road, brake, and turn on emergency flashers. If this also fails, simply braking or disengaging the accelerator would be the next failure mode. i have no idea why you would assume that professional engineers would consider a car "randomly swerving at 70 miles an hour" an appropriate response when one of the 2-5 redundant primary computers failed, but I assure you they would not. There are many other ways to ensure the creation of reliable software; there is an entire field here and won't post a literature survey here. I'll just leave you with this: to be safer than human control, computers don't have to fly a plane perfectly, just better than the average pilot. To be safer than human control, computers must only drive safer than the average driver.
Yes. That's why the safety record of airliners has plummeted as computers control more and more of the cockpit and air traffic control towers, why antilock braking systems controlled by computers are universally derided as dangerous, why robotic surgery is outlawed in every civilized country, and why pacemakers were outlawed after a brief, tragic experiment with them ended in the computer putting a virus in the victim's brain and using the host as a primitive version of Skynet.
Or maybe ... just maybe ... the software controlling critical safety systems is written to a different standard of quality than the software controlling fucking Twitter.
Well, the problem with QuickSort is that if you're unlucky with your pivot choice you can get O(n^2) runtime. The problem with MergeSort is that you have to copy the array, which, for n in the millions, could be an issue.
For such a case I would recommend heapsort or introsort (which is just "quicksort unless I'm getting unlucky, then I do heapsort instead").
HeapSort doesn't get enough love :(
Umm ... (+1, Funny) ... I hope?
Neither of those sorting algorithms is particularly good, but random sort (bogosort) is hilariously bad.
Sorry, the thief/embezzler bit came out a lot harsher than I intended. I'm not cynical/bitter. Merry Christmas.
You're right; I don't do much traveling on business. I'm rather glad of that :)
Re thief/embezzler, if the company's aware and okay with what you're doing, I guess it's okay, though I'd rather the company just give me the money than a non-monetary "perk" like that. Per diem sounds like a good way to do it although I don't think that's how my employer does it (not sure, haven't traveled on business with this employer yet).
If you got most of your status through your credit card ... you spent over $500,000 on your credit card and could have gotten $5000-$10,000 in cash back with a 1% card. $5000+ for a lifetime membership in AA's rewards program? Not worth it for me; Southwest is better and cheaper anyway.