Thank you! I didn't even know that something like that existed!! Interesting read. The earliest I've known about was OS/400's TIMI (VM with integrated database). In '92, I was working on a database/language integrated system and found only Lotus Notes to be somewhat similar. Great that we have access to the Web now and can access all that information that was rotting somewhere in libraries before. Not to mention all the possibilities for communication that we have now!:) - It's a shame those "ancient" technologies have not been picked up by the mainstream OS developers yet. There's been a lot of good stuff in the '60ies already. I'll certainly work to bring back some of these things into the mainstream if I can...
No one has come up with the "database driven file systems" we were all promised years ago
This has been one of my research projects for 16 years. Recently, I've published a library that can be used for implementing one. It doesn't suffer from the same problems as earlier prototypes (that I didn't publish b/c they had limited use, but I might anyway someday). Most notably, because it's written in C++ with portability in mind, it possesses quite some powerful abilities. I have some even more powerful concepts ready that I might integrate into the library one day.
You should read the whole thread, not just a few posts. He DOES explain some of the concepts in his android. Also, you're wrong about saying something like that never existed before: There are hundreds of projects like this, most of them happen in Japan. The problem is that none of those development groups ever work together. Instead, they all independently try to build the first real android. Aiko's inventor has come very far, but he'll need a lot of more funds and time to complete the project.
His way of writing software is the same as that of many software companies: They try to keep the thing undocumented to make theft of source code futile. Instead, Aiko's inventor should open-source his effort, no matter how bad the code is. Other groups could benefit from his work. He could work with other groups to get some of their insights and knowledge. Sharing of information would get androids to market far quicker than all those isolated efforts.
... this thread clearly shows us who we will purchase our robots from. Apparently the West is oblivious to employment opportunities. Aiko is just one of hundreds of similar projects to create humanoid robots to assist people in the household. Yeah... what a dumb idea... a household robot, who could ever need that? Now guess where most of the development happens...
The fact that most people write bad code in a language (i.e. they use a bad dialect) is no good reason not to write good code in that language. Because such bad code exists doesn't necessarily mean you have to make your code around it.
In principle, that might be true; However, in practice, when working for an employer, you have to make compromises. Like adding code to prevent long unnecessary debugging sessions. (That's a good idea even when you're just coding for yourself; It can save a lot of time.)
I already said it was fairly useless and what it needed to become very useful. It's just a few lines to show you what RAII is like, because whatever you might boast it was obvious you needed to be given an example.
Well, as I already said, I've been employing those principles for over 12 years already.
I've written my first auto-pointer classes in 1996
Which was necessarily defective. std::auto_ptr sucks hard, that's why it's being deprecated.
Well, you haven't seen my auto pointer classes. They are totally unrelated to the STL.
Besides, in 1996, the STL was nothing more than a proposal, and there wasn't even a usable implementation.
std::unique_ptr, its replacement, is better, but still not perfect in my opinion since it takes a pointer and not an object;
The purpose of such classes is to provide automatic cleanup for pointers. Hence, only a pointer makes sense in that case.
When talking about what code should be like I'd rather use the ideal solutions, even if few compilers implement them, rather than ugly workarounds.
That's your choice, but it makes you seem more like a language lawyer than a programmer. Seeing the practical side of things is paramount to programming however. You're doing yourself no favour.
As you can see, you're doing delete outside of a destructor.
It is clear from your code you understood nothing of the ownership issues I took time to explain to you. You also probably didn't read up on RAII or exception-safety, since your code is not conforming to those principles, and is thus garbage.
It's an example of real-world garbage, in a shortened form. That's the whole point. In the real world, many programmers don't know anything about the principles you're talking about. And that's the problem!
You appear to live in an ivory tower.
The "= delete" you consider to be a syntax error is a feature of the new yet-to-be-finalized C++ standard (known as C++0x) which allows deleting of member functions that are defined by default.
I already suspected that, but it's still considered to be a syntax error by the compiler I'm using, GCC 4.3.2.
It also doesn't conform to the current ISO C++ standard.
You cannot write code that uses fantasy features of yet-to-be-defined standards.
That makes you appear as dislodged from reality as in some other statements you made.
I chose here to make the object non-copyable and non-assignable for the sake of simplicity.
In fact, that class appears to be very wacky. If I ever came across such code, I would rewrite it for clarity.
I've written my first auto-pointer classes in 1996, and automatic container classes (for stack-based usage) even earlier.
The way to do that in C++03 is usually to redeclare them and make them private, not providing the definition. I thought you might not understand such basic techniques, so I chose to use a way that conveyed the intent better.
Instead you used a piece of fantasy code for a fantasy compiler. How smart! Now you're the epitome of a C++ programmer!
Ok, let's give an example to you about that pointer that cannot be accessed.
This is of course a fairly useless object (albeit if you add move, swap and inplace construction support, it then becomes quite useful).
Incredibly enough, once the destructor of scoped_obj has been called, there is no way to access ptr anymore. So there is no reason to set it to null.
Writing ~scoped_obj() { delete ptr; ptr = 0; } would just be silly.
Ah, so writing:
struct A {
int b;
inline A() { b = 0; }
inline A( const A& a ) { b = a.b; }
};
A aa;
scoped_obj<A>* a = new scoped_obj<A>( aa );
delete a;
(*a)->b = 135;
would not result in a problem? *scratches head*
Methinks you've overlooked something.
Understand that simple point now? And since C++ code should follow RAII, resource reclamations should look like this (be done in destructors).
Yeah, yeah, the principle is okay, I didn't doubt that. And I didn't doubt your C++ skills until now.
It is clear you understand very little of what I'm talking about, which is probably linked to your complete lack of modern C++ knowledge, so I'll just stop there.
I suspect it's just the other way around.
It seems your problem with C++ is that it doesn't refuse bad code at compile-time. Well, I wish you good luck with programming then. Even Haskell is no panacea on those terms.
Well, I've fixed bugs written by people like you, and frankly, I wouldn't want to be on the same team with you. You've got a lot to learn.
I don't really see how making objects stateless brings any direct help to parallel programming; sure, that means concurrent read accesses are allowed, but that doesn't parallelize the code.
Stateless objects do not have state, and hence are similar to real constness (which is isn't guaranteed in C++). In a concurrent scenario, yes, concurrent reads would be possible without the need of a mutex semaphore. In a team development setting, true constness with no loopholes would guarantee that a modification cannot interfere with object state.
Stateless as in "undefined value" would have advantages in some settings. Sadly, C++ doesn't provide that either.
But that is your choice.
In a team setting, programming guidelines need to be established and followed; but some companies don't want that.
Spaghetti code is not permitted by the standard idioms.
But it is permitted by the compiler. And hence, you have no guarantees against it. Spaghetti code is a reality of real-word projects, a nightmare that too often comes true...
Many companies don't even have internal documentation for their projects ("the source is the documentation"), and the source-code is ever-changing.
That's why companies are moving away from the "problematic" C++ to C#, for instance. Not that they'd realize that you can write spaghetti code in any language...
Setting member variables to 0 in a destructor for instance is important to avoid memory corruption and to detect when a pointer is accessed after an object is already destroyed
As I already told you, the pointer doesn't exist anymore once the destructor has been called.
It cannot be accessed anymore. It is just useless to modify its value.
You're very wrong about this. Simply disassemble some code that accesses memory after it is freed, and not only does the compiler not complain about it, but it also generates code that faithfully accesses the pointer to the memory that has already been freed.
Say, you have used the "new" operator to allocate an object of class X and assigned it to a pointer variable called "px". A debugger or printf()-statement or whatever you choose outputs the pointer variable as "0xbfec00", for instance. Now you call the delete operator on "px". Then, you output the pointer again, and... surprise, surprise, you'll still see "0xbfec00" in the "px" variable. That's why it is a good idea to set it to "0" especially when there's a risk that the variable might be reused later on.
In the light of multithreading, some programmers do not understand that they MUST NOT access memory from two threads at once. That leads to horrible forms of spaghetti code when they try to program around crash scenarios. This leads to programs that crash differently with timing variations. That's why it is important to use mutexes correctly in multithreading code. That's why setting pointers to null pointers can become critical in detecting programming errors.
Sorry, but I don't really see the link between null pointers and concurrency. Moreover, concurrent reads certainly are valid with most concurrency memory models.
Null pointers are crash triggers for badly-written programs. That's called "crash accelerator". If some multithreaded code unprotectedly accesses objects that are already freed, an exception is caused immediately, instead of continuing processing until the condition escalates.
You seem to be indulged in theory... I can tell you that no theory is going to protect you against the realities of real-world applications, especially if you aren't working alone.
If you've ever debugged an application for two weeks straight, just to find out that some moron has accessed memory after it was already freed, th
In C and C++, constness can be cast away at the programmer's whim (using either a C++ const_cast<> operator or a regular C cast operator). Also, fields declared "mutable" in C++ can be modified even in constant context. That's why "const" is not a "stateless" modifier in C and C++.
Of course, it's up to you to decide what your object should allow when constant. It's up to you to maintain the right invariants and semantics, which are what modeling resources and values as objects is for.
Sadly, formal object modelling isn't used by many companies. Most corporate code is more akin to spaghetti code. The more people have worked on it, the greater the mess you'll find when you look at it.
The good practices of C++ are to *not* use pointers, only perform resource reclamation in destructors (which means setting the pointer to null after freeing is useless, since the pointer doesn't exist any more),
Setting member variables to 0 in a destructor for instance is important to avoid memory corruption and to detect when a pointer is accessed after an object is already destroyed. If there's even the slightest chance of a dangling pointer (or reference, for that matter), it's always good to set things to sane values before leaving a function. Otherwise, the slightest programming error can corrupt swathes of memory.
In the light of multithreading, some programmers do not understand that they MUST NOT access memory from two threads at once. That leads to horrible forms of spaghetti code when they try to program around crash scenarios. This leads to programs that crash differently with timing variations. That's why it is important to use mutexes correctly in multithreading code.
That's why setting pointers to null pointers can become critical in detecting programming errors.
and not use useless "empty" states when it doesn't make sense, because they're usually dangerous states with limited possibilities (it mostly makes sense only for dynamically-sized collections).
WTF are you talking about?! The usage of state information is always highly application dependent.
No, that's largely correct, but it's not that much of a difference. If a compiler knows how to handle parallelism, handling threads isn't much extra overhead. Probably, such compilers (for languages like C and C++) already exist, but are too expensive for most users. I don't know how good GCC is at generating Itanium code, but it has become far better in generating X86 code over the years. That makes GCC increasingly good even for cases in which optimization truly matters. If you look at medium-priced compilers like IBM C Set and IBM Visual Age for C/C++, you can see that even for a 4- to 5-figure sum, you can get pretty good optimizers. The best ones are in the 6- to 7-figure range however (b/c they're sold in small numbers by small companies). Applying every optimization strategy known to mankind in a reliable and robust manner costs a buck or two. That's an area in which GCC needs to be further improved (to make optimizers that always work), but 4.x has become quite good in that respect also. Still, if more people would know how to write compilers, there wouldn't be so many monopolies around.
You're right, there's no "stateless" modifier in C++. Interesting idea! If I ever get around to implement a C++ compiler, I'll include it! Implementing it is a piece of cake!:) -- In real world apps, currently the only solution is to use null pointers. If something is a null-pointer, you can regard it as stateless. As soon as something else is assigned to it, it has state. But this requires a lot of discipline in the code, namely that after every deallocation, a pointer is set to null. There are various other techniques that can enhance legibility and stability of code. Clearly, global variables are not among desirable elements. Yup, I did a lot of work with multithreaded code. Sadly, few programmers know how to use it right. On UNIX systems, you can run into a lot of problems with non-thread-safe libraries and signalling problems. Encapsulating such stuff away is always a good idea. Also, programming around system limitations. It's always a good idea not use any system call directly; instead, write a library to encapsulate any issues that are encountered. This also makes the code more easily portable.
I live in Germany!:) Here, in the 80ies, they interrupted regular programming for every shuttle launch and broadcast it live, from the preparations to the actual launch, often accompanied with interviews with NASA staff and scientists. Nowadays, shuttle launches aren't broadcast live anymore here, sadly, but at least we have Space Night every night on BR3 (a Bavarian television channel), they broadcast NASA footage all night every night. That's a lot of fun also!:) - I hope that NASA will get a foot into commercial space travel and be one of the major players!:)
BTW, I have an idea how to make space travel cheaper: Why not build a large scale space elevator (about 20 miles in diameter and 40 miles up) capable of lifting payload into space? That would be much cheaper, and would be the first mega-city and real spaceport on the planet!:) (robot-based construction and light materials could enable that!)
A chip like Itanium requires parallelizing compilers. These do exist, but often cost a lot of money. Languages like Occam have builtin language features for parallelism, but even a multithreading library like pthread could be inlined by the compiler. It's all a matter of compiler design, that's why Itanium wasn't very populer, because there are only few compilers. CS students should be tought how to write HLL compilers, so that more people know how to do it and aren't afraid of it. It's really simple if you look underneath the apparent complexities. For instance, a recursive-descendant compiler is easier to implement by hand than a table-driven compiler. Tools like lex and yacc should be banned from compiler theory lessons. These are things that only increase the apparent complexity for the student. In fact, writing compilers is extremely simple if you know how; a good book has been "BCPL - The Language and Its Compiler", because it contained portions of a hand-written compiler. Lexical analyzers and syntax analyzers are very easy to implement. Basically, a BNF or EBNF already describes the layout of the syntax analyzer if its implemented in a recursion. I successfully implemented a number of compilers for specialized languages without even a CS background, just by writing solid recursive code.
Threads are really simple if you're using a few simple techniques: Write a simple wrapper class (or lib) around your system's threading API. Make sure startup and cleanup work in a well-defined manner. You can synchronize this by using events (or condition variables on UNIX). Provide a mechanism to signal when a thread shall terminate. The thread tests this signal and leaves processing when it is set. For inter-thread communication, write a simple messaging system (using doubly-linked lists and mutexes). Once you have these simple tools encapsulated in away in a few classes or a small library, writing multithreaded code becomes a piece of cake. Also, make sure that threads only do black-box stuff and are controlled only via messages. HTH
Thanks for your work on the Space Shuttle!:) Sorry to see it go. I fondly remember the time when every Space Shuttle launch was broadcast on television!:)
Slashdot Mirror
... or *BSD or Solaris :)
I heard Ubuntu Linux can run any number of applications. No trouble with the visuals either.
In fact, they're counting on you. They want to commit mass suicide: Windows was such a pain to maintain ...
Yeah, when does Micro$oft stop selling toy OSes ...
Windows did never multitask proper, it can run only 3 apps at once, now we have the proof.
... and it's still not finished.
... until it's feature-complete and fully implemented, that is. ;-)
My concept goes far beyond Phantom, however. But it's vaporware too
Thank you! I didn't even know that something like that existed!! Interesting read. The earliest I've known about was OS/400's TIMI (VM with integrated database). In '92, I was working on a database/language integrated system and found only Lotus Notes to be somewhat similar. Great that we have access to the Web now and can access all that information that was rotting somewhere in libraries before. Not to mention all the possibilities for communication that we have now! :) - It's a shame those "ancient" technologies have not been picked up by the mainstream OS developers yet. There's been a lot of good stuff in the '60ies already. I'll certainly work to bring back some of these things into the mainstream if I can ...
No one has come up with the "database driven file systems" we were all promised years ago
This has been one of my research projects for 16 years. Recently, I've published a library that can be used for implementing one. It doesn't suffer from the same problems as earlier prototypes (that I didn't publish b/c they had limited use, but I might anyway someday). Most notably, because it's written in C++ with portability in mind, it possesses quite some powerful abilities. I have some even more powerful concepts ready that I might integrate into the library one day.
Yeah, what do we need trillion dollar industries for?
Some people apparently don't believe this is real. They'll be purchasing their robots from Wal-Mart instead of getting involved.
You should read the whole thread, not just a few posts. He DOES explain some of the concepts in his android. Also, you're wrong about saying something like that never existed before: There are hundreds of projects like this, most of them happen in Japan. The problem is that none of those development groups ever work together. Instead, they all independently try to build the first real android. Aiko's inventor has come very far, but he'll need a lot of more funds and time to complete the project.
His way of writing software is the same as that of many software companies: They try to keep the thing undocumented to make theft of source code futile. Instead, Aiko's inventor should open-source his effort, no matter how bad the code is. Other groups could benefit from his work. He could work with other groups to get some of their insights and knowledge. Sharing of information would get androids to market far quicker than all those isolated efforts.
... this thread clearly shows us who we will purchase our robots from. Apparently the West is oblivious to employment opportunities. Aiko is just one of hundreds of similar projects to create humanoid robots to assist people in the household. Yeah ... what a dumb idea ... a household robot, who could ever need that? Now guess where most of the development happens ...
A space elevator needs to be firmly set onto the ground, be at least 20 km in diameter and 40 km high. Lots of rental space included.
The fact that most people write bad code in a language (i.e. they use a bad dialect) is no good reason not to write good code in that language. Because such bad code exists doesn't necessarily mean you have to make your code around it.
In principle, that might be true; However, in practice, when working for an employer, you have to make compromises. Like adding code to prevent long unnecessary debugging sessions. (That's a good idea even when you're just coding for yourself; It can save a lot of time.)
I already said it was fairly useless and what it needed to become very useful. It's just a few lines to show you what RAII is like, because whatever you might boast it was obvious you needed to be given an example.
Well, as I already said, I've been employing those principles for over 12 years already.
I've written my first auto-pointer classes in 1996
Which was necessarily defective. std::auto_ptr sucks hard, that's why it's being deprecated.
Well, you haven't seen my auto pointer classes. They are totally unrelated to the STL.
Besides, in 1996, the STL was nothing more than a proposal, and there wasn't even a usable implementation.
std::unique_ptr, its replacement, is better, but still not perfect in my opinion since it takes a pointer and not an object;
The purpose of such classes is to provide automatic cleanup for pointers. Hence, only a pointer makes sense in that case.
When talking about what code should be like I'd rather use the ideal solutions, even if few compilers implement them, rather than ugly workarounds.
That's your choice, but it makes you seem more like a language lawyer than a programmer. Seeing the practical side of things is paramount to programming however. You're doing yourself no favour.
As you can see, you're doing delete outside of a destructor. It is clear from your code you understood nothing of the ownership issues I took time to explain to you. You also probably didn't read up on RAII or exception-safety, since your code is not conforming to those principles, and is thus garbage.
It's an example of real-world garbage, in a shortened form. That's the whole point. In the real world, many programmers don't know anything about the principles you're talking about. And that's the problem!
You appear to live in an ivory tower.
The "= delete" you consider to be a syntax error is a feature of the new yet-to-be-finalized C++ standard (known as C++0x) which allows deleting of member functions that are defined by default.
I already suspected that, but it's still considered to be a syntax error by the compiler I'm using, GCC 4.3.2.
It also doesn't conform to the current ISO C++ standard.
You cannot write code that uses fantasy features of yet-to-be-defined standards.
That makes you appear as dislodged from reality as in some other statements you made.
I chose here to make the object non-copyable and non-assignable for the sake of simplicity.
In fact, that class appears to be very wacky. If I ever came across such code, I would rewrite it for clarity.
I've written my first auto-pointer classes in 1996, and automatic container classes (for stack-based usage) even earlier.
The way to do that in C++03 is usually to redeclare them and make them private, not providing the definition. I thought you might not understand such basic techniques, so I chose to use a way that conveyed the intent better.
Instead you used a piece of fantasy code for a fantasy compiler. How smart! Now you're the epitome of a C++ programmer!
Ok, let's give an example to you about that pointer that cannot be accessed. This is of course a fairly useless object (albeit if you add move, swap and inplace construction support, it then becomes quite useful).
// syntax error! // syntax error!
template<typename T>
struct scoped_obj
{
scoped_obj(const T& t) : ptr(new T(t)) {}
~scoped_obj() { delete ptr; }
scoped_obj(const scoped_obj&) = delete;
scoped_obj& operator=(const scoped_obj&) = delete;
T* operator->() { return ptr; }
const T* operator->() const { return ptr; }
private:
T* ptr;
};
Incredibly enough, once the destructor of scoped_obj has been called, there is no way to access ptr anymore. So there is no reason to set it to null. Writing ~scoped_obj() { delete ptr; ptr = 0; } would just be silly.
Ah, so writing:
struct A {
int b;
inline A() { b = 0; }
inline A( const A& a ) { b = a.b; }
};
A aa;
scoped_obj<A>* a = new scoped_obj<A>( aa );
delete a;
(*a)->b = 135;
would not result in a problem? *scratches head*
Methinks you've overlooked something.
Understand that simple point now? And since C++ code should follow RAII, resource reclamations should look like this (be done in destructors).
Yeah, yeah, the principle is okay, I didn't doubt that. And I didn't doubt your C++ skills until now.
It is clear you understand very little of what I'm talking about, which is probably linked to your complete lack of modern C++ knowledge, so I'll just stop there.
I suspect it's just the other way around.
It seems your problem with C++ is that it doesn't refuse bad code at compile-time. Well, I wish you good luck with programming then. Even Haskell is no panacea on those terms.
Well, I've fixed bugs written by people like you, and frankly, I wouldn't want to be on the same team with you. You've got a lot to learn.
I don't really see how making objects stateless brings any direct help to parallel programming; sure, that means concurrent read accesses are allowed, but that doesn't parallelize the code.
Stateless objects do not have state, and hence are similar to real constness (which is isn't guaranteed in C++). In a concurrent scenario, yes, concurrent reads would be possible without the need of a mutex semaphore. In a team development setting, true constness with no loopholes would guarantee that a modification cannot interfere with object state.
Stateless as in "undefined value" would have advantages in some settings. Sadly, C++ doesn't provide that either.
But that is your choice.
In a team setting, programming guidelines need to be established and followed; but some companies don't want that.
Spaghetti code is not permitted by the standard idioms.
But it is permitted by the compiler. And hence, you have no guarantees against it. Spaghetti code is a reality of real-word projects, a nightmare that too often comes true ...
...
Many companies don't even have internal documentation for their projects ("the source is the documentation"), and the source-code is ever-changing.
That's why companies are moving away from the "problematic" C++ to C#, for instance. Not that they'd realize that you can write spaghetti code in any language
Setting member variables to 0 in a destructor for instance is important to avoid memory corruption and to detect when a pointer is accessed after an object is already destroyed
As I already told you, the pointer doesn't exist anymore once the destructor has been called. It cannot be accessed anymore. It is just useless to modify its value.
You're very wrong about this. Simply disassemble some code that accesses memory after it is freed, and not only does the compiler not complain about it, but it also generates code that faithfully accesses the pointer to the memory that has already been freed.
... surprise, surprise, you'll still see "0xbfec00" in the "px" variable. That's why it is a good idea to set it to "0" especially when there's a risk that the variable might be reused later on.
Say, you have used the "new" operator to allocate an object of class X and assigned it to a pointer variable called "px". A debugger or printf()-statement or whatever you choose outputs the pointer variable as "0xbfec00", for instance. Now you call the delete operator on "px". Then, you output the pointer again, and
In the light of multithreading, some programmers do not understand that they MUST NOT access memory from two threads at once. That leads to horrible forms of spaghetti code when they try to program around crash scenarios. This leads to programs that crash differently with timing variations. That's why it is important to use mutexes correctly in multithreading code. That's why setting pointers to null pointers can become critical in detecting programming errors.
Sorry, but I don't really see the link between null pointers and concurrency. Moreover, concurrent reads certainly are valid with most concurrency memory models.
Null pointers are crash triggers for badly-written programs. That's called "crash accelerator". If some multithreaded code unprotectedly accesses objects that are already freed, an exception is caused immediately, instead of continuing processing until the condition escalates.
... I can tell you that no theory is going to protect you against the realities of real-world applications, especially if you aren't working alone.
You seem to be indulged in theory
If you've ever debugged an application for two weeks straight, just to find out that some moron has accessed memory after it was already freed, th
How is const not a good stateless modifier?
In C and C++, constness can be cast away at the programmer's whim (using either a C++ const_cast<> operator or a regular C cast operator). Also, fields declared "mutable" in C++ can be modified even in constant context. That's why "const" is not a "stateless" modifier in C and C++.
Of course, it's up to you to decide what your object should allow when constant. It's up to you to maintain the right invariants and semantics, which are what modeling resources and values as objects is for.
Sadly, formal object modelling isn't used by many companies. Most corporate code is more akin to spaghetti code. The more people have worked on it, the greater the mess you'll find when you look at it.
The good practices of C++ are to *not* use pointers, only perform resource reclamation in destructors (which means setting the pointer to null after freeing is useless, since the pointer doesn't exist any more),
Setting member variables to 0 in a destructor for instance is important to avoid memory corruption and to detect when a pointer is accessed after an object is already destroyed. If there's even the slightest chance of a dangling pointer (or reference, for that matter), it's always good to set things to sane values before leaving a function. Otherwise, the slightest programming error can corrupt swathes of memory.
In the light of multithreading, some programmers do not understand that they MUST NOT access memory from two threads at once. That leads to horrible forms of spaghetti code when they try to program around crash scenarios. This leads to programs that crash differently with timing variations. That's why it is important to use mutexes correctly in multithreading code.
That's why setting pointers to null pointers can become critical in detecting programming errors.
and not use useless "empty" states when it doesn't make sense, because they're usually dangerous states with limited possibilities (it mostly makes sense only for dynamically-sized collections).
WTF are you talking about?! The usage of state information is always highly application dependent.
Thank you! :)
No, that's largely correct, but it's not that much of a difference. If a compiler knows how to handle parallelism, handling threads isn't much extra overhead. Probably, such compilers (for languages like C and C++) already exist, but are too expensive for most users. I don't know how good GCC is at generating Itanium code, but it has become far better in generating X86 code over the years. That makes GCC increasingly good even for cases in which optimization truly matters. If you look at medium-priced compilers like IBM C Set and IBM Visual Age for C/C++, you can see that even for a 4- to 5-figure sum, you can get pretty good optimizers. The best ones are in the 6- to 7-figure range however (b/c they're sold in small numbers by small companies). Applying every optimization strategy known to mankind in a reliable and robust manner costs a buck or two. That's an area in which GCC needs to be further improved (to make optimizers that always work), but 4.x has become quite good in that respect also. Still, if more people would know how to write compilers, there wouldn't be so many monopolies around.
You're right, there's no "stateless" modifier in C++. Interesting idea! If I ever get around to implement a C++ compiler, I'll include it! Implementing it is a piece of cake! :) -- In real world apps, currently the only solution is to use null pointers. If something is a null-pointer, you can regard it as stateless. As soon as something else is assigned to it, it has state. But this requires a lot of discipline in the code, namely that after every deallocation, a pointer is set to null. There are various other techniques that can enhance legibility and stability of code. Clearly, global variables are not among desirable elements. Yup, I did a lot of work with multithreaded code. Sadly, few programmers know how to use it right. On UNIX systems, you can run into a lot of problems with non-thread-safe libraries and signalling problems. Encapsulating such stuff away is always a good idea. Also, programming around system limitations. It's always a good idea not use any system call directly; instead, write a library to encapsulate any issues that are encountered. This also makes the code more easily portable.
I live in Germany! :) Here, in the 80ies, they interrupted regular programming for every shuttle launch and broadcast it live, from the preparations to the actual launch, often accompanied with interviews with NASA staff and scientists. Nowadays, shuttle launches aren't broadcast live anymore here, sadly, but at least we have Space Night every night on BR3 (a Bavarian television channel), they broadcast NASA footage all night every night. That's a lot of fun also! :) - I hope that NASA will get a foot into commercial space travel and be one of the major players! :)
:) (robot-based construction and light materials could enable that!)
BTW, I have an idea how to make space travel cheaper: Why not build a large scale space elevator (about 20 miles in diameter and 40 miles up) capable of lifting payload into space? That would be much cheaper, and would be the first mega-city and real spaceport on the planet!
A chip like Itanium requires parallelizing compilers. These do exist, but often cost a lot of money. Languages like Occam have builtin language features for parallelism, but even a multithreading library like pthread could be inlined by the compiler. It's all a matter of compiler design, that's why Itanium wasn't very populer, because there are only few compilers. CS students should be tought how to write HLL compilers, so that more people know how to do it and aren't afraid of it. It's really simple if you look underneath the apparent complexities. For instance, a recursive-descendant compiler is easier to implement by hand than a table-driven compiler. Tools like lex and yacc should be banned from compiler theory lessons. These are things that only increase the apparent complexity for the student. In fact, writing compilers is extremely simple if you know how; a good book has been "BCPL - The Language and Its Compiler", because it contained portions of a hand-written compiler. Lexical analyzers and syntax analyzers are very easy to implement. Basically, a BNF or EBNF already describes the layout of the syntax analyzer if its implemented in a recursion. I successfully implemented a number of compilers for specialized languages without even a CS background, just by writing solid recursive code.
Threads are really simple if you're using a few simple techniques: Write a simple wrapper class (or lib) around your system's threading API. Make sure startup and cleanup work in a well-defined manner. You can synchronize this by using events (or condition variables on UNIX). Provide a mechanism to signal when a thread shall terminate. The thread tests this signal and leaves processing when it is set. For inter-thread communication, write a simple messaging system (using doubly-linked lists and mutexes). Once you have these simple tools encapsulated in away in a few classes or a small library, writing multithreaded code becomes a piece of cake. Also, make sure that threads only do black-box stuff and are controlled only via messages. HTH
Thanks for your work on the Space Shuttle! :) Sorry to see it go. I fondly remember the time when every Space Shuttle launch was broadcast on television! :)