Sure, but then you're talking about a conspiracy to break the hypothetical law (which requires the standard to be implemented), which brings a new set of problems.
I will lose sleep knowing that I printed a replacement part for my car rather than buying it from the company that made my car? I have my doubts about that one...
Which is why I said that the standard would require printers to be too bloated for small scale or home uses. Who will take the time to create parts for a printer that not only does not implement the standard, but which would threaten the revenue model for those industrial 3D printing shops that actually operate 3D printers?
This is why, if we are going to have a 3D printing revolution, it needs to happen right now before such a standard can be created. That is one of the reasons PCs were so successful: they become popular before X.25 terminals were rammed down everyone's throats. The people who are threatened by 3D printing know this, and they are going to try to stop the revolution before it starts.
This sort of thing can be snuck into the law without too much difficulty, by first creating a standard and then passing a law that requires all 3D printers to implement the standard. The standard will not be able DRM, but about things people will want standardized: data formats, chemistry, electrical safety, etc., and then also the DRM requirement, tucked away in the standard.
I gave this prediction elsewhere, but I bet that such a standard will make 3D printers too bloated, expensive, and complicated for home use. None of the big industries that sell incompatible parts that make consumers' lives harder want to see a repeat of how PCs and the Internet affected the recording and movie industries. They will line up behind a 3D printing standard that makes industrial scale printing interoperable (but also ensures that their rounded rectangles are not being printed without authorization), but which is not feasible for small scale or home use.
Now, imagine if there were a 3D printing standard that included this restriction system, and a law (for your safety!) that required all 3D printers to implement the standard. I predict that the standard will create such monstrously bloated 3D printers that only industrial applications will be possible.
More likely, this company wants to make money on some future standard that will kill 3D printing. You know, a standard that will be required by law for all 3D printers, which will be so loaded with junk like this that only large industrial operations will be able to use 3D printers. Us little people can buy or rent the products of 3D printers, but to own or operate one in your home will be out of the question.
After all, when we allowed people to have computers in their homes instead of x.25 terminals, look at the disaster that ensued.
We can't have disruptive technologies that force us to change how we monetize creativity! Let's make the technologies useless, cumbersome, and expensive, so that later on we can claim they were never really worth what everyone thought!
Oh, and did I mention how terrible it is that we failed to do it with the automobile:
A technology that challenges the recording industry's firm grim on paying people to make music? A system that gives artists a big cut of the revenue made by monetizing their music? Something that might actually change revenue models? The lawsuits will not stop until this is dead and buried.
Even if what you said comes to pass, I have faith that someone somewhere would find a way around the problem.
Don't hold your breath -- many people do not see it as a problem, and some even see it as a good thing (after all, there will be fewer viruses!). It will not be easy to find a way around, either; the law as it exists today would make it impossible to deploy any real fix. When ISPs and banking websites start requiring "features" that are only available on such locked down systems, it will all be over. People who deploy PCs that can connect to ISPs and banking websites in such a world will be in the same category as people who sell illegal cable TV equipment.
Businesses are seeing the value of open systems - deploying more and more Linux into their network, and chaffing from the limitations imposed by 'black box' vendors - are seeing the business value of having options by casting off their vendor chains
Except that businesses are willing to pay for that, and willing to pay a lot. Red Hat is considered a bargain because of their pricing structure, which is one of the reasons they have been so successful. Businesses will pay a premium for flexibility, and they will not complain if their systems enforce such a licensing structure.
As long as things are interoperable, businesses will not complain.
Hardcore Gamers -- for gamers that play insanely complex simulations (FPS/Flight and combined arms combat simulations), there is no substitute for being able to build and tweak out their own game machine. Console game systems come nowhere near the capabilities of a tricked out game system; and for those who are highly competitive, having the technological edge is worth paying for.
Easily solved: create a restricted boot environment that requires the user to insert a smartcard into their system just to boot up. Then gamers can build whatever they want, with whatever hardware they want, and all they need to do is buy a "security module" that gives them access to the Internet (for online play). The best part is that the security modules can be designed to burn themselves out after a month (or whatever -- a day, or an hour, or whatever else), thus ensuring that gamers must pay a recurring fee to someone. Couple this with a TPM so that people have cryptographically enforced "accounts," and maybe create encrypted instruction sets, and you have a new way for gamers to pay to play -- which they will probably do, as long as the prices are not outrageous.
Yes, this failed a few years ago. It failed because there was no big shakeup in computing, nothing to motivate people to give up what they have. Now we have a big shakeup (the "app store model"), a strong demand for improved security, and another decade of experience in deployed DRM. The proposals did not die, they are just on hold. Ultraviolet is already deployed, and Microsoft is pushing for restricted boot environments.
Technologists and Scientists - a number of people who program or otherwise work in depth with computers will want to have access to computer resources in real-time for their own personal projects at home. In the old days this was known as 'console access'. It better be able to run all sorts of complex simulations, crunch large amounts of numbers, and compile their latest monster program in nothing flat.
My fiancee works for a corporation; they let her bring her laptop home from work if she wants to. She needs to use a smartcard to log in or access anything, so frankly, I think this is a problem that was solved already. Scientists and engineers will not be wanting for computing power on weekends or "vacations."
Independent Developers - hobbyists and other small scale/independent developers currently can't afford the cost of server grade computers to do their development on.
If you do not control your computer, if you cannot run whatever software you feel like, if you need to ask permission to do things, then it is not a "personal computer." It does not matter if it has a keyboard, mouse, and monitor; we can make a thin client with a connection to a mainframe that has such an interface, but that would not be a PC either.
I predict a future wherein we buy smartphone-sized computer casings and put the CPU, memory, post-SSD storage stuff, etc in there with tweezers.
...and I predict that you will not be able to connect that to any other computers, until you insert a special smartcard that burns itself out every thirty days. You will not be able to connect to the Internet, you will not be able to do your banking, you will not be able to share your birthday pictures with Grandma unless you buy access rights. Should you find a way to connect to another computer without making such a purchase, you will have become a criminal hacker, facing five years in prison for violating 60 different laws.
The death of PCs has nothing to do with form factor, and everything to do with the concept and purpose of PCs. We could have had computer access in every home via mainframes, by having terminals with x.25 connections. Of course, we would have had no innovation, but then again, why would the industry giants want to allow for disruptive technologies? The PC is one of the few examples in human history where entrenched interests were completely blindsided by a couple of commoners trying to help each other out (and now that those commoners are in positions of power, they recognize that they must prevent such disruption in the future).
Mainframes did not die because they were good for the market they served -- profitable for the vendor, utilized productively by the customer. PCs are different -- utilized poorly by most customers, and not as profitable for the vendor as they could be (oh, if we could just find a way to not allow people to run their own software...). That is why PCs are in greater peril now than mainframes ever were.
You'll still have a computer on your desk, with a monitor, keyboard, and mouse hooked up to it in 20 years. The difference is that you will need to get permission from the vendor before running software on that computer, and you will not have the chance to use your computer to create disruptive technologies. Middle schoolers with a passion for programming will only get to exercise their passion in the tightly controlled environment of their school's computer lab, using the language their teacher demands they use. Programmers will use $10k computers with special licensing structures that most individuals cannot afford.
The form factor is not going away any time soon. Eventually it will be replaced, I do not know with what, but it is likely that such a thing will not happen for a long time -- maybe not even within our lifetimes.
The concept is already dying. The idea that you can own the means of your own computing, and not have it be controlled or dictated to you by someone else, is on its last legs. We have been watching it die a painful deal for the past few years, and by 2020 personal computing as a concept will be forgotten by most of society.
The major battles of gay, civil, and reproductive rights were not won by a party, they were won by people -- people who went out and protested, people who were beaten up and arrested, people who had fire hoses sprayed at them. They had support by some politicians, mostly Democrats, but those politicians are not running for election now. The Democrats of the 50s, 60s, and 70s are not the Democrats of today. In fact, the 70s marked a turning point for the Democrats: it was the point at which they started accepting big campaign contributions from corporations.
Romney's support among African Americans is statistically zero. His Latino support is better, but not by much. Are you trying to tell me that those two groups know less about their own situation than you do?
Did I say people should vote for Mitt Romney?
If there's no difference, why not vote for the party with a track record of at least pretending like they give a damn?
I am planning vote for the party that does not need to pretend, because they actually do give a damn. Hint: their name starts with a G.
Everything you just said is true unless you don't care about gay rights, immigrant rights, reproductive rights, civil rights, publicly funded social programs, a modicum of union rights...
I do care about those issues, but it is worth pointing out that:
The major battles of the gay rights, reproductive rights, and civil rights movements were won decades ago. Today's big gay rights battle is about marriage, despite the widespread availability of civil unions; in the 1960s, it was illegal for two men to dance together at a night club in many states (including the place of my birth, New York). Today's big reproductive rights battle is about defending nationwide access to abortions; yet at one time, the battle was about allowing women to choose whether or not they would become pregnant without having to bow to their husbands' wishes. Today's big civil rights questions are about affirmative action and the limits of free speech rights; the major battles were about whether or not people could drink from the same water fountain, whether people could be members of the communist party, and if the news media could publish reports about our reasons for going to war (despite everything that has happened with Wikileaks, we have still improved since the Pentagon Papers).
Publicly funded social programs are not substantially better after four years of Obama's leadership. The one thing that would really have helped us -- publicly funded health care and the end of health insurance as an industry -- is dead. Our education system is so poorly funded that some schools are asking students to bring toilet paper, because the school district cannot afford it. We have "public" universities where students graduate saddled with debt, and the Obama administration's answer to that was "keep interest rates low, and increase the intensity of the pursuit of delinquent debtors." I guess you could say there is a choice: Republicans with overt attacks on these programs, or Democrats who corrupt the programs and render them worthless.
Democrats remain slightly better than Republicans on union rights, but hardly enough to justify my vote. Unions are being attacked at the state level by both Democrats and Republicans, and the Obama administration has done little to stop it.
Oh, and regarding civil rights? The Obama administration has stepped up the number of paramilitary raids on marijuana dispensaries in California. The past four years have seen more such raids than all eight years of the Bush administration combined. The DEA under the Obama administration has exercised its power to unilaterally declare drugs to be illegal over and over again -- and there has been a push to expand that power. One of the most serious civil rights issues we face today is the war on drugs, and the fact that as a direct result of it, we have the largest prison population on the planet. Neither Obama nor Romney have even bothered to publicly state their opposition to drug prohibition.
So you can spend your life paying attention to the superficial differences between Democrats and Republicans if you want. Your life is not likely to be substantially different if one side or the other is in power. You are just as likely to find yourself in prison. You are just as likely to find yourself or your children dealing with an enormous and inescapable debt. You are just as likely to have your interests ignored, and just as likely to see corporate interests promoted.
OK, we're getting really into pedantry. Replace do_something with always_do_something() which doesn't depend on global variables. Then you know what I mean.
I knew what you meant to begin with, but my point is that the missing return statement is only a problem in C if the return value is not discarded; in other words, what the function is used for determines whether or not the missing statement causes a crash. On the other hand, in C++, the crash depends on that, and additionally on the type that the function returns -- because a destructor will be called implicitly if you return an object by value. This would appear to make the missing statement more obvious, but it could just as easily go undetected if the class has a non-virtual destructor with an empty body, which is not uncommon.
Where this becomes a problem is when you do wind up with a crash, and you are trying to debug it. In the C version, you dereferenced an uninitialized pointer; in the C++ version, you could be trying to figure out any of the following:
Why you were dereferencing an uninitialized pointer in a destructor, when the member is always properly initialized and maintained by every member function of the class.
How you wound up calling some method of a totally unrelated class, with an uninitialized "this" pointer (if e.g. there was another object sitting in whatever region of memory your compiler puts return values, and you try to called a virtual destructor).
Why you tried to call a function in an invalid region of memory.
...and so forth. By the time you figure out that you were missing a return statement, you just spent an hour trying to trace pointers. This is made worse by the fact that many (most?) C++ debuggers will say "the problem is on line X," and when you look at the source on line X, you see no pointers at all, and you may not even see anything having to do with the class whose member function was called (see #2 above). In C, when you look at the line that dereferenced the pointer, you get no surprises at all, and working your way from there to the missing return statement is straightforward.
I believe you that it does not crash. That's besides the point: it's not fnuctionally equivalent to the C++ code.
Only because the C++ compiler is going to insert a bunch of implicit function calls and pointer dereferencing there, which coupled with the poor definition of the language (there is never a case where not having the return statement makes sense, so why is it allowed?) leads to this problem. If I need to take the time to think about what my compiler is inserting for me, then I might as well not even bother with C++; I could just create some macros in my favorite IDE to insert all that for me. The point of using high level features is to avoid wasting time thinking about how those things are being implemented for you. C++ is not supposed to be "C with macros" in this day and age.
Perhaps, but the complaint levelled at C++ only has no bearing on a C vs C++ thread, since it's an equal complaint for both. It's the truth, but not the whole truth, and thereby deceptive.
On its own it is an equal complaint for both. When coupled with the things that C++ does which C does not, it becomes a problem that affects C++ more severely than C. Warnings in C can sometimes be ignored without it being a problem (e.g. warnings about things related to portability); ignoring warnings in C++ is almost always a problem.
You're lurching into massive hypotheticals here
Not really; people who are used to MSVC++ sometimes do not realize that g++ does not give full/pedantic warnings by default (this was somewhat related to the switch from using an IDE to not using an IDE, but then we get back to the same point about the standard). I hear that MSVC++ will actually treat missing return statements as errors, although som
Your choices are to use a rational datatype...or an unbounded-precision type
I do not see why these should be separated. A rational datatype that uses arbitrary-width integers for the numerator and denominator gives you unbounded precision. Yes, you will have problems with irrational and transcendental numbers, but at least your basic arithmetic will be intuitive. If you do need do deal with irrational numbers and rounding errors are not acceptable, then you should be using a computer algebra system of some sort, or a library that gives you such types (if you are not using a language that allows you to embed a CAS in your code). You might even envision a language where the only way to compute something irrational would be to use such a system -- a language where sin/cos/sqrt/etc. return some numeric type that must be explicitly coerced to a rational or floating point type if the programmer actually wants such an approximation.
why would we expect the same things to be perfect everywhere?
We are talking about general purpose programming languages, that's why. If we cannot expect our programming languages to be good, then we cannot expect the software we write in those languages to be good either. If we cannot expect any language to give us what we want in arbitrary applications, then we should not create general purpose languages; we should create domain specific languages (there actually is a middle ground on this issue: https://en.wikipedia.org/wiki/Language_oriented_programming).
The equavilent C code to the C++ code is:
char * f(void)
{
if(some_condition)
return "Some string";
}...
do_something(f());...
That will always crash.
In fact, it will not always crash, and here is what happens when I run this version of "do_something" on my system:
void do_something(const char * c) { if(some_condition) cout << c << endl; cout << "If I have not crashed, I should wind up here." << endl; }
Which does not crash (at least when compiled with g++ 4.4.6) when some_condition is true or when some_condition is false. On the other hand, using string instead of const char * crashes whenever some_condition is false (which is lucky, because it need not crash). Try it yourself if you do not believe me.
Firstly, it's something that any C OR C++ programmer should do
Then it should be in the standard. If there is no good reason not to do it, then there is no reason for it to be excluded from the standard (for C, you might claim that the goal of portability necessitates a simple compiler; no such excuse can be made for C++, given how complex the language is to begin with).
Secondly, there's the implicit assumption that you'll get C++ programmers who don't know this
Or that you'll get C++ programmers who are more familiar with a different compiler, which has different flags (or maybe one that does not even have such options -- after all, if it is not required, you cannot expect it).
You mean in C++ it is far more likely to notice the undefined behaviour?
No, I mean it is more likely to be noticed long after it was written and committed, after numerous other changes have been committed, and will then require hours of debugging to figure out. Leaving out a return statement from a function that claims to return an object by value may not cause a crash, if the destructor is not virtual and has an empty body; then one day someone makes the destructor virtual and the program starts behaving wrong. The problem is that C++ inserts a lot of extra pointers and function calls, which is what turns undefined behavior into a landmine.
And you do the same thing in C by returning a pointer to a local variable from a function.
Except that a lexical closure is not dealing with a pointer, it is dealing with a reference, which comes with a different set of rules and restrictions. The solution is counter-intuitive (that the lambda should capture variables by value) and makes the code needlessly complex (as you must now use pointers where there was no real need). The solution is also unique to the case where the closure is returned from a function; if it is passed as an argument to a function call, you can capture by reference without a problem.
And as I recall, the default for lambdas is to take its parameters by value, so you explicitly chose to capture by reference to create the lifetime issue
I am pretty sure the default is "no capture," but even if what you are saying is true, capture by value is counterintuitive for a lexical closure. I do not want my own separate copy of the variable, I want the same one as the function call that the expression was returned from. The problem is that in C++, the lexical environment is destroyed when the function returns, rather than when the environment is no longer needed. Yes, this is a consequence of having no garbage collector; the solution is to have a garbage collector, and perhaps to give programmers a standardized way to enable/disable it if C++ programmers really do need to not have GC sometimes (although I suspect that such cases are comparatively few and far between, given that the overwhelming majority of C++ programs are high-level and given how popular smart pointers are).
Unless your constructor was called during the initialization of a global object, in which case the exception cannot be caught anywhere. Although some people think this is a good thing, it is probably not what you actually want to have happen, because you might want to destroy other global objects before you exit.
Does Dr. Joe Researcher make any money selling papers?
Not directly; a researcher might make money by advancing his career, which a well-padded resume might help with, which publishing in top name journals accomplishes. But that is a pretty big stretch, and there is no reason that a resume could not be padded in another system where the papers cannot be copyrighted (or simply are not). Note also that researchers in my own field, where papers are almost always available at no cost, still pad their resumes.
Do the institutions that employ Dr. Joe?
That is even more tenuous. Institutions with researchers that have well-padded resumes do tend to bring in more grant money, because those researchers are more likely to get grants. Again, in my field, people get lots of grant money, despite the fact that their published papers can be downloaded at no cost.
Does any of the money flow back to the source of funding?
Only in the sense that the money I spent on coffee this past week will eventually find its way there.
In the long run, copyrights on scientific research are going to either die or become irrelevant, that's why. That is all that the middle of the road approach has going for it.
Slashdot Mirror
Sure, but then you're talking about a conspiracy to break the hypothetical law (which requires the standard to be implemented), which brings a new set of problems.
You'll sleep easier too.
I will lose sleep knowing that I printed a replacement part for my car rather than buying it from the company that made my car? I have my doubts about that one...
Which is why I said that the standard would require printers to be too bloated for small scale or home uses. Who will take the time to create parts for a printer that not only does not implement the standard, but which would threaten the revenue model for those industrial 3D printing shops that actually operate 3D printers?
This is why, if we are going to have a 3D printing revolution, it needs to happen right now before such a standard can be created. That is one of the reasons PCs were so successful: they become popular before X.25 terminals were rammed down everyone's throats. The people who are threatened by 3D printing know this, and they are going to try to stop the revolution before it starts.
Not to mention, aren't patents usually used to PREVENT someone (else) from implementing a feature?
https://en.wikipedia.org/wiki/Reasonable_and_non-discriminatory_licensing
This sort of thing can be snuck into the law without too much difficulty, by first creating a standard and then passing a law that requires all 3D printers to implement the standard. The standard will not be able DRM, but about things people will want standardized: data formats, chemistry, electrical safety, etc., and then also the DRM requirement, tucked away in the standard.
I gave this prediction elsewhere, but I bet that such a standard will make 3D printers too bloated, expensive, and complicated for home use. None of the big industries that sell incompatible parts that make consumers' lives harder want to see a repeat of how PCs and the Internet affected the recording and movie industries. They will line up behind a 3D printing standard that makes industrial scale printing interoperable (but also ensures that their rounded rectangles are not being printed without authorization), but which is not feasible for small scale or home use.
All VCRs must be vulnerable to the Macrovision attack, by law. What makes you think that 3D printers won't have a similar problem?
Now, imagine if there were a 3D printing standard that included this restriction system, and a law (for your safety!) that required all 3D printers to implement the standard. I predict that the standard will create such monstrously bloated 3D printers that only industrial applications will be possible.
More likely, this company wants to make money on some future standard that will kill 3D printing. You know, a standard that will be required by law for all 3D printers, which will be so loaded with junk like this that only large industrial operations will be able to use 3D printers. Us little people can buy or rent the products of 3D printers, but to own or operate one in your home will be out of the question.
After all, when we allowed people to have computers in their homes instead of x.25 terminals, look at the disaster that ensued.
We can't have disruptive technologies that force us to change how we monetize creativity! Let's make the technologies useless, cumbersome, and expensive, so that later on we can claim they were never really worth what everyone thought!
Oh, and did I mention how terrible it is that we failed to do it with the automobile:
https://en.wikipedia.org/wiki/Red_flag_laws
A technology that challenges the recording industry's firm grim on paying people to make music? A system that gives artists a big cut of the revenue made by monetizing their music? Something that might actually change revenue models? The lawsuits will not stop until this is dead and buried.
Even if what you said comes to pass, I have faith that someone somewhere would find a way around the problem.
Don't hold your breath -- many people do not see it as a problem, and some even see it as a good thing (after all, there will be fewer viruses!). It will not be easy to find a way around, either; the law as it exists today would make it impossible to deploy any real fix. When ISPs and banking websites start requiring "features" that are only available on such locked down systems, it will all be over. People who deploy PCs that can connect to ISPs and banking websites in such a world will be in the same category as people who sell illegal cable TV equipment.
Businesses are seeing the value of open systems - deploying more and more Linux into their network, and chaffing from the limitations imposed by 'black box' vendors - are seeing the business value of having options by casting off their vendor chains
Except that businesses are willing to pay for that, and willing to pay a lot. Red Hat is considered a bargain because of their pricing structure, which is one of the reasons they have been so successful. Businesses will pay a premium for flexibility, and they will not complain if their systems enforce such a licensing structure.
As long as things are interoperable, businesses will not complain.
Hardcore Gamers -- for gamers that play insanely complex simulations (FPS/Flight and combined arms combat simulations), there is no substitute for being able to build and tweak out their own game machine. Console game systems come nowhere near the capabilities of a tricked out game system; and for those who are highly competitive, having the technological edge is worth paying for.
Easily solved: create a restricted boot environment that requires the user to insert a smartcard into their system just to boot up. Then gamers can build whatever they want, with whatever hardware they want, and all they need to do is buy a "security module" that gives them access to the Internet (for online play). The best part is that the security modules can be designed to burn themselves out after a month (or whatever -- a day, or an hour, or whatever else), thus ensuring that gamers must pay a recurring fee to someone. Couple this with a TPM so that people have cryptographically enforced "accounts," and maybe create encrypted instruction sets, and you have a new way for gamers to pay to play -- which they will probably do, as long as the prices are not outrageous.
Yes, this failed a few years ago. It failed because there was no big shakeup in computing, nothing to motivate people to give up what they have. Now we have a big shakeup (the "app store model"), a strong demand for improved security, and another decade of experience in deployed DRM. The proposals did not die, they are just on hold. Ultraviolet is already deployed, and Microsoft is pushing for restricted boot environments.
Technologists and Scientists - a number of people who program or otherwise work in depth with computers will want to have access to computer resources in real-time for their own personal projects at home. In the old days this was known as 'console access'. It better be able to run all sorts of complex simulations, crunch large amounts of numbers, and compile their latest monster program in nothing flat.
My fiancee works for a corporation; they let her bring her laptop home from work if she wants to. She needs to use a smartcard to log in or access anything, so frankly, I think this is a problem that was solved already. Scientists and engineers will not be wanting for computing power on weekends or "vacations."
Independent Developers - hobbyists and other small scale/independent developers currently can't afford the cost of server grade computers to do their development on.
Here is what the powers that be have to s
If you do not control your computer, if you cannot run whatever software you feel like, if you need to ask permission to do things, then it is not a "personal computer." It does not matter if it has a keyboard, mouse, and monitor; we can make a thin client with a connection to a mainframe that has such an interface, but that would not be a PC either.
I predict a future wherein we buy smartphone-sized computer casings and put the CPU, memory, post-SSD storage stuff, etc in there with tweezers.
The death of PCs has nothing to do with form factor, and everything to do with the concept and purpose of PCs. We could have had computer access in every home via mainframes, by having terminals with x.25 connections. Of course, we would have had no innovation, but then again, why would the industry giants want to allow for disruptive technologies? The PC is one of the few examples in human history where entrenched interests were completely blindsided by a couple of commoners trying to help each other out (and now that those commoners are in positions of power, they recognize that they must prevent such disruption in the future).
Mainframes did not die because they were good for the market they served -- profitable for the vendor, utilized productively by the customer. PCs are different -- utilized poorly by most customers, and not as profitable for the vendor as they could be (oh, if we could just find a way to not allow people to run their own software...). That is why PCs are in greater peril now than mainframes ever were.
You'll still have a computer on your desk, with a monitor, keyboard, and mouse hooked up to it in 20 years. The difference is that you will need to get permission from the vendor before running software on that computer, and you will not have the chance to use your computer to create disruptive technologies. Middle schoolers with a passion for programming will only get to exercise their passion in the tightly controlled environment of their school's computer lab, using the language their teacher demands they use. Programmers will use $10k computers with special licensing structures that most individuals cannot afford.
The issue is not the form, it is the philosophy.
The form factor is not going away any time soon. Eventually it will be replaced, I do not know with what, but it is likely that such a thing will not happen for a long time -- maybe not even within our lifetimes.
The concept is already dying. The idea that you can own the means of your own computing, and not have it be controlled or dictated to you by someone else, is on its last legs. We have been watching it die a painful deal for the past few years, and by 2020 personal computing as a concept will be forgotten by most of society.
Romney's support among African Americans is statistically zero. His Latino support is better, but not by much. Are you trying to tell me that those two groups know less about their own situation than you do?
Did I say people should vote for Mitt Romney?
If there's no difference, why not vote for the party with a track record of at least pretending like they give a damn?
I am planning vote for the party that does not need to pretend, because they actually do give a damn. Hint: their name starts with a G.
Everything you just said is true unless you don't care about gay rights, immigrant rights, reproductive rights, civil rights, publicly funded social programs, a modicum of union rights...
I do care about those issues, but it is worth pointing out that:
Oh, and regarding civil rights? The Obama administration has stepped up the number of paramilitary raids on marijuana dispensaries in California. The past four years have seen more such raids than all eight years of the Bush administration combined. The DEA under the Obama administration has exercised its power to unilaterally declare drugs to be illegal over and over again -- and there has been a push to expand that power. One of the most serious civil rights issues we face today is the war on drugs, and the fact that as a direct result of it, we have the largest prison population on the planet. Neither Obama nor Romney have even bothered to publicly state their opposition to drug prohibition.
So you can spend your life paying attention to the superficial differences between Democrats and Republicans if you want. Your life is not likely to be substantially different if one side or the other is in power. You are just as likely to find yourself in prison. You are just as likely to find yourself or your children dealing with an enormous and inescapable debt. You are just as likely to have your interests ignored, and just as likely to see corporate interests promoted.
OK, we're getting really into pedantry. Replace do_something with always_do_something() which doesn't depend on global variables. Then you know what I mean.
I knew what you meant to begin with, but my point is that the missing return statement is only a problem in C if the return value is not discarded; in other words, what the function is used for determines whether or not the missing statement causes a crash. On the other hand, in C++, the crash depends on that, and additionally on the type that the function returns -- because a destructor will be called implicitly if you return an object by value. This would appear to make the missing statement more obvious, but it could just as easily go undetected if the class has a non-virtual destructor with an empty body, which is not uncommon.
Where this becomes a problem is when you do wind up with a crash, and you are trying to debug it. In the C version, you dereferenced an uninitialized pointer; in the C++ version, you could be trying to figure out any of the following:
I believe you that it does not crash. That's besides the point: it's not fnuctionally equivalent to the C++ code.
Only because the C++ compiler is going to insert a bunch of implicit function calls and pointer dereferencing there, which coupled with the poor definition of the language (there is never a case where not having the return statement makes sense, so why is it allowed?) leads to this problem. If I need to take the time to think about what my compiler is inserting for me, then I might as well not even bother with C++; I could just create some macros in my favorite IDE to insert all that for me. The point of using high level features is to avoid wasting time thinking about how those things are being implemented for you. C++ is not supposed to be "C with macros" in this day and age.
Perhaps, but the complaint levelled at C++ only has no bearing on a C vs C++ thread, since it's an equal complaint for both. It's the truth, but not the whole truth, and thereby deceptive.
On its own it is an equal complaint for both. When coupled with the things that C++ does which C does not, it becomes a problem that affects C++ more severely than C. Warnings in C can sometimes be ignored without it being a problem (e.g. warnings about things related to portability); ignoring warnings in C++ is almost always a problem.
You're lurching into massive hypotheticals here
Not really; people who are used to MSVC++ sometimes do not realize that g++ does not give full/pedantic warnings by default (this was somewhat related to the switch from using an IDE to not using an IDE, but then we get back to the same point about the standard). I hear that MSVC++ will actually treat missing return statements as errors, although som
Your choices are to use a rational datatype...or an unbounded-precision type
I do not see why these should be separated. A rational datatype that uses arbitrary-width integers for the numerator and denominator gives you unbounded precision. Yes, you will have problems with irrational and transcendental numbers, but at least your basic arithmetic will be intuitive. If you do need do deal with irrational numbers and rounding errors are not acceptable, then you should be using a computer algebra system of some sort, or a library that gives you such types (if you are not using a language that allows you to embed a CAS in your code). You might even envision a language where the only way to compute something irrational would be to use such a system -- a language where sin/cos/sqrt/etc. return some numeric type that must be explicitly coerced to a rational or floating point type if the programmer actually wants such an approximation.
why would we expect the same things to be perfect everywhere?
We are talking about general purpose programming languages, that's why. If we cannot expect our programming languages to be good, then we cannot expect the software we write in those languages to be good either. If we cannot expect any language to give us what we want in arbitrary applications, then we should not create general purpose languages; we should create domain specific languages (there actually is a middle ground on this issue: https://en.wikipedia.org/wiki/Language_oriented_programming).
The equavilent C code to the C++ code is: char * f(void) { if(some_condition) return "Some string"; } ...
do_something(f()); ...
That will always crash.
In fact, it will not always crash, and here is what happens when I run this version of "do_something" on my system:
Which does not crash (at least when compiled with g++ 4.4.6) when some_condition is true or when some_condition is false. On the other hand, using string instead of const char * crashes whenever some_condition is false (which is lucky, because it need not crash). Try it yourself if you do not believe me.
Firstly, it's something that any C OR C++ programmer should do
Then it should be in the standard. If there is no good reason not to do it, then there is no reason for it to be excluded from the standard (for C, you might claim that the goal of portability necessitates a simple compiler; no such excuse can be made for C++, given how complex the language is to begin with).
Secondly, there's the implicit assumption that you'll get C++ programmers who don't know this
Or that you'll get C++ programmers who are more familiar with a different compiler, which has different flags (or maybe one that does not even have such options -- after all, if it is not required, you cannot expect it).
You mean in C++ it is far more likely to notice the undefined behaviour?
No, I mean it is more likely to be noticed long after it was written and committed, after numerous other changes have been committed, and will then require hours of debugging to figure out. Leaving out a return statement from a function that claims to return an object by value may not cause a crash, if the destructor is not virtual and has an empty body; then one day someone makes the destructor virtual and the program starts behaving wrong. The problem is that C++ inserts a lot of extra pointers and function calls, which is what turns undefined behavior into a landmine.
And you do the same thing in C by returning a pointer to a local variable from a function.
Except that a lexical closure is not dealing with a pointer, it is dealing with a reference, which comes with a different set of rules and restrictions. The solution is counter-intuitive (that the lambda should capture variables by value) and makes the code needlessly complex (as you must now use pointers where there was no real need). The solution is also unique to the case where the closure is returned from a function; if it is passed as an argument to a function call, you can capture by reference without a problem.
And as I recall, the default for lambdas is to take its parameters by value, so you explicitly chose to capture by reference to create the lifetime issue
I am pretty sure the default is "no capture," but even if what you are saying is true, capture by value is counterintuitive for a lexical closure. I do not want my own separate copy of the variable, I want the same one as the function call that the expression was returned from. The problem is that in C++, the lexical environment is destroyed when the function returns, rather than when the environment is no longer needed. Yes, this is a consequence of having no garbage collector; the solution is to have a garbage collector, and perhaps to give programmers a standardized way to enable/disable it if C++ programmers really do need to not have GC sometimes (although I suspect that such cases are comparatively few and far between, given that the overwhelming majority of C++ programs are high-level and given how popular smart pointers are).
Unless your constructor was called during the initialization of a global object, in which case the exception cannot be caught anywhere. Although some people think this is a good thing, it is probably not what you actually want to have happen, because you might want to destroy other global objects before you exit.
Does Dr. Joe Researcher make any money selling papers?
Not directly; a researcher might make money by advancing his career, which a well-padded resume might help with, which publishing in top name journals accomplishes. But that is a pretty big stretch, and there is no reason that a resume could not be padded in another system where the papers cannot be copyrighted (or simply are not). Note also that researchers in my own field, where papers are almost always available at no cost, still pad their resumes.
Do the institutions that employ Dr. Joe?
That is even more tenuous. Institutions with researchers that have well-padded resumes do tend to bring in more grant money, because those researchers are more likely to get grants. Again, in my field, people get lots of grant money, despite the fact that their published papers can be downloaded at no cost.
Does any of the money flow back to the source of funding?
Only in the sense that the money I spent on coffee this past week will eventually find its way there.
In the long run, copyrights on scientific research are going to either die or become irrelevant, that's why. That is all that the middle of the road approach has going for it.