I know very well that transfer and licensing are not the same thing. Perhaps that is why I used both terms? Some publishers (e.g. technical journals) depend on outright transfers. Anyway, how can you selectively license something that you don't actually own?
You are asking to deprive them of the hundred years of precedent they have relied on so that the Supreme Court can affirm your radically limited view of what the copyright power means. Your primary reasoning seems to be "it is obviously unconstitutional." Do you really think in the past hundred years that there haven't been any copyright cases before the court? That something so "obvious" would be missed in those cases?
Furthermore, *any* judge can rule a law unconstitutional, although that judgement only serves as precedent in a limited venue. There is no "odd quirk" that you claim. A Supreme Court decision is only needed to create a precedent that acts as the law of the land.
In fact, any ruling of unconstitutionality by a lower court is going to be a very good reason for the Supreme Court to grant certiorari, as different courts having different holdings on constitutionality is a serious problem to be rectified.
No real judge is going to rule the way you want. In the real world, this means your opinion is not legally valid. Expecting the Supreme Court to declare some well-established body of law unconstitutional is not like expecting Linus to include a patch in the kernel.
even when the copyright expires, the authors are not required to "release their works into the public domain".
By definition, those works whose copyrights have expired are in the public domain. You may do anything you wish to the copyrighted material, including reproducing it, translating it, performing it, producing derivative works, etc.
To encourage new works, copyright has to expire before the author dies.
Absolutely not. It is easy to see why not: most authors don't know when they will die. What is true, is that the copyright period has to be long enough that a publisher will see value in paying the author for his work.
Otherwise, elderly or unhealthy authors couldn't get publishers to pay them; the publishers would have more incentive just to wait for the author to starve to death.
You are missing the point. In particular, the qualifying words "in nature" Sure, ideas aren't property in the sense of inherently limited possession. That is why statutory power must be invoked to grant to ideas the legal status that ordinary property has in nature had from the beginning of common law.
Once that statutory power has been used to create copyrights and patents, then the expressions and inventions then *assume* some of the character that naturally pertain to physical property, namely the "exclusive right" that society has chosen to grant!
The extent to which ideas are property is solely and completely due to statute. Society has chosen to create copyright and patent legislation. Hence, *legally speaking*, they are equivalent to property, to the extent that statute provides. Penalties exist for the unlawful use of an idea, just as penalties exist for the unlawful taking of other types of property.
That is that, at least in the US (Disney, the RIAA and MPAA, etc are based in the US), using copyright in this was appears to be outside of the US constitution and thus completly bogus.
Obviously, YANAL. If it were completely bogus, people would not have to argue so strenuously that the new law is unconstitutional. A hundred years of law has been estabished that copyrights are indeed transferable and licensable. How else could publishers publish works for authors? The Constitution does not explicitly mention the concepts of "works for hire" or "fair use" Do you think those are unconstitutional as well?
It is absurd to believe that the Constitution must describe the powers of Congress in such detail. It is absurd for the Constitution to say that Congress has such a power as a legislative body, and then mean that no law regarding that power can be passed that is not explicitly in the Constitution. If it were already in the Constitution, there wouldn't be any need for any statute!!
Two party "duopoly" happens because America has a first-past-the-post voting system, without any proportional representation. Great Britain also has a duopoly, because it has a first-past-the-post system as well.
[The basic fact is that any prospective third party must get a *majority* in some district or state to have any Federal representation at all, and must have nearly a *majority* in one house of Congress to have any real chance of influencing policy. Since by definition, only one party can have a given majority at a given time, everyone left out had better join into a second party, giving the best chance of becoming the majority party in turn.]
As a possible alternative, most countries on the European continent have a list-based voting system with proportional representation, so more than two parties prosper.
In Austria, for example, this means either that far right neo-Nazi types like Joerg Haider can dictate policy to larger right-of-center parties, or that center-left and center-right parties are forced into alliances that mean cozy, easily corruptible, unproductive coexistence preserving the status quo while partitioning out the spoils of government equally between the two parties.
Today in Germany, the essentially far left Green party can dictate policy to the left-of-center party.
Are any of those an improvement over the American state of affairs? Not significantly, if at all.
You speak as though a libertarian-run government would somehow be better, and that a conspiracy between two parties is somehow keeping that from happening. In fact, there are deep structural reasons why only two generally centrist parties exist in the system. Unless you posit some *radical change* in the electoral system, it is pointless blathering.
The DVD reproduction is pretty good, and doesn't degrade. The local super mega-multi-plex hires minimum-wage slobs to run the projectors, and never bothers to teach them to properly clean the gate, so theater prints get seriously worn.
When digital theater projection starts being widespread, this won't be an issue anymore. The expense of delivering heavy prints will be reduced, and it changes the economics of keeping movies for extended runs.
Here, I pay $9.50 (ever rising) to watch a movie in a closet, projected on a screen the size of a bedsheet, where the soundtrack is overwhelmed by the latest Jerry Bruckheimer film in the closet next door. I have to fight over the armrest with my neighbor. And if I don't see a movie in the first three weeks, it gets replaced with some newer one-week wonder. God forbid I want something to eat or drink for less than $3, or want something other than sweet or greasy junk.
At home, I can rent a DVD for $5 or less, watch it in the peace of my living room on a comfortable couch with a number of invited friends, who know to shut up when the dialog is important. In the event anyone needs a break, or covered up the dialog with a laugh, or missed a plot point, we can pause or rewind. I can drink a glass of OJ or wine or beer, with unlimited refills. Popcorn without butter-flavored grease. If my girlfriend and I decide we'd rather make out, we can watch the movie later. If I reallly cared about the ear-shattering soundtracks, I could get a serious surround-sound system.
How can the theater compete?
Re:Which decent games are written in lisp?
on
C
·
· Score: 2
I don't know about decent games (Abuse had a Lisp engine), but systems to develop games certainly have been written in Lisp.
I would suspect that the best breakpoint for run-time efficiency is to have a C or assembly language rendering engine, with Lisp-based game action code. I.e. the dynamic portion that has to be easily changed is in Lisp, the part that has to smash data into registers as fast as possible would be in C or assembly. Of course, commercial Lisps typically have provisions for a Lisp-syntax expression of assembly code, so you can write assembler using Lisp macros...
Re:Why are people still using a 30 year old langua
on
C
·
· Score: 2
So when your customer runs your program for many months and happens to trigger some rare condition that you didn't test, he'll just leak memory, right?
This assumes that your test cases are always exhaustive enough to cover any possible order of reference creation and destruction processes, and have run times long enough to do so.
I'm not blaming my tools, I'm blaming your tools. When I program in Common Lisp, I don't spend a millisecond of my time debugging/preventing memory leaks. You seem to spend days. Which seems like a better use of programmer time?
Re:Why are people still using a 30 year old langua
on
C
·
· Score: 2
Most modern garbage-collected languages can use generational garbage-collection, which, although not hard real-time, generally avoids long pauses, and is very efficient when much garbage is being generated quickly.
The "real" reason you can't get to absolute zero is because of the classical laws of thermodynamics, not quantum fluctuations.
The third law of thermodynamics: "as the temperature approaches absolute zero, the entropy of a closed system approaches a constant which is independent of the system's parameters" is equivalent (given the other laws) to the statement that "a system cannot be brought to absolute zero in any finite number of steps."
These statements do not require quantum mechanics in order to be valid. (They probably require QM to understand why they are true, but that is statistical mechanics, not thermodynamics.)
Re:Why are people still using a 30 year old langua
on
C
·
· Score: 4, Insightful
What makes you think dynamic memory management in C is efficent?
Just because "malloc" and "free" each fit on one line of code doesn't mean they are fast or efficient. In particular, if your memory arena gets seriously fragmented, the performance of these routines can get worse and worse over time.
As opposed to a genuine generational garbage collector, for which the performance stays relatively consistent.
Re:Why are people still using a 30 year old langua
on
C
·
· Score: 1
If you're "man enough" to write a program with no memory leaks, you've probably also written a program that can't function as part of a long-lived dynamic system.
That is, if your program is simple enough that memory allocation can be handled manually, then it probably isn't complicated enough to do anything interesting. Where by "interesting" I mean, can do things with data that are too complicated to get a human brain around without making a mistake---such as running queries against complicated databases for flexible, user-configurable front-end applications.
Why is it that most large projects start out with defining a memory-management subsystem? Why not use a language that has a robust memory management capability built in, and save your presumably valuable time?
For good shielding, you typically need to limit the apertures to something like wavelength/10. That gap is a little slot antenna, which still radiates even when it is smaller than a wavelength.
Also that huge open space where the light comes through probably doesn't shield much of anything.
When one is doing *engineering,* as opposed to typical software development, the person doing the engineering has the responsibility to make sure that they are applying their expertise according to best known practices. If they don't have enough knowledge, they shouldn't do it. An engineer building a bridge without knowing enough about bridge building would be seriously liable for any damages caused. His professor would not be.
Notice that slashdot rarely has discussions on how Microsoft medical devices have more bugs than Linux medical devices. Because people who program with human lives on the line take their job pretty damn seriously. Because there are serious consequences for failure.
Coding on the net has no accountability or consequences for failure. That is not a product of poor instruction, but of the commercial nature of the net.
You appear to have missed the point, which was old software accessing sound cards through HARDWARE. Load all the drivers you want, the old software can't magically understand that there is a software layer involved.
The question is what the professor is teaching about. A physicist would probably feel comfortable teaching about the elastic response of a bridge member. But he would admit he isn't trying to teach you bridge design.
The CS professor mentioned at the beginning of the thread probably wasn't trying to teach how to program in a way that is robust to various kinds of errors, including security errors. He almost certainly was not claiming to.
The problem is when people take the limited knowledge they acquired from the CS professor and apply it in the real world without understanding all the implications of what they are doing. That ain't the professor's fault.
The world would probably be a better place if more computer scientists had actually written the code that is being used to do real world things, because they would have cared more about abstract properties like "correctness" rather than concrete properties like "compiles, doesn't crash." And they wouldn't be programming it in C.
Others are perhaps more qualified to comment on the history, but they've probably moved onto more productive threads;-)
Part of the purpose of Common Lisp was to define a *common* standard for Lisp programmers. The language had branched into a lot of different dialects, each with their own quirks. Some of this was just random evolution, some of it was alternative ideas being explored.
My understanding is that OO was one of the areas where alternative ideas were being explored. There were a large number of OO extensions to Lisp that had been developed (e.g. Flavors) by various groups, and there had to be a reasonably large amount of discussion to determine which approaches were really valuable enough to standardize. CLOS was determined to be powerful enough to accomodate any important feature of the other approaches, so it could be standardized on without crippling some set of programmers.
This is very different than the C++ standardization approach, where, as far as I can tell, only a few people work on new ideas, and test them out in whatever way they feel is appropriate, then it gets thrown to a committee. Common Lisp depended on there being *existing*, *widely used* implementations that behaved in the standard way, so that the quality of the solution was already widely acknowledged.
That means that there is a lot more to many Lisp implementations than the standard discusses (e.g. GUI, network, database support, etc.). The standardization process did *not* include GUI features, for instance, because there is far too much variability between platforms, and because no one model is clearly successful enough to be forced on everyone. However, almost all Common Lisp implementations include GUI support.
The overhead of C++ is still going to be substantial.
Hint: how do you plan on detecting overflow on integer operations? Most processors have flags that you can branch on, but C and C++ don't offer language-level access to that functionality. The results of integer overflow are purposely left *undefined.* As in, no standard way to detect it. Every C implementation I've seen defines it as "silently truncate result and continue," with no way to detect it in the language.
Either you have to include assembly code in your C implementation (there goes portability), or you have to put a lot of tests in your common case to determine when the overflow is going to happen. That's a lot less efficient.
That's why this stuff belongs in the base language--they can do the processor dependent stuff right the first time.
Look, if an object is accessible, it ain't garbage, it's sitting at the end of some pointer, which if you access, you'd better get valid memory.
A "memory leak" is memory that is only accessible through the system's memory manager, but not through any pointers under program control. That is, the program has changed the last pointer that pointed to it so that it points somewhere else, without freeing it. It became garbage, but your program didn't realize it, probably because the "ownership" model made it look like it belonged to someone else. These leaks DO NOT HAPPEN under garbage collection, because the GC scavenges this memory when it is needed.
"Memory leaks" where the memory isn't garbage aren't leaks. They are growing data structures in your program. Sure, if your data structures keep growing, you will consume more and more memory.
Garbage collection is about removing the accounting errors that lead to true memory leaks, which means you can focus your human intelligence on figuring out what resources your program needs to solve the problem it is working on.
So you are talking about roll your own. It is NOT EASY to write a high-performance multi-precision integer solution in C that smoothly integrates with fixed-precision integers and which you can use with the ease of a typedef. It needs to be built in the language from the start, not bolted on afterwards.
If you want true high-performance switching of integer sizes, you need to have the *machine code* tuned for the processor to make the common case fast, and the uncommon case still reasonably fast. You really can't do that in standard C, much less by including the overhead of C++ classes in a roll-your-own implementation. Much better if the person who wrote the compiler wrote it to emit the best code for these cases, then to have to persuade the compiler to change your C into the same code.
And in the case where you want to optimize away the overflow checks, the compiler is a lot more careful in the constraint analysis, and can check *every possibility* *every time*, not just when your gut tells you you should.
If you want to spend your hours acting like a Common Lisp compiler to get robust overflow protection, feel free. But in the 21st century, I'd rather a compiler do the work than have to do it myself.
Look, you guys keep saying "ownership" as if it is the magical solution to memory allocation.
If things were simple enough that you could define a clear policy of "ownership" and stick to it, then you wouldn't leak memory in the first place. Memory leaks happen because the ownership model was not specified clearly enough, or because it wasn't followed, because someone didn't understand all the possibilities that could happen at run time.
Slashdot Mirror
I know very well that transfer and licensing are not the same thing. Perhaps that is why I used both terms? Some publishers (e.g. technical journals) depend on outright transfers. Anyway, how can you selectively license something that you don't actually own?
You are asking to deprive them of the hundred years of precedent they have relied on so that the Supreme Court can affirm your radically limited view of what the copyright power means. Your primary reasoning seems to be "it is obviously unconstitutional." Do you really think in the past hundred years that there haven't been any copyright cases before the court? That something so "obvious" would be missed in those cases?
Furthermore, *any* judge can rule a law unconstitutional, although that judgement only serves as precedent in a limited venue. There is no "odd quirk" that you claim. A Supreme Court decision is only needed to create a precedent that acts as the law of the land.
In fact, any ruling of unconstitutionality by a lower court is going to be a very good reason for the Supreme Court to grant certiorari, as different courts having different holdings on constitutionality is a serious problem to be rectified.
No real judge is going to rule the way you want. In the real world, this means your opinion is not legally valid. Expecting the Supreme Court to declare some well-established body of law unconstitutional is not like expecting Linus to include a patch in the kernel.
even when the copyright expires, the authors are not required to "release their works into the public domain".
By definition, those works whose copyrights have expired are in the public domain. You may do anything you wish to the copyrighted material, including reproducing it, translating it, performing it, producing derivative works, etc.
To encourage new works, copyright has to expire before the author dies.
Absolutely not. It is easy to see why not: most authors don't know when they will die. What is true, is that the copyright period has to be long enough that a publisher will see value in paying the author for his work.
Otherwise, elderly or unhealthy authors couldn't get publishers to pay them; the publishers would have more incentive just to wait for the author to starve to death.
You are missing the point. In particular, the qualifying words "in nature" Sure, ideas aren't property in the sense of inherently limited possession. That is why statutory power must be invoked to grant to ideas the legal status that ordinary property has in nature had from the beginning of common law.
Once that statutory power has been used to create copyrights and patents, then the expressions and inventions then *assume* some of the character that naturally pertain to physical property, namely the "exclusive right" that society has chosen to grant!
The extent to which ideas are property is solely and completely due to statute. Society has chosen to create copyright and patent legislation. Hence, *legally speaking*, they are equivalent to property, to the extent that statute provides. Penalties exist for the unlawful use of an idea, just as penalties exist for the unlawful taking of other types of property.
That is that, at least in the US (Disney, the RIAA and MPAA, etc are based in the US), using copyright in this was appears to be outside of the US constitution and thus completly bogus.
Obviously, YANAL. If it were completely bogus, people would not have to argue so strenuously that the new law is unconstitutional. A hundred years of law has been estabished that copyrights are indeed transferable and licensable. How else could publishers publish works for authors? The Constitution does not explicitly mention the concepts of "works for hire" or "fair use" Do you think those are unconstitutional as well?
It is absurd to believe that the Constitution must describe the powers of Congress in such detail. It is absurd for the Constitution to say that Congress has such a power as a legislative body, and then mean that no law regarding that power can be passed that is not explicitly in the Constitution. If it were already in the Constitution, there wouldn't be any need for any statute!!
Two party "duopoly" happens because America has a first-past-the-post voting system, without any proportional representation. Great Britain also has a duopoly, because it has a first-past-the-post system as well.
[The basic fact is that any prospective third party must get a *majority* in some district or state to have any Federal representation at all, and must have nearly a *majority* in one house of Congress to have any real chance of influencing policy. Since by definition, only one party can have a given majority at a given time, everyone left out had better join into a second party, giving the best chance of becoming the majority party in turn.]
As a possible alternative, most countries on the European continent have a list-based voting system with proportional representation, so more than two parties prosper.
In Austria, for example, this means either that far right neo-Nazi types like Joerg Haider can dictate policy to larger right-of-center parties, or that center-left and center-right parties are forced into alliances that mean cozy, easily corruptible, unproductive coexistence preserving the status quo while partitioning out the spoils of government equally between the two parties.
Today in Germany, the essentially far left Green party can dictate policy to the left-of-center party.
Are any of those an improvement over the American state of affairs? Not significantly, if at all.
You speak as though a libertarian-run government would somehow be better, and that a conspiracy between two parties is somehow keeping that from happening. In fact, there are deep structural reasons why only two generally centrist parties exist in the system. Unless you posit some *radical change* in the electoral system, it is pointless blathering.
Oh, yeah, one more thing---
The DVD reproduction is pretty good, and doesn't degrade. The local super mega-multi-plex hires minimum-wage slobs to run the projectors, and never bothers to teach them to properly clean the gate, so theater prints get seriously worn.
When digital theater projection starts being widespread, this won't be an issue anymore. The expense of delivering heavy prints will be reduced, and it changes the economics of keeping movies for extended runs.
Where the hell do you live?
Here, I pay $9.50 (ever rising) to watch a movie in a closet, projected on a screen the size of a bedsheet, where the soundtrack is overwhelmed by the latest Jerry Bruckheimer film in the closet next door. I have to fight over the armrest with my neighbor. And if I don't see a movie in the first three weeks, it gets replaced with some newer one-week wonder. God forbid I want something to eat or drink for less than $3, or want something other than sweet or greasy junk.
At home, I can rent a DVD for $5 or less, watch it in the peace of my living room on a comfortable couch with a number of invited friends, who know to shut up when the dialog is important. In the event anyone needs a break, or covered up the dialog with a laugh, or missed a plot point, we can pause or rewind. I can drink a glass of OJ or wine or beer, with unlimited refills. Popcorn without butter-flavored grease. If my girlfriend and I decide we'd rather make out, we can watch the movie later. If I reallly cared about the ear-shattering soundtracks, I could get a serious surround-sound system.
How can the theater compete?
I don't know about decent games (Abuse had a Lisp engine), but systems to develop games certainly have been written in Lisp.
I would suspect that the best breakpoint for run-time efficiency is to have a C or assembly language rendering engine, with Lisp-based game action code. I.e. the dynamic portion that has to be easily changed is in Lisp, the part that has to smash data into registers as fast as possible would be in C or assembly. Of course, commercial Lisps typically have provisions for a Lisp-syntax expression of assembly code, so you can write assembler using Lisp macros...
So when your customer runs your program for many months and happens to trigger some rare condition that you didn't test, he'll just leak memory, right?
This assumes that your test cases are always exhaustive enough to cover any possible order of reference creation and destruction processes, and have run times long enough to do so.
I'm not blaming my tools, I'm blaming your tools. When I program in Common Lisp, I don't spend a millisecond of my time debugging/preventing memory leaks. You seem to spend days. Which seems like a better use of programmer time?
There are real-time garbage collectors, which are guaranteed to not take longer than a fixed time.
Most modern garbage-collected languages can use generational garbage-collection, which, although not hard real-time, generally avoids long pauses, and is very efficient when much garbage is being generated quickly.
Malloc and free are generally not hard real-time.
Try reading the Garbage Collection FAQ
The "real" reason you can't get to absolute zero is because of the classical laws of thermodynamics, not quantum fluctuations.
The third law of thermodynamics: "as the temperature approaches absolute zero, the entropy of a closed system approaches a constant which is independent of the system's parameters" is equivalent (given the other laws) to the statement that "a system cannot be brought to absolute zero in any finite number of steps."
These statements do not require quantum mechanics in order to be valid. (They probably require QM to understand why they are true, but that is statistical mechanics, not thermodynamics.)
What makes you think dynamic memory management in C is efficent?
Just because "malloc" and "free" each fit on one line of code doesn't mean they are fast or efficient. In particular, if your memory arena gets seriously fragmented, the performance of these routines can get worse and worse over time.
As opposed to a genuine generational garbage collector, for which the performance stays relatively consistent.
If you're "man enough" to write a program with no memory leaks, you've probably also written a program that can't function as part of a long-lived dynamic system.
That is, if your program is simple enough that memory allocation can be handled manually, then it probably isn't complicated enough to do anything interesting. Where by "interesting" I mean, can do things with data that are too complicated to get a human brain around without making a mistake---such as running queries against complicated databases for flexible, user-configurable front-end applications.
Why is it that most large projects start out with defining a memory-management subsystem? Why not use a language that has a robust memory management capability built in, and save your presumably valuable time?
For good shielding, you typically need to limit the apertures to something like wavelength/10. That gap is a little slot antenna, which still radiates even when it is smaller than a wavelength.
Also that huge open space where the light comes through probably doesn't shield much of anything.
I doubt this case would get past the FCC.
No, the problem is not in instruction.
When one is doing *engineering,* as opposed to typical software development, the person doing the engineering has the responsibility to make sure that they are applying their expertise according to best known practices. If they don't have enough knowledge, they shouldn't do it. An engineer building a bridge without knowing enough about bridge building would be seriously liable for any damages caused. His professor would not be.
Notice that slashdot rarely has discussions on how Microsoft medical devices have more bugs than Linux medical devices. Because people who program with human lives on the line take their job pretty damn seriously. Because there are serious consequences for failure.
Coding on the net has no accountability or consequences for failure. That is not a product of poor instruction, but of the commercial nature of the net.
You appear to have missed the point, which was
old software accessing sound cards through HARDWARE. Load all the drivers you want, the old software can't magically understand that there is a software layer involved.
The question is what the professor is teaching about. A physicist would probably feel comfortable teaching about the elastic response of a bridge member. But he would admit he isn't trying to teach you bridge design.
The CS professor mentioned at the beginning of the thread probably wasn't trying to teach how to program in a way that is robust to various kinds of errors, including security errors. He almost certainly was not claiming to.
The problem is when people take the limited knowledge they acquired from the CS professor and apply it in the real world without understanding all the implications of what they are doing. That ain't the professor's fault.
The world would probably be a better place if more computer scientists had actually written the code that is being used to do real world things, because they would have cared more about abstract properties like "correctness" rather than concrete properties like "compiles, doesn't crash." And they wouldn't be programming it in C.
Others are perhaps more qualified to comment on the history, but they've probably moved onto more productive threads ;-)
Part of the purpose of Common Lisp was to define a *common* standard for Lisp programmers. The language had branched into a lot of different dialects, each with their own quirks. Some of this was just random evolution, some of it was alternative ideas being explored.
My understanding is that OO was one of the areas where alternative ideas were being explored. There were a large number of OO extensions to Lisp that had been developed (e.g. Flavors) by various groups, and there had to be a reasonably large amount of discussion to determine which approaches were really valuable enough to standardize. CLOS was determined to be powerful enough to accomodate any important feature of the other approaches, so it could be standardized on without crippling some set of programmers.
This is very different than the C++ standardization approach, where, as far as I can tell, only a few people work on new ideas, and test them out in whatever way they feel is appropriate, then it gets thrown to a committee. Common Lisp depended on there being *existing*, *widely used* implementations that behaved in the standard way, so that the quality of the solution was already widely acknowledged.
That means that there is a lot more to many Lisp implementations than the standard discusses (e.g. GUI, network, database support, etc.). The standardization process did *not* include GUI features, for instance, because there is far too much variability between platforms, and because no one model is clearly successful enough to be forced on everyone. However, almost all Common Lisp implementations include GUI support.
I said "C" several times in the parent post where I meant "C and/or C++"; from my perspective, they are equally broken in this area.
The overhead of C++ is still going to be substantial.
Hint: how do you plan on detecting overflow on integer operations? Most processors have flags that you can branch on, but C and C++ don't offer language-level access to that functionality. The results of integer overflow are purposely left *undefined.* As in, no standard way to detect it. Every C implementation I've seen defines it as "silently truncate result and continue," with no way to detect it in the language.
Either you have to include assembly code in your C implementation (there goes portability), or you have to put a lot of tests in your common case to determine when the overflow is going to happen. That's a lot less efficient.
That's why this stuff belongs in the base language--they can do the processor dependent stuff right the first time.
Look, if an object is accessible, it ain't garbage, it's sitting at the end of some pointer, which if you access, you'd better get valid memory.
A "memory leak" is memory that is only accessible through the system's memory manager, but not through any pointers under program control. That is, the program has changed the last pointer that pointed to it so that it points somewhere else, without freeing it. It became garbage, but your program didn't realize it, probably because the "ownership" model made it look like it belonged to someone else. These leaks DO NOT HAPPEN under garbage collection, because the GC scavenges this memory when it is needed.
"Memory leaks" where the memory isn't garbage aren't leaks. They are growing data structures in your program. Sure, if your data structures keep growing, you will consume more and more memory.
Garbage collection is about removing the accounting errors that lead to true memory leaks, which means you can focus your human intelligence on figuring out what resources your program needs to solve the problem it is working on.
"You can build..."
So you are talking about roll your own. It is NOT EASY to write a high-performance multi-precision integer solution in C that smoothly integrates with fixed-precision integers and which you can use with the ease of a typedef. It needs to be built in the language from the start, not bolted on afterwards.
If you want true high-performance switching of integer sizes, you need to have the *machine code* tuned for the processor to make the common case fast, and the uncommon case still reasonably fast. You really can't do that in standard C, much less by including the overhead of C++ classes in a roll-your-own implementation. Much better if the person who wrote the compiler wrote it to emit the best code for these cases, then to have to persuade the compiler to change your C into the same code.
And in the case where you want to optimize away the overflow checks, the compiler is a lot more careful in the constraint analysis, and can check *every possibility* *every time*, not just when your gut tells you you should.
If you want to spend your hours acting like a Common Lisp compiler to get robust overflow protection, feel free. But in the 21st century, I'd rather a compiler do the work than have to do it myself.
Man, this parent says it all. MOD UP!
Look, you guys keep saying "ownership" as if it is the magical solution to memory allocation.
If things were simple enough that you could define a clear policy of "ownership" and stick to it, then you wouldn't leak memory in the first place. Memory leaks happen because the ownership model was not specified clearly enough, or because it wasn't followed, because someone didn't understand all the possibilities that could happen at run time.