Well, it is correct that rocket engines often use Hydrogen/Oxygen as it has the best specific impulse, but it is not impossible to use hydrocarbons instead of hydrogen.
E.g. see this:
http://en.wikipedia.org/wiki/Kerosene#Transportation
Well, maybe it is just me, but IF future generations are going back to stone age rather than to stars, I just do not care about them. In that case, humanity failed and should leave.
And as for the possibility of development of other sapient species, 10.000 years is nothing.
CISC-to-RISC translation is mostly PR term.
uops executed by OOO x86 cores are quite unsimilar to RISC opcodes - unless you have RISC consuming 100+ bits per single intruction..
Well, if you want to see human settlements off this planet, you definitely should be happy about this direction.
The Moon is the most stupid place to settle. The real settlements are much better on orbit and asteroids are much better way how to obtain resources to build them.
The idea that we should be living on Moon or Mars is the most stupid one. Why, once we leave that deep gravity well, should we bound ourselves to another one? All resources we need are sun for energy and matter from asteroids.
Also, if you do want to have any chance of long term settlement, Moon or Mars are bad too - too low gravity, say bye bye to bones and muscles. Which is much more easily solved on orbit again...
So I've been running Vista for about a week so far, with heavy use both plugged in and on battery, and I have to say this (in bold in italics so you get the idea of how surprising this was to me... ) I'm pretty impressed with Vista.
Well, report back after a month. I too was quite happy with Vista in the first week, but finally downgraded after a month.
I like Aero and new fileselector, but besides that, I really do not see what advantages Vista brings. I have met a lot of disadvantages though... (e.g.: No SPX/IPX support, Vista locks my user account in Win2003 domain, C++ build process 15% slower than in XP on the same hardware...).
My finally block has little to nothing to do with the GC other than the scope. I (as a programmer) use the finally block to deal with non-memory resources.
Well, maybe you could try a language where resource management is really automatic for a change (C++):)
So i take your point.. I just wouldn't put things quite that way.
Fair enough. Thanks for interesting chat.
Nope. What I say is that memory is resource manageable by destructor. That is not the same thing. Whereas non-memory resource are NOT manageable by GC. Therefore, GC based language needs "finally". Finally does not imply GC, but GC with exception handling implies "finally".
BTW, I am not even advocating C++ over GC languages. I am not commenting about the fault in the application. I am only responding to your comment that "finally" has nothing to do with GC. It has. Almost everything;)
Well, ok. Look at what you have written: GC - manages memory. Destructor - manages resources. That is exactly the point. In Java/C#, you need finally, because there is no other way how to do it. The whole language structure and usage is based on using GC.
And no, you cannot really have safe destructors in GC language. I mean, you can try, but the whole mess will likely be unmanagable and way error prone. And finalizers are not destructors by a long shot - they are asynchronous.
I guess you misundrestood a bit the issue.
I do not say that finally is there to release references, so that GC can collect. No.
The finally is there because you need to release non-memory resources in case of exception.
Sure, only C++ provides an alternative solution to the problem - destructors, OTOH C++ is accidentally the only currect alternative for C#/Java. And the concept of destructors is incompatible with GC (synchronous vs asynchronouse problem).
That is the why C++ can do withou finally, while C#/Java cannot.
(Summary: GC -> destructors not possible -> we need "finally" to release non-memory resources. Therefore: "Finally have everything to do with GC".).
Unfortunately parent and the parent-parent have clearly never actually written anything of significance with a GC language. Using and try-finally have little to do with GC btw.
Wrong, it has everything to do with GC.
GC is mutually exclusive with concept of destructors, therefore GC collected language needs other means than scope based destruction to free resources in case of exception.
That is why Java has "finally" and C++ not.
XP won't run on it because Intel doesn't make (a working set of)drivers for the board's SATA controller. Not for XP. I tried Professional, Home, and even Server 2003 to make sure. Won't run. Bluescreens before you see the GUI. Tried both pre and post DRM versions (Original, SP1, and SP2 ++DRM). No XP "love". Looked on their website and they sorta support XP, but couldn't find a way to order one with that OS. (I was going to order one, clone the HD's magic partition, and take it back.)
That is a trivial problem to solve, just turn off the "Native SATA" mode in BIOS. Performance difference is negligible (you only loose NCQ, which benefits on dekstops are debatable anyway) and you will be able to install/run XP out of box.
The interesting part about global warming and heating houses is that global warming in fact reduces heating costs. I guess, if we presume that it is indeed CO2 that causes global warming, there can be a sort of negative feedback -> higher temperatures, less CO2 produced by heating houses.
Frankly, I might be alone, but has anybody ever considered that global warming can in fact be a GOOD THING? Who needs cold winters, anyway?
On the opposite side, global warming hype is good for technology. We might see much needed new nuclear plants and electric vehicles boom soon.
You are missing the point. You can have container library in C++ that allows storing objects directly. Technically, it is simple. Even boost has one (see ptr_vector etc...). The problem of STL is value semantics. Problem of C++ is STL.
Personally, you pick Ruby. Personally, I still pick C++ *for productivity reasons* (despite superior performance:-).
Many GC systems have a notion of "finalization." An object may be registered with the GC system so that when it is about to reclaim the object, it runs a function on the object that can perform necessary cleanups. Finalization is tricky. Some of the issues are:
1. When can an object actually be finalized? This is trickier than it first appears in the presence of some normally-desirable optimizing transformations.
2. In what thread, resource, or security context does a finalization function run?
3. What happens when registered objects reference each other?
4. What happens if a finalization function makes an object not be garbage any more?
Now add one special to this list: Destructors were not designed as finalizers in the first place....
Well, that is probably better of two bad solutions and it is what M$ done in managed C++. One of disadvantages is that it hides a lot of hard to spot bugs. With generational collectors, forgetting to release resource will be in 99.9% hidden by GC, but in 0.1% will cause deadlock.
Destructors are no problem for GC in C++: if you want determinism, don't allocate the objects on the heap, allocate them on the stack.
Yes, that is naive solution. But that does mean that you cannot use objects with destructors as member attributes of GC collected objects. Think e.g.
struct MyFoo {
int x;
istream bar;
};
Now what? Will you call bar's destructor at sweep phase? Or are you going to disallow putting objects with destructors to GC?
What to say? I have to agree with all points, except the last one;)
Maybe you have not noticed, but U++ is C++ platform. And I have noticed that model of execution of C++ is superior. That is one of reason we are using C++, is not it?
What most people have not noticed is fact that C++ can be used in a way that makes it superior even in productivity. That is what U++ is about.
Slashdot Mirror
Well, it is correct that rocket engines often use Hydrogen/Oxygen as it has the best specific impulse, but it is not impossible to use hydrocarbons instead of hydrogen. E.g. see this: http://en.wikipedia.org/wiki/Kerosene#Transportation
Where are you going to get oxygen to burn the oil with?
What makes me wonder is what these pools of hydrocarbons on Titan say about 'debunked' theory of abiogenic oil.... http://en.wikipedia.org/wiki/Abiogenic_petroleum_origin
Well, maybe it is just me, but IF future generations are going back to stone age rather than to stars, I just do not care about them. In that case, humanity failed and should leave. And as for the possibility of development of other sapient species, 10.000 years is nothing.
CISC-to-RISC translation is mostly PR term. uops executed by OOO x86 cores are quite unsimilar to RISC opcodes - unless you have RISC consuming 100+ bits per single intruction..
Well, it is because for too many programmers, programming is not a job or way how to make money, but passion, fun, entertainment.
:)
Actually, perhaps some of us would actually PAY to be allowed to do it
Well, if you want to see human settlements off this planet, you definitely should be happy about this direction. The Moon is the most stupid place to settle. The real settlements are much better on orbit and asteroids are much better way how to obtain resources to build them. The idea that we should be living on Moon or Mars is the most stupid one. Why, once we leave that deep gravity well, should we bound ourselves to another one? All resources we need are sun for energy and matter from asteroids. Also, if you do want to have any chance of long term settlement, Moon or Mars are bad too - too low gravity, say bye bye to bones and muscles. Which is much more easily solved on orbit again...
So I've been running Vista for about a week so far, with heavy use both plugged in and on battery, and I have to say this (in bold in italics so you get the idea of how surprising this was to me... ) I'm pretty impressed with Vista. Well, report back after a month. I too was quite happy with Vista in the first week, but finally downgraded after a month. I like Aero and new fileselector, but besides that, I really do not see what advantages Vista brings. I have met a lot of disadvantages though... (e.g.: No SPX/IPX support, Vista locks my user account in Win2003 domain, C++ build process 15% slower than in XP on the same hardware...).
Well, maybe you could try a language where resource management is really automatic for a change (C++) :)
So i take your point.. I just wouldn't put things quite that way.
Fair enough. Thanks for interesting chat.
BTW, I am not even advocating C++ over GC languages. I am not commenting about the fault in the application. I am only responding to your comment that "finally" has nothing to do with GC. It has. Almost everything ;)
And no, you cannot really have safe destructors in GC language. I mean, you can try, but the whole mess will likely be unmanagable and way error prone. And finalizers are not destructors by a long shot - they are asynchronous.
I guess you misundrestood a bit the issue. I do not say that finally is there to release references, so that GC can collect. No. The finally is there because you need to release non-memory resources in case of exception. Sure, only C++ provides an alternative solution to the problem - destructors, OTOH C++ is accidentally the only currect alternative for C#/Java. And the concept of destructors is incompatible with GC (synchronous vs asynchronouse problem). That is the why C++ can do withou finally, while C#/Java cannot. (Summary: GC -> destructors not possible -> we need "finally" to release non-memory resources. Therefore: "Finally have everything to do with GC".).
Unfortunately parent and the parent-parent have clearly never actually written anything of significance with a GC language. Using and try-finally have little to do with GC btw. Wrong, it has everything to do with GC. GC is mutually exclusive with concept of destructors, therefore GC collected language needs other means than scope based destruction to free resources in case of exception. That is why Java has "finally" and C++ not.
XP won't run on it because Intel doesn't make (a working set of)drivers for the board's SATA controller. Not for XP. I tried Professional, Home, and even Server 2003 to make sure. Won't run. Bluescreens before you see the GUI. Tried both pre and post DRM versions (Original, SP1, and SP2 ++DRM). No XP "love". Looked on their website and they sorta support XP, but couldn't find a way to order one with that OS. (I was going to order one, clone the HD's magic partition, and take it back.) That is a trivial problem to solve, just turn off the "Native SATA" mode in BIOS. Performance difference is negligible (you only loose NCQ, which benefits on dekstops are debatable anyway) and you will be able to install/run XP out of box.
In other words, Microsoft tried to "fix" something that wasn't broken.
Actually, this is the most accurate definition of Windows Vista...
The interesting part about global warming and heating houses is that global warming in fact reduces heating costs. I guess, if we presume that it is indeed CO2 that causes global warming, there can be a sort of negative feedback -> higher temperatures, less CO2 produced by heating houses. Frankly, I might be alone, but has anybody ever considered that global warming can in fact be a GOOD THING? Who needs cold winters, anyway? On the opposite side, global warming hype is good for technology. We might see much needed new nuclear plants and electric vehicles boom soon.
Well, there are many things you got wrong (e.g. ptr_vector exposes objects, not pointers, memory allocation can have zero overhead, at least in U++ it has, etc...), but this is a little bit dead thread. I welcome you to discuss this issue in this somewhat related thread: http://www.ultimatepp.org/forum/index.php?t=msg&th =1738&start=0&S=a60a17415da420a4cd756711de199c23
Mirek
Personally, you pick Ruby. Personally, I still pick C++ *for productivity reasons* (despite superior performance :-).
Of std::vector > over
with manual deletes.
Slashdot ate parts of your text... Yes, sorry,
vs.
.I have to learn to use preview...
Do you think std::vector > is easier to use and maintain than std::vector?
Many GC systems have a notion of "finalization." An object may be registered with the GC system so that when it is about to reclaim the object, it runs a function on the object that can perform necessary cleanups. Finalization is tricky. Some of the issues are:
1. When can an object actually be finalized? This is trickier than it first appears in the presence of some normally-desirable optimizing transformations.
2. In what thread, resource, or security context does a finalization function run? 3. What happens when registered objects reference each other?
4. What happens if a finalization function makes an object not be garbage any more?
Now add one special to this list: Destructors were not designed as finalizers in the first place....
Well, that is probably better of two bad solutions and it is what M$ done in managed C++. One of disadvantages is that it hides a lot of hard to spot bugs. With generational collectors, forgetting to release resource will be in 99.9% hidden by GC, but in 0.1% will cause deadlock.
'shared_ptr' is all about sacrificing performance (and productivity). 'Pointer containers' is really the way to go, but too little too late. Mirek
Destructors are no problem for GC in C++: if you want determinism, don't allocate the objects on the heap, allocate them on the stack. Yes, that is naive solution. But that does mean that you cannot use objects with destructors as member attributes of GC collected objects. Think e.g. struct MyFoo { int x; istream bar; }; Now what? Will you call bar's destructor at sweep phase? Or are you going to disallow putting objects with destructors to GC?
What to say? I have to agree with all points, except the last one ;)
Maybe you have not noticed, but U++ is C++ platform. And I have noticed that model of execution of C++ is superior. That is one of reason we are using C++, is not it?
What most people have not noticed is fact that C++ can be used in a way that makes it superior even in productivity. That is what U++ is about.