I haven't looked at Inti much yet, but GTK-- was horrible. It was quite clear from the very beginning that the GNOME people have considered a C++ binding as necessary only to shut up people who think that using an OO language is a good idea for an OO toolkit.
I don't write much UI code, but the quality of GTK-- made me even less interested in doing so. With Java Swing, writing UI code is almost fun. Making a good OO UI toolkit is possible. I hope Inti is one.
It was using a forward declared nested class. The crash happened when I forgot to put in the include file that defined the nested class.
Again, I've not seen forward declared nested classes used much. Most of STL uses typedefs to rename a top level class to a nested type name, so the class definition itself is top level.
The problem was repeatable. Hardware problems usually aren't.
When I was compiling good code and it crashed, I was making use of a g++ specific feature, named return values. I expect this feature to disappear and be made into an automatically done optimization instead, but, until then, it makes vast improvements in code in the right places.
I think the bad code that crashed the compiler was using deeply nested classes in combination with templates. This is also not commonly seen.
I could care less about C++ binary compatibility. It largely doesn't exist now. C++ is a moving target from that perspective, and is likely to remain so for awhile longer.
I do care about my compiler's stability. I expect my compiler to work. Any hint that it does not work worries me deeply. It makes me wonder if any bug I find is a code generation error, or my problem.
gcc 2.96 (C++) crashed on me, twice. Once was when it was compiling code with errors, which was mildly worrisome, and once while it was compiling perfectly good code, which was very worrisome.
Above all else, I want a stable compiler I can trust. gcc-2.96 has lost my trust. I want gcc-2.95.2 back, and kgcc is not gcc-2.95.2, it's gcc-2.91.66 (which I bet has much worse C++ support).
CERT has had a history of releasing vague reports about a problem fearinf that embarassing the vendor was a bad idea. IMHO, the more embarassed, the better.
I don't think exploits should be released right off, but upon discovering a security hole, you should immediately release a detailed enough description that an exploit could be written by someone competent in a few days.
Releasing an exploit is something you do after you feel the bug has been out for long enough for someone to have coded one anyway. I would say, 3-6 months after the bug has been disclosed, but probably not at all if the vendor has a patch. This gives vendors enough time to code a patch, but doesn't let them ignore you.
I don't think there is anything about actually releasing the exploit immediately that should be actionable under the law. It should just be considered rude and in poor taste.
That's my personal philosophy, and IMHO, what CERT is doing doesn't go far enough. I don't consider releasing an exploit as necessary to claiming full disclosure. I do consider immediately releasing all pertinenet information to be required.
It's a problem of the mapping between function name, and location in the virtual table. If you set it up so that mapping happens at runtime (but just once), then adding new methods isn't a problem. Only removing methods, or changing the semantics of an existing method is a problem.
If you don't stick with abstract base classes, then you add class size to the mix. Many parts of a C++ program invisibly depend on the size of a class. In particular, array declarations or pass by value arguments and return values. Also, if you call inline functions, you end up with code that depends on the actual layout, type and name of member variables. This is a real pain to deal with.
You could have some kind of hash that was kept of what the two linked components expected the insides of the class to look like, and if the hashes differ, refuse to link and tell the programmer that a recompile of one of the two components was required instead.
Why not just define decent abstract base classes use them, and be done with it. But, I suppose that wouldn't work if you had to change the interface. *sigh* I hate CORBA. It's an even uglier mess than the C++ ABI, and it lets people believe they're making functions calls when they're really sending network messages.
Hear here! This has been my experience with gcc-2.95.2. I think its optimization could be better, and it would be nice to have support for the K6 and K7, but other than that, it's been very stable and reliable for me. I do a _lot_ of C++ coding.
I expect this to change in the next 5 years. C++ is starting to be stable and well understood enough that compiler vendors can start standardizing on calling conventions and such.
But, it will still have the 'fragile base class' problem. That one's pretty hard to fix. *sigh* *think*
I don't really care too much about the binary incompatibility problem. It's a pain for libraries, but there are not yet a lot of widely used C++ libraries that I know of.
I do care very much about my compiler breaking. I have a C++ project I've been working on for a long time, and I remember the bad old days of the 2.6.x series. *shudder* I was having to #ifdef all over to make code that closely followed what then passed for the standards. And I even purposely avoided some of the newer features like templates and exceptions.
It's very painful to work around compiler breaks. Especially when you code like I do and the vast majority of your code is so cross-platform that you don't even need #ifdefs to get it to work for NT.
This is true, but nobody would have any way to know if the new Microsoft product were vaporware or not. We know for a fact that the Linux kernel isn't, and if you care to look, you can even get an extremely detailed list of things that still need fixing. Definitely not vaporware. *grin*
Oh, I know this, but it's often not used to distribute things beyond the bounds of the machine it's running on.
Besides, CORBA and RPC are horrible protocols for doing that as well, though I will admit that.NET is not a solution. Also, if.NET turns that into even more verbose XML, that's even worse, though not that much worse (except that XML is a much bigger pain to parse).
My main problem with RPC is not its verbosity, it's latency. There's a hard lower limit on latency. That limit can be reduced, but as I like to say, the speed of light is a constant.
Yeah, I'm too busy doing other stuff to take the time needed to collect all the information about.NET. I wish someone would and actually tell me what it is. This vague cloud of Microsoft sponsored hype is unsettling.
This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.
RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.
This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.
Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.
BTW, this is all a guess. The article is kind of vague.
This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.
RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.
This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.
Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.
BTW, this is all a guess. The article is kind of vague.
Both CORBA and COM/DCOM are horrible answers to the cross-language communication problem. A function call should be a function call, not a network message. They aren't the same thing. That's why microkernels aren't such a hot idea either.
Since RPC style methods are so bad for cross-language communication, why not do something different, and just standardize on data representations instead. Then function calls work like they're supposed to. It's an interesting idea.
No, they probably won't, but this platform on top of.NET will be. And since it will be, you can look at it and see how.NET works.
Maybe they'll try to cover that with other forms of IP, like patents. I don't know.
All I know is that I read the article, and my brain wants to shut down into 'your subconcious is thinking hard about something' mode. Something about it is intriguing.
The article is based on the premise than Sun will leave the Cobalt hardware running Linux. It's also misses the fact that recent Cobalt hardware is Intel based, though that strengthens the argument.
I think Sun will replace Linux with Solaris because of the mindset they have that Solaris is better in all ways. This will hurt Linux, and not help Sun as much as it could if they didn't do that.
When I want an OS by a monopolistic company that has APIs that are piles of steaming horse dung and wants to lock me into using their system forever, I'll use Windows.
As for RH 7.0's bugginess, I'm rather apalled. I may switch distributions over this. At least I have a choice.
As I said, a Scientific American article. I can't remember the exact issue. It was within the last three months. They were talking about the spread of AIDS in Africa.
Also, the article implied that these practices were widespread, but didn't give any percentages that I can recall.
The point is, they have a devil of a time trying to get honest answers from women about their sexual habits because it's such a taboo subject to talk about, so it's hard to track down their partners if they turn out to have AIDS.
Slashdot Mirror
I haven't looked at Inti much yet, but GTK-- was horrible. It was quite clear from the very beginning that the GNOME people have considered a C++ binding as necessary only to shut up people who think that using an OO language is a good idea for an OO toolkit.
I don't write much UI code, but the quality of GTK-- made me even less interested in doing so. With Java Swing, writing UI code is almost fun. Making a good OO UI toolkit is possible. I hope Inti is one.
The compiler not being able to build the kernel is the kernel's fault, not the compiler's.
If I'm not mistaken, gcc 2.95.2 can't even compile the kernel.
Oh, I remember...
It was using a forward declared nested class. The crash happened when I forgot to put in the include file that defined the nested class.
Again, I've not seen forward declared nested classes used much. Most of STL uses typedefs to rename a top level class to a nested type name, so the class definition itself is top level.
The problem was repeatable. Hardware problems usually aren't.
When I was compiling good code and it crashed, I was making use of a g++ specific feature, named return values. I expect this feature to disappear and be made into an automatically done optimization instead, but, until then, it makes vast improvements in code in the right places.
I think the bad code that crashed the compiler was using deeply nested classes in combination with templates. This is also not commonly seen.
I could care less about C++ binary compatibility. It largely doesn't exist now. C++ is a moving target from that perspective, and is likely to remain so for awhile longer.
I do care about my compiler's stability. I expect my compiler to work. Any hint that it does not work worries me deeply. It makes me wonder if any bug I find is a code generation error, or my problem.
gcc 2.96 (C++) crashed on me, twice. Once was when it was compiling code with errors, which was mildly worrisome, and once while it was compiling perfectly good code, which was very worrisome.
Above all else, I want a stable compiler I can trust. gcc-2.96 has lost my trust. I want gcc-2.95.2 back, and kgcc is not gcc-2.95.2, it's gcc-2.91.66 (which I bet has much worse C++ support).
CERT has had a history of releasing vague reports about a problem fearinf that embarassing the vendor was a bad idea. IMHO, the more embarassed, the better.
I don't think exploits should be released right off, but upon discovering a security hole, you should immediately release a detailed enough description that an exploit could be written by someone competent in a few days.
Releasing an exploit is something you do after you feel the bug has been out for long enough for someone to have coded one anyway. I would say, 3-6 months after the bug has been disclosed, but probably not at all if the vendor has a patch. This gives vendors enough time to code a patch, but doesn't let them ignore you.
I don't think there is anything about actually releasing the exploit immediately that should be actionable under the law. It should just be considered rude and in poor taste.
That's my personal philosophy, and IMHO, what CERT is doing doesn't go far enough. I don't consider releasing an exploit as necessary to claiming full disclosure. I do consider immediately releasing all pertinenet information to be required.
Neat, you've demonstrated that I have more to learn. :-)
Here's how I see the problem...
It's a problem of the mapping between function name, and location in the virtual table. If you set it up so that mapping happens at runtime (but just once), then adding new methods isn't a problem. Only removing methods, or changing the semantics of an existing method is a problem.
If you don't stick with abstract base classes, then you add class size to the mix. Many parts of a C++ program invisibly depend on the size of a class. In particular, array declarations or pass by value arguments and return values. Also, if you call inline functions, you end up with code that depends on the actual layout, type and name of member variables. This is a real pain to deal with.
You could have some kind of hash that was kept of what the two linked components expected the insides of the class to look like, and if the hashes differ, refuse to link and tell the programmer that a recompile of one of the two components was required instead.
Bah! Icky CORBA.
Why not just define decent abstract base classes use them, and be done with it. But, I suppose that wouldn't work if you had to change the interface. *sigh* I hate CORBA. It's an even uglier mess than the C++ ABI, and it lets people believe they're making functions calls when they're really sending network messages.
Hear here! This has been my experience with gcc-2.95.2. I think its optimization could be better, and it would be nice to have support for the K6 and K7, but other than that, it's been very stable and reliable for me. I do a _lot_ of C++ coding.
I expect this to change in the next 5 years. C++ is starting to be stable and well understood enough that compiler vendors can start standardizing on calling conventions and such.
But, it will still have the 'fragile base class' problem. That one's pretty hard to fix. *sigh* *think*
I don't really care too much about the binary incompatibility problem. It's a pain for libraries, but there are not yet a lot of widely used C++ libraries that I know of.
I do care very much about my compiler breaking. I have a C++ project I've been working on for a long time, and I remember the bad old days of the 2.6.x series. *shudder* I was having to #ifdef all over to make code that closely followed what then passed for the standards. And I even purposely avoided some of the newer features like templates and exceptions.
It's very painful to work around compiler breaks. Especially when you code like I do and the vast majority of your code is so cross-platform that you don't even need #ifdefs to get it to work for NT.
This is true, but nobody would have any way to know if the new Microsoft product were vaporware or not. We know for a fact that the Linux kernel isn't, and if you care to look, you can even get an extremely detailed list of things that still need fixing. Definitely not vaporware. *grin*
Oh, I know this, but it's often not used to distribute things beyond the bounds of the machine it's running on.
Besides, CORBA and RPC are horrible protocols for doing that as well, though I will admit that .NET is not a solution. Also, if .NET turns that into even more verbose XML, that's even worse, though not that much worse (except that XML is a much bigger pain to parse).
My main problem with RPC is not its verbosity, it's latency. There's a hard lower limit on latency. That limit can be reduced, but as I like to say, the speed of light is a constant.
Yeah, I'm too busy doing other stuff to take the time needed to collect all the information about .NET. I wish someone would and actually tell me what it is. This vague cloud of Microsoft sponsored hype is unsettling.
This is a duplicate of a post I decided to make at the top level called 'Preliminary Analysis'. :-)
I posted, and forgot that I was posting it as a reply to my own message. Oops.
What an interesting and Machiavelian interpretation of that little incident. You might even just be right. :-)
This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.
RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.
This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.
Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.
BTW, this is all a guess. The article is kind of vague.
This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.
RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.
This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.
Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.
BTW, this is all a guess. The article is kind of vague.
Both CORBA and COM/DCOM are horrible answers to the cross-language communication problem. A function call should be a function call, not a network message. They aren't the same thing. That's why microkernels aren't such a hot idea either.
Since RPC style methods are so bad for cross-language communication, why not do something different, and just standardize on data representations instead. Then function calls work like they're supposed to. It's an interesting idea.
No, they probably won't, but this platform on top of .NET will be. And since it will be, you can look at it and see how .NET works.
Maybe they'll try to cover that with other forms of IP, like patents. I don't know.
All I know is that I read the article, and my brain wants to shut down into 'your subconcious is thinking hard about something' mode. Something about it is intriguing.
Microsoft didn't come up with it. They just recognized a possibly good thing and are trying to be first on the bandwagon to adopt it.
What theese people have here sounds interesting. It needs to be studied more and explained better.
Besides, this thing _is_ GNU licensed. That's why I won't reject it out of hand and/or try to build a duplicate that is.
Solaris x86 has no standing in the Intel arena. The only people who care about it are people who are also running Solaris on Sparc boxes.
The article is based on the premise than Sun will leave the Cobalt hardware running Linux. It's also misses the fact that recent Cobalt hardware is Intel based, though that strengthens the argument.
I think Sun will replace Linux with Solaris because of the mindset they have that Solaris is better in all ways. This will hurt Linux, and not help Sun as much as it could if they didn't do that.
When I want an OS by a monopolistic company that has APIs that are piles of steaming horse dung and wants to lock me into using their system forever, I'll use Windows.
As for RH 7.0's bugginess, I'm rather apalled. I may switch distributions over this. At least I have a choice.
As I said, a Scientific American article. I can't remember the exact issue. It was within the last three months. They were talking about the spread of AIDS in Africa.
Also, the article implied that these practices were widespread, but didn't give any percentages that I can recall.
The point is, they have a devil of a time trying to get honest answers from women about their sexual habits because it's such a taboo subject to talk about, so it's hard to track down their partners if they turn out to have AIDS.