At Fri, 4 Jun 2010 10:40:04 -0600, Bartlett, Roscoe A wrote:
I _will_ argue that OOP has costs to software complexity that are often under-appreciated.
[Bartlett, Roscoe A]
Any approach can be misused, including anything you might be trying to advocate (but I am not 100% sure what that is exactly).
Note that C++ was first designed in the early 80s primarily to support #2 object-oriented C++. I can see the reason for this bias for #3 and #4 given the nature of most of the Boost libraries and you can have that opinion if you would like.
I don't, so please read what I wrote and try to address that rather than to your preconceived notions of my ?bias.?
[Bartlett, Roscoe A]
I am not trying to put words in your mouth. I am just trying to pin down your argument/position. You can say that I have a "bias" for good software if you would like :-)
I'm not sure what that is supposed to mean. Isn't it safe to assume that everyone here has that bias?
Seriously, I am sorry if I misinterpreted you position with the position of others on the boost list who were arguing for a more template-heavy approach. I guess that you are arguing for more of a stack-based approach (see below).
No, I'm not arguing for any particular approach. I'm arguing that the tools we have in C++ are enough to effectively handle the problems you're trying to address with Teuchos. But I have to admit that I haven't read the whole paper so I may not know what all those problems are.
I would argue that the current accepted approaches to writing OO programs in C++ (i.e. #2 OO C++ features) make it too easy to create programs with undefined behavior (i.e. segfaults or worse) and as a result, the paranoia of undefined behavior in C++, memory leaks etc. lead to lots of bad programming practices and designs (see Section 1 in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf).
Seriously? Are you saying that a disciplined application of shared_ptr, weak_ptr, new_shared, et. al when dynamic allocations are called for is insufficient for most OO programs?
[Bartlett, Roscoe A]
As argued in the Teuchos MM document
http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf
these boost classes are a good start but they are *not* sufficient to build a safe and effective memory management system that encapsulated *all* raw pointers. What is missing for single objects, as described in Section 5.14 and other sections, is the Teuchos::Ptr class. Without integrating a class like Ptr in with the reference-counted pointer classes, you can't build a safe and effective memory management system in C++ that comes closer to eliminating undefined behavior.
Yes, wrapping every pointer and adding debug-mode-only checks for invalid usage is one way to help programmers debug their code. In a strict sense, though, eliminating undefined behavior requires keeping the checks on in optimized code. By the way, I actually like undefined behavior. It creates a clear boundary between valid and invalid usage. If all usages have defined behaviors, then neither the compiler nor runtime tools are allowed to interfere with such usages to help the user detect bugs. So I'm not in favor of eliminating it, at least not without some other measure of what's illegal.
Also, as described in Section 5.9.2, separating weak_ptr from shared_ptr is not ideal from a design perspective since it reduces the generality and reusability of software (see the arguments for this in the document).
I see the arguments. They boil down to, “there are complex cases where weakness needs to be determined at runtime rather than compile time.” IMO any design that uses reference counting but can't statically establish a hierarchy at ownership is broken. Even if the program works today, it will, eventually, acquire a cycle that consists entirely of non-weak pointers, and leak. So that *shouldn't* be convenient to write, so it's a problem with Teuchos that it encourages such designs. The fact that shared_ptr and weak_ptr are different types is a feature, not a bug. Furthermore if you really-really-really-really need to do that with boost, it's easy enough to build a type that acts as you wish (e.g. boost::variant<shared_ptr<T>, weak_ptr<T> >).
Did you read at least the sections called out in the reduced table of contents given in the Preface? I think these sections should address all of these questions (and more).
I am afraid I haven't had time, and probably won't until the end of next week.
When runtime performance or other issues related to dynamic allocations and classic OO are not a problem, classic OO C++ programs using runtime polymorphism are typically superior to highly templated C++ programs using static polymorphism
Straw man; I'm not arguing for ?templated C++ programs using static polymorphism.?
[Bartlett, Roscoe A]
Okay, the runtime vs. compile-time polymorphism debate is another issue (but a very important one). Are you instead arguing for a static and stack-based approach to programming?
No, I'm arguing for a value-based approach. If you're strict about it, you even turn references into values using type erasure… although doing so is often unfortunately so tedious that I wouldn't insist on it. See http://stlab.adobe.com/wiki/index.php/Papers_and_Presentations, particularly * Classes that work video: http://my.adobe.acrobat.com/p53888531/ * Thread Safety pdf (expanded version of slides in “Classes that work”): http://stlab.adobe.com/wiki/index.php/Image:2008_09_11_thread_safety.pdf * A Possible Future of Software Development video: http://www.youtube.com/watch?v=4moyKUHApq4 -- Dave Abrahams BoostPro Computing http://www.boostpro.com