Maybe it's just me, but I would expect a spacewalk to be performed by a strict procedure, (someone telling each step over the intercom or a digital checklist attached to the sleeve of the astronaut's suit), comparable to how surgeons work: well planned and prepared, the placement of the toolbox and its tools included in the planning (open attached toolbag, attach needed tool to suit, detach said tool from toolbag (with double straps, like mountain climbers do), use tool, etc.). Am I getting something fundamentally wrong about spacewalking as to how this would be impossible?
Simple: when the shuttle's done at the station, detach and intercept the bag in orbit. Voila, $100k saved.
They could think of it as a drill for retrieving an astronaut who floats away during a spacewalk.
I can't believe that was just given a 3 interesting. As if the spaceshuttle can just go fly around anywhere. As if the spaceshuttle has even enough fuel for that. Even with enough fuel, as if the fuel usage for retrieval would cost less than 100K. As if the risk of such operation wouldn't be tremendous. Etcetera. Who gives mod-points these days? A bunch of 7-year olds?
Here's a quote for you sir: "Frankly, I'm suspicious of anyone who has a strong opinion on a complicated issue." - Scott Adams
Now...honestly, what do you think is really going to change?
Here's one word: Trust! Obama is clearly someone who has gained the trust of the world, or to say the least, far more trust than Bush has. You can already see this immediately in the exchange rate of the dollar vs euro to name one. There will be a positive effect that will spread out. I also suspect that aggression against American troops will decline because of this, which means fewer troops will be needed, which means lower tax expenses, etc. In short: the fact that the American people chose Obama is a major boost for the karma of all America that will be felt on every level, be it diplomatic relations, business, international trade... Investors all over the world believe America is in good hands. And he's not even started ruling!
I've seen so many "look, I wrote my own string class, isn't it neat?" that I lost count. No, it's not neat. The STL has provided strings in C++ since 1994 -- if you're writing one in 2008, it's because you're so incompetent you don't know the full language.
I should react to that. The stl string is one string implementation that uses the "string as array of characters" paradigm so that the algortihm template functions can be used with them. Other languages (C#, Java) use the "copy-on-write" paradigm (Google that up, I won't explain the difference here). The latter implementation is more memory and cpu-friendly in 90% of the cases where string operations are needed, so I prefer it above the stl implementation, therefore I DID write my own string class. (If ever I need to use stl algorithms on them, I convert my string into an stl string and afterwards back to my string class. This gives me additional deep copies, but hey, that's what the stl implementation does ALL the time with strings, whereas the other implementation only when the string changes, so there is your benefit.) Second thing (and even more important), the copy-on-write string is thread-safe, the stl not.
Now how does this example adhere to this discussion? Sometimes, the existing code just doesn't float your boat. In such case, it makes sense to look for an alternative and often, writing it yourself can be a good choice as well. What is important when writing it yourself is to use class names and method names (and behaviour) that are well-established. In the case of my own string class, I used the method names of the C# string class, so my documentation is already written. Of course, you won't catch me re-writing things like the quicksort algorithm.
Saying that someone who writes this or that class from scratch is incompetent is a dangerous statement that might somehow boomerang back in your face. Sometimes yes, sometimes no. Rule: listen to what the writer has to say for himself (or read his documentation), you might learn something, you might teach something. Or both.
I wouldn't go with the Poor Man's copyright idea. It doesn't have any case law AFAIK, and is easily fakeable.
The "sending a letter to yourself" idea is demonstrably ridiculous.
I should disagree; it depends on how you send the letter. I don't know about other countries, but where I live it's possible to send a letter that has to be signed for on receipt. Since this is being tracked by the postal service, it can be officially verified that you have actually sent a certain letter on a certain date. On receipt, you sign for it and leave it closed. When in court, you can hand over the closed letter to the judge who can open it and legally determine that the content was in your possession prior to the date the letter was sent. Now if someone else heard of your idea (which must be on a later day since you kept your idea to yourself before you registered it) and decides to register the idea as his, that registration date will be later than yours, so his registration expires. This is waterproof, so explain me how this would be "demonstrably ridiculous"?
Writing past an array in C++ might cause a signal from the MMU, or it might damage an unrelated object causing mysterious failures much later.
This basically means that if other languages have additional bounds checking before writing to arrays which comes at a cost. C++ gives you the same possibilities though: you can overload operator[] of your collection class and add additional checks in it.
As for the rest:
- dangling references: I assume you are familiar with the concept of smart pointers
- iterator invalidation: add a reference counter in your collection classes, increment them each time you create an iterator for it, decrement it when you destroy the iterator, don't destroy the collection unless the reference count is 0
- placement new should only be used in a wrapper that does the necessary checking
- I never use array new, only use vectors
- exceptions during destructors: this is a true pitfall, watch out for this, but at least C++ provides destructors where other languages let you do the cleaning yourself by having to call dispose explicitly. Nobody ever calls that a pitfall.
- dispatch to pure virtual functions can only happen when you call a pure abstract method from the destructor of the abstract class, I mean, come on, it's only obvious that when the destructors get called in reverse order and at the time the pointer to the virtual functions table is set to the one of the abstract class that you will end up calling a function on a null pointer
- Don't use static initialization unless you know that there aren't dependencies on other static initializations. Instead, use the singleton design pattern.
It basically boils down to following good practice guidelines, programming your software in layers, programming your software in layers, programming your software in layers (can't repeat that one often enough), all of which if you don't follow them in any other language, you will end up shooting yourself in the foot as well.
There are pitfalls in C++. There's undefined behaviour in dozens of places. This is all very true, but what you are asking for is this: "give me a razor-sharp knife with which it is impossible to cut me in the fingers." It's all a matter of trade-offs. For any C++ program, you can choose any 3 of the following:
- fast software
- reliable software
- complex software
- easy to build software
Many other languages do not give you the choice of this trade-off, e.g. there's no way to turn off garbage collection.
But let me tell you this: the undefined behaviour is also true for many other popular languages:
- C# doesn't guarantee that the finalize method gets called when the program finishes
- No language can guarantee at what times the garbage collector will run nor how long the collection phase will take
- all threads are frozen during GC
If you want to believe you have more safety with other languages, be my guest, but IMHO, it depends more on who's driving the car than the type of car and yes, the faster the car, the higher the required skills for the driver.
... but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.
Frankly, you should be doing everything on the server side.
If you're going to do everything (validation too) server-side, your application will be very slow and not user-friendly. In fact, a good web-application should do things like validation twice: once in javascript/AJAX and on submit again on the serverside for security reasons. This is why writing good validation in web-applications is far more difficult to maintain than in ordinary windows-based applications: there's a need for redundant checking because you pass everything over a non-secured protocol (http) that can be easily mimicked by hackers who want to push invalid data into your system.
Off-line support is only necessary as a short-term stopgap until the cloud is visible again...
Consider the following:
1) In order to get online on the web cloud, I need an internet connection. Without it, I can't access my data, while others can. If for some reason I can't pay for my internet connection, I can no longer access my data. Where I live, the internet providers basically have an oligopoly (near-monopoly) since there are only 2 of them (sure, there are others, but they depend on the prices of the 2 major ones). This makes me highly dependent.
2) When I create content with sensitive data about private issues (e.g. you want to solicit for another job), this data has to travel over the line even when all I want to do is save a draft version of a document that I may decide to delete later on. Knowing that such data can be easily read by third parties when transferred over the internet, I personally rather restrict the times that I send data over the internet to a minimum.
To conclude, the web platform as an operating system makes you financially more dependent and is a threat to privacy. But feel free to join, I know I won't.
I just don't believe it's worth the risk of constantly being just one static_cast<> or bounds check away from catastrophe. So learn it if you like, but holy crap don't rely on it.
Well, what can I say, tons of applications do rely on C++. In fact, the Joint Strike Fighter's software will be written in C++ and we're talking about life support here; if the software fails, lives depend on it.
I mean, you could easily introduce a bug in an application no matter what language you're going to use. Using a good architecture is what makes the quality of software, not per se the language, only C++ has a richer toolset for designing your program's architecture while (and this is important) not having to trade in performance.
Personally, I wouldn't like to be the pilot in a plane that makes intense real-time calculations where suddenly the garbage collector freezes all the threads because he feels it's time to see if any memory needs to be cleaned up. So yes, I'd rather rely on C++ than on any garbage collected language for that sort of applications.
Now to go a bit deeper into the examples you state: The use of static cast is deprecated. If you find yourself using it, there's something wrong with the architecture of your application. The few cases where you do need it, you can write extensive checks and unit tests around that particular piece of code. And as for bounds checking: if you read or write outside the bounds of an array in C#, you will get a range exception, I don't see what the difference is with C++.
I feel that there's a lot of FUD created around C++. Feel free to post some real code samples that demonstrate how C++ is supposedly broken. Challenge me.
Let me first say that I know how you feel. I've been there too, but this is the steep part of the learning curve of C++ that you just need to get past.
there are far better uses for your time than to fight a language that wants you to fail.
Learning a language like C++ trains you as a programmer in better understanding how things work "under the hood" so to speak. It makes me a better C# programmer, so it's well worth the time and the effort. Even when programming C# in situations where performance matters, your experience with C++ will help you understand which classes and methods to use and which to avoid on what occasions. You may feel that the language has let you down, but on such occasions it is best to call in the help of a mentor. Eventually, you'll be able to find the answers on your own.
I just re-read your comment and realized that I indeed misinterpreted a key sentence. I'm so used to people being against C++ and its features that I somehow got conditioned into interpreting things that way by default.
That said, if you find the time to continue this debate, I'm still curious to see in what situations multiple inheritance can introduce problems of its own.
... but the C++ object model is not the only way to do OO. In many ways, it's a step removed from the original idea of independent objects communicating via message passing with late binding.
Could you specify exactly what step is removed from the original idea? In what way is C++ violating the principle of "independent objects communicating via message passing with late binding"? (examples?)
One could make a reasonable argument that it is the projection of the original concept onto the C++ implementation that causes the lack of cleanliness
What you refer to as a lack of cleanliness is basically a way to allow for optimizations. Very strict concepts cause a lot of overhead that is just not acceptable in situations that require high performance.
... and that while multiple and virtual inheritance can compensate for that to some extent, they also introduce problems of their own.
Please give an example of these problems they supposedly introduce. I'm sure I'll be able to size them down to either (1) a conceptual flaw in the way the programmer designed the classes or (2) a misuse or lack of knowledge of syntax (such as not using virtual inheritance or dynamic_cast)
Personally, I think it's a bit of a cheap shot to make that argument but then implement a half-baked version of C++'s object model anyway rather than a more faithful representation of the original, simple and elegant concept of OO.
One solution does not fit all. That's why C++ gives the programmer the freedom to choose a different paradigm and allow him to not strictly use OO where the overhead would just not be acceptable. Let me ask you this: what is a better tool: one that can be used in many different ways to fit different purposes or one that enforces you to use it in one way only? I'd go for the first and that's what C++ is.
Saying that the OO model of C++ is half-baked is quite an ironic statement. You probably think that C# en Java have a better model while they don't allow multiple inheritance, to me *that* is half-baked; it forces me to use static methods if I want to centralize logic whereas C++ would allow me to inherit from multiple bases that contain code for each different aspect of the resulting class. I find this far more elegant than having to implement the same interfaces over and over again. (read Andrei Alexandrescu)
C++ is not half baked, it is a large toolbox that has many features, but apparently the average programmer is not capable of chosing what tool is fit for what purpose. This results in them choosing a reduced toolbox that requires less learning (other languages). If such a programmer is then confronted with C++, he choses the wrong feature of C++ to solve certain problems and cuts of his fingers with a knife way to sharp. If someone cuts his fingers with a sharp knife, does that mean that we should no longer use sharp knifes? Or does it mean that this person is incompetent and should either get an education or stay away from sharp knives to begin with?
This is why I don't have much time for the Java and C# designers who criticised C++ for supporting multiple inheritance, but then went ahead and used classes and virtual functions essentially the same way anyway.
I don't see how C# and Java could be used the same way if it comes to multiple inheritance.
I also like to remind that generics as now widely used in languages such as Java and C# initially started as templates in C++, only the latter has far better support.
I think that's rather flattering to C++. Generic code, in the parameterised type/function sense, is effectively the default in many functional languages. The compile-time meta-programming side of C++ templates... Well, Lisp, 'nuff said.
OK, other languages have it as well, but my point was that it's undoubtedly the C++ co
Just a side-note on unit-tests and debuggers (actually off-topic): They're all fine and well, but bugs resulting from bad synchronization (e.g. use of mutex etc) in multithreaded programs will not be detected. Often, if an object is not well synchronized, the chance of having race conditions or lost updates are generally very small and therefor hard to reproduce, but in a production environment they would still come up fairly regularly. E.g. If there's a chance of 1 in a million for something to go wrong due to bad synchronization, you would only encounter it on average every one millionth time you debug your application (=never), while for a computer it's not a big deal to run a piece of code billions of times per day. By definition, unit tests are never run while other threads are touching the same memory because they are meant to test an isolated unit, which boils down to testing them on a single thread, so unit tests will even never spot them.
Don't get me wrong, it's good practice to have unit tests, but there are actually people out there (often IT managers) who imagine that if all code is covered by unit tests that this would guarantee that the program as a whole can't fail so I always like to add this disclaimer when talking about unit-tests or testing in general.
Multiple inheritance carries too much baggage (...) but it really has no demonstrable practical benefit in my opinion. This is basically heresay. Most people who *think* multiple inheritance is not needed have never gotten into programming deep enough to understand that it actually *is* necessary if you want a clean object model. Sure C# and the like give you interfaces, but they require you to implement the code behind them over and over again, resulting in most programmers to just start copy-paste code. Then one day, a bug or change request comes up for that particular copy-pasted code and hell starts: you can start updating all that copy-pasted code and make sure you don't forget any of it. With multiple inheritance, the shared code is actually where it should be: in one class. I dare people to actually show an example of where multiple inheritance is flawed that can't be solved with virtual inheritance or dynamic_cast. The problem is that most programmers who *think* they are C++ programmers are actually enhanced C programmers (at best) who never even heard of dynamic_cast or virtual inheritance, not to mention partial template specialization. Here's a link if you want to know more: http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design
I also like to remind that generics as now widely used in languages such as Java and C# initially started as templates in C++, only the latter has far better support.
For those who think that garbage collection is the holy grail against leaks in a program, think again. While it may solve memory leaks, it doesn't solve resource leaks (like open connections, file locks,...) who on the other hand can be nicely solved in C++ by implementing their release in the destructor. The use of garbage collectors inherently prevents the destructor paradigm (since one can never be sure when or even IF the Finalize method will be called - yes the GC of.NET doesn't guarantee that it will be called even when the program terminates, so freeing up a resource in a Finalize is a no-no since it may still leave you with locked resources), so basically, you're required to manually clean up your resources instead of having your object deal with the cleanup automatically. Makes garbage collection quite controversial if you ask me.
If you want to know more, I'm always in for a discussion on the subject. Happy to inform.
Re:If you want to see the real Cuba, go now...
on
Fidel Castro Resigns
·
· Score: 1
"The crumbling buildings. The antiquated automobiles. The authoritarian presence. The warning to tourists to stay in designated tourist zones. The many desperate women offering their daughters as prostitutes."
Things the USA has as well as Cuba: crumbling buildings - check authoritarian presence - check warning to tourists to stay in designated tourist zones - check desperate women offering their daughters as prostitutes - check
Slashdot Mirror
Maybe it's just me, but I would expect a spacewalk to be performed by a strict procedure, (someone telling each step over the intercom or a digital checklist attached to the sleeve of the astronaut's suit), comparable to how surgeons work: well planned and prepared, the placement of the toolbox and its tools included in the planning (open attached toolbag, attach needed tool to suit, detach said tool from toolbag (with double straps, like mountain climbers do), use tool, etc.). Am I getting something fundamentally wrong about spacewalking as to how this would be impossible?
Simple: when the shuttle's done at the station, detach and intercept the bag in orbit. Voila, $100k saved. They could think of it as a drill for retrieving an astronaut who floats away during a spacewalk.
I can't believe that was just given a 3 interesting. As if the spaceshuttle can just go fly around anywhere. As if the spaceshuttle has even enough fuel for that. Even with enough fuel, as if the fuel usage for retrieval would cost less than 100K. As if the risk of such operation wouldn't be tremendous. Etcetera. Who gives mod-points these days? A bunch of 7-year olds?
Here's a quote for you sir: "Frankly, I'm suspicious of anyone who has a strong opinion on a complicated issue." - Scott Adams
Simple? Yeah, right.
Now...honestly, what do you think is really going to change?
Here's one word: Trust! Obama is clearly someone who has gained the trust of the world, or to say the least, far more trust than Bush has. You can already see this immediately in the exchange rate of the dollar vs euro to name one. There will be a positive effect that will spread out. I also suspect that aggression against American troops will decline because of this, which means fewer troops will be needed, which means lower tax expenses, etc. In short: the fact that the American people chose Obama is a major boost for the karma of all America that will be felt on every level, be it diplomatic relations, business, international trade... Investors all over the world believe America is in good hands. And he's not even started ruling!
I've seen so many "look, I wrote my own string class, isn't it neat?" that I lost count. No, it's not neat. The STL has provided strings in C++ since 1994 -- if you're writing one in 2008, it's because you're so incompetent you don't know the full language.
I should react to that. The stl string is one string implementation that uses the "string as array of characters" paradigm so that the algortihm template functions can be used with them. Other languages (C#, Java) use the "copy-on-write" paradigm (Google that up, I won't explain the difference here). The latter implementation is more memory and cpu-friendly in 90% of the cases where string operations are needed, so I prefer it above the stl implementation, therefore I DID write my own string class. (If ever I need to use stl algorithms on them, I convert my string into an stl string and afterwards back to my string class. This gives me additional deep copies, but hey, that's what the stl implementation does ALL the time with strings, whereas the other implementation only when the string changes, so there is your benefit.) Second thing (and even more important), the copy-on-write string is thread-safe, the stl not.
Now how does this example adhere to this discussion? Sometimes, the existing code just doesn't float your boat. In such case, it makes sense to look for an alternative and often, writing it yourself can be a good choice as well. What is important when writing it yourself is to use class names and method names (and behaviour) that are well-established. In the case of my own string class, I used the method names of the C# string class, so my documentation is already written. Of course, you won't catch me re-writing things like the quicksort algorithm.
Saying that someone who writes this or that class from scratch is incompetent is a dangerous statement that might somehow boomerang back in your face. Sometimes yes, sometimes no. Rule: listen to what the writer has to say for himself (or read his documentation), you might learn something, you might teach something. Or both.
Those with marginal plans are probably taking the gas pipe as well.
I hate to be a grammar-nazi, but it's written "hash pipe", not "gas pipe".
I wouldn't go with the Poor Man's copyright idea. It doesn't have any case law AFAIK, and is easily fakeable.
The "sending a letter to yourself" idea is demonstrably ridiculous.
I should disagree; it depends on how you send the letter. I don't know about other countries, but where I live it's possible to send a letter that has to be signed for on receipt. Since this is being tracked by the postal service, it can be officially verified that you have actually sent a certain letter on a certain date. On receipt, you sign for it and leave it closed. When in court, you can hand over the closed letter to the judge who can open it and legally determine that the content was in your possession prior to the date the letter was sent. Now if someone else heard of your idea (which must be on a later day since you kept your idea to yourself before you registered it) and decides to register the idea as his, that registration date will be later than yours, so his registration expires. This is waterproof, so explain me how this would be "demonstrably ridiculous"?
...And even if they support recursion, you have to watch out for genie stack overflow.
And a pint's a pound, the world 'round. Metric measurements don't have a monopoly on interrelated units.
A pound's a pint, but neither are defined.
Writing past an array in C++ might cause a signal from the MMU, or it might damage an unrelated object causing mysterious failures much later.
This basically means that if other languages have additional bounds checking before writing to arrays which comes at a cost. C++ gives you the same possibilities though: you can overload operator[] of your collection class and add additional checks in it.
As for the rest:
- dangling references: I assume you are familiar with the concept of smart pointers
- iterator invalidation: add a reference counter in your collection classes, increment them each time you create an iterator for it, decrement it when you destroy the iterator, don't destroy the collection unless the reference count is 0
- placement new should only be used in a wrapper that does the necessary checking
- I never use array new, only use vectors
- exceptions during destructors: this is a true pitfall, watch out for this, but at least C++ provides destructors where other languages let you do the cleaning yourself by having to call dispose explicitly. Nobody ever calls that a pitfall.
- dispatch to pure virtual functions can only happen when you call a pure abstract method from the destructor of the abstract class, I mean, come on, it's only obvious that when the destructors get called in reverse order and at the time the pointer to the virtual functions table is set to the one of the abstract class that you will end up calling a function on a null pointer
- Don't use static initialization unless you know that there aren't dependencies on other static initializations. Instead, use the singleton design pattern.
It basically boils down to following good practice guidelines, programming your software in layers, programming your software in layers, programming your software in layers (can't repeat that one often enough), all of which if you don't follow them in any other language, you will end up shooting yourself in the foot as well.
There are pitfalls in C++. There's undefined behaviour in dozens of places. This is all very true, but what you are asking for is this: "give me a razor-sharp knife with which it is impossible to cut me in the fingers." It's all a matter of trade-offs. For any C++ program, you can choose any 3 of the following:
- fast software
- reliable software
- complex software
- easy to build software
Many other languages do not give you the choice of this trade-off, e.g. there's no way to turn off garbage collection.
But let me tell you this: the undefined behaviour is also true for many other popular languages:
- C# doesn't guarantee that the finalize method gets called when the program finishes
- No language can guarantee at what times the garbage collector will run nor how long the collection phase will take
- all threads are frozen during GC
If you want to believe you have more safety with other languages, be my guest, but IMHO, it depends more on who's driving the car than the type of car and yes, the faster the car, the higher the required skills for the driver.
Frankly, you should be doing everything on the server side.
If you're going to do everything (validation too) server-side, your application will be very slow and not user-friendly. In fact, a good web-application should do things like validation twice: once in javascript/AJAX and on submit again on the serverside for security reasons. This is why writing good validation in web-applications is far more difficult to maintain than in ordinary windows-based applications: there's a need for redundant checking because you pass everything over a non-secured protocol (http) that can be easily mimicked by hackers who want to push invalid data into your system.
Off-line support is only necessary as a short-term stopgap until the cloud is visible again ...
Consider the following:
1) In order to get online on the web cloud, I need an internet connection. Without it, I can't access my data, while others can. If for some reason I can't pay for my internet connection, I can no longer access my data. Where I live, the internet providers basically have an oligopoly (near-monopoly) since there are only 2 of them (sure, there are others, but they depend on the prices of the 2 major ones). This makes me highly dependent.
2) When I create content with sensitive data about private issues (e.g. you want to solicit for another job), this data has to travel over the line even when all I want to do is save a draft version of a document that I may decide to delete later on. Knowing that such data can be easily read by third parties when transferred over the internet, I personally rather restrict the times that I send data over the internet to a minimum.
To conclude, the web platform as an operating system makes you financially more dependent and is a threat to privacy. But feel free to join, I know I won't.
I just don't believe it's worth the risk of constantly being just one static_cast<> or bounds check away from catastrophe. So learn it if you like, but holy crap don't rely on it.
Well, what can I say, tons of applications do rely on C++. In fact, the Joint Strike Fighter's software will be written in C++ and we're talking about life support here; if the software fails, lives depend on it.
I mean, you could easily introduce a bug in an application no matter what language you're going to use. Using a good architecture is what makes the quality of software, not per se the language, only C++ has a richer toolset for designing your program's architecture while (and this is important) not having to trade in performance.
Personally, I wouldn't like to be the pilot in a plane that makes intense real-time calculations where suddenly the garbage collector freezes all the threads because he feels it's time to see if any memory needs to be cleaned up. So yes, I'd rather rely on C++ than on any garbage collected language for that sort of applications.
Now to go a bit deeper into the examples you state: The use of static cast is deprecated. If you find yourself using it, there's something wrong with the architecture of your application. The few cases where you do need it, you can write extensive checks and unit tests around that particular piece of code. And as for bounds checking: if you read or write outside the bounds of an array in C#, you will get a range exception, I don't see what the difference is with C++.
I feel that there's a lot of FUD created around C++. Feel free to post some real code samples that demonstrate how C++ is supposedly broken. Challenge me.
there are far better uses for your time than to fight a language that wants you to fail.
Learning a language like C++ trains you as a programmer in better understanding how things work "under the hood" so to speak. It makes me a better C# programmer, so it's well worth the time and the effort. Even when programming C# in situations where performance matters, your experience with C++ will help you understand which classes and methods to use and which to avoid on what occasions. You may feel that the language has let you down, but on such occasions it is best to call in the help of a mentor. Eventually, you'll be able to find the answers on your own.
I just re-read your comment and realized that I indeed misinterpreted a key sentence. I'm so used to people being against C++ and its features that I somehow got conditioned into interpreting things that way by default.
That said, if you find the time to continue this debate, I'm still curious to see in what situations multiple inheritance can introduce problems of its own.
It will be interesting to see what Brussels has to say about this.
Just a question: what has Brussels to do with this?
... but the C++ object model is not the only way to do OO. In many ways, it's a step removed from the original idea of independent objects communicating via message passing with late binding.
Could you specify exactly what step is removed from the original idea? In what way is C++ violating the principle of "independent objects communicating via message passing with late binding"? (examples?)
One could make a reasonable argument that it is the projection of the original concept onto the C++ implementation that causes the lack of cleanliness
What you refer to as a lack of cleanliness is basically a way to allow for optimizations. Very strict concepts cause a lot of overhead that is just not acceptable in situations that require high performance.
... and that while multiple and virtual inheritance can compensate for that to some extent, they also introduce problems of their own.
Please give an example of these problems they supposedly introduce. I'm sure I'll be able to size them down to either (1) a conceptual flaw in the way the programmer designed the classes or (2) a misuse or lack of knowledge of syntax (such as not using virtual inheritance or dynamic_cast)
Personally, I think it's a bit of a cheap shot to make that argument but then implement a half-baked version of C++'s object model anyway rather than a more faithful representation of the original, simple and elegant concept of OO.
One solution does not fit all. That's why C++ gives the programmer the freedom to choose a different paradigm and allow him to not strictly use OO where the overhead would just not be acceptable. Let me ask you this: what is a better tool: one that can be used in many different ways to fit different purposes or one that enforces you to use it in one way only? I'd go for the first and that's what C++ is.
Saying that the OO model of C++ is half-baked is quite an ironic statement. You probably think that C# en Java have a better model while they don't allow multiple inheritance, to me *that* is half-baked; it forces me to use static methods if I want to centralize logic whereas C++ would allow me to inherit from multiple bases that contain code for each different aspect of the resulting class. I find this far more elegant than having to implement the same interfaces over and over again. (read Andrei Alexandrescu)
C++ is not half baked, it is a large toolbox that has many features, but apparently the average programmer is not capable of chosing what tool is fit for what purpose. This results in them choosing a reduced toolbox that requires less learning (other languages). If such a programmer is then confronted with C++, he choses the wrong feature of C++ to solve certain problems and cuts of his fingers with a knife way to sharp. If someone cuts his fingers with a sharp knife, does that mean that we should no longer use sharp knifes? Or does it mean that this person is incompetent and should either get an education or stay away from sharp knives to begin with?
This is why I don't have much time for the Java and C# designers who criticised C++ for supporting multiple inheritance, but then went ahead and used classes and virtual functions essentially the same way anyway.
I don't see how C# and Java could be used the same way if it comes to multiple inheritance.
I also like to remind that generics as now widely used in languages such as Java and C# initially started as templates in C++, only the latter has far better support.
I think that's rather flattering to C++. Generic code, in the parameterised type/function sense, is effectively the default in many functional languages. The compile-time meta-programming side of C++ templates... Well, Lisp, 'nuff said.
OK, other languages have it as well, but my point was that it's undoubtedly the C++ co
that's why I always define the macro
#define girlfriend friend
because I only want girlfriends to touch my privates.
Just a side-note on unit-tests and debuggers (actually off-topic): They're all fine and well, but bugs resulting from bad synchronization (e.g. use of mutex etc) in multithreaded programs will not be detected. Often, if an object is not well synchronized, the chance of having race conditions or lost updates are generally very small and therefor hard to reproduce, but in a production environment they would still come up fairly regularly. E.g. If there's a chance of 1 in a million for something to go wrong due to bad synchronization, you would only encounter it on average every one millionth time you debug your application (=never), while for a computer it's not a big deal to run a piece of code billions of times per day. By definition, unit tests are never run while other threads are touching the same memory because they are meant to test an isolated unit, which boils down to testing them on a single thread, so unit tests will even never spot them.
Don't get me wrong, it's good practice to have unit tests, but there are actually people out there (often IT managers) who imagine that if all code is covered by unit tests that this would guarantee that the program as a whole can't fail so I always like to add this disclaimer when talking about unit-tests or testing in general.
... should be hearsay. I noticed after submitting. My apologies to the grammar-nazis out there.
I also like to remind that generics as now widely used in languages such as Java and C# initially started as templates in C++, only the latter has far better support.
For those who think that garbage collection is the holy grail against leaks in a program, think again. While it may solve memory leaks, it doesn't solve resource leaks (like open connections, file locks,
If you want to know more, I'm always in for a discussion on the subject. Happy to inform.
"The crumbling buildings. The antiquated automobiles. The authoritarian presence. The warning to tourists to stay in designated tourist zones. The many desperate women offering their daughters as prostitutes."
Things the USA has as well as Cuba:
crumbling buildings - check
authoritarian presence - check
warning to tourists to stay in designated tourist zones - check
desperate women offering their daughters as prostitutes - check
Your point being?
My 2 cents.
... And politics is run by Belgians.
low-level languages like C fail on all those points compared to a higher-level language.
yes, that's why a high-level NATIVE language was invented to overcome that. It's called C++ and it's been around for quite a while. Welcome. New here?