Jump to content

  • Log In with Google      Sign In   
  • Create Account

BitMaster

Member Since 08 Aug 2000
Offline Last Active Today, 08:50 AM

Posts I've Made

In Topic: why that i get a signal SIGSEGV with my Multithread code?

Today, 02:12 AM

Personally I would point to Álvaro' advise in your other thread dealing with the same problem.

In Topic: Is there any reason to prefer procedural programming over OOP

25 June 2016 - 12:53 AM

Do you have any examples?  Certainly most of the container classes seem very non-OO to me.  Vectors don't know how to iterate over themselves.  Rather, the algorithms to do things with vectors are kept at arms length and divorced from the containers.  That's not in the slightest how OO designs tend to work.  In fact, it's the complete opposite.  OO is about coupling code and data.  The C++ containers are all about decoupling code and data.  Much of the standard library following the STL stuff has followed a similar pattern.


Even among the more traditional OO schools (heavy on inheritance and polymorphism) there are strong voices that member function should only be used where necessary and free functions be preferred (assuming of course you work in a language which has the concept of member functions to start with).

Setting that aside, this design makes the standard library containers more OO, not less. Based on the iterator category the compiler can select different algorithms depending on what kind of iterator it gets (all decisions are made at compile time which is a form of compile time polymorphism). That has several advantages. Without compile time polymorphism, I would we would either need virtual functions (runtime overhead) or having the algorithm tied directly to the container. Coupling the algorithm and container that strongly has negative side effects, for example every new container has to do the same work again. For example boost::small_vector is extremely similar to an std::vector. Thanks to that design decision the boost::small_vector can transparently make use of any algorithmic enhancement already available to the std::vector. There are also important questions about how to deal with algorithms taking input from more than one container as well.

Additionally, this design allows for cleaner extension. If I add a new algorithm I would have to modify every standard library container just to get it as a member function or have a free function when every other algorithm is not.

Avoiding a need for explicit member functions has other advantages in C++, especially once templates are involved. For example std::begin/std::end were added in C++11. When I have SomeType from SomeLibrary which would be sufficiently container-like I can still use it as a container in any template code simply by adding overloads for std::begin and std::end. That even works when I'm unable to modify SomeType's interface or it's an opaque type from a C library.

And even after all this, the nitty griddy internals of the std::containers are handled as member function and hidden from the outside. A container is supposed to store data (allocating and freeing memory as needed, initializing and destroying data at the adequate times). It must allow for adding and removing data. It must allow for accessing the data somehow (by index, by key, by sequence, ...). All of these things (which need the implementation details) are handled as member functions. Sorting a container or finding an element in the container or partitioning the container or anything else in algorithm or your own library is not part of the the container's job. It is good design not to pollute the interface of the container with 'also useful sometimes' but not 'mission-critical'. Note that some containers do consider some operations as part of their mission statement and add corresponding member functions (for example finding something in an std::set).

While we are talking about the containers, they also make use of composition in the form of an allocator. Currently you are stuck at compile time here (unless you are willing to do a bit of extra work) but C++17 has the polymorphic_allocator. Obviously that comes with a bit of extra cost then, but if polymorphism were free of any extra costs we would not be talking about any of this because the C++ standard library would have done it all in a more classic OO-y way.

In Topic: Including from the Standard C++ Library

25 June 2016 - 12:02 AM

All these cmath, string, etc. are still regular headers, just without extension. At least VS automatically adds references to the C++ runtime libs, so all you need to do is to include the headers. The libs are imported "under the hood".


Well, the standard allows for standard library headers to be 'something special' instead of regular text files but I'm not aware of any implementation which really does it.

That said, the file extension of headers is irrelevant. .h, .hpp or .hh are commonly used. .inl is sometimes used to name files which contain inline definitions which are often included from their parent header. Nothing stops you from including .foo or .bar files as headers. C++ does not care, although people who read you code might have objections.

Not using an extension for your headers is another way to go but since all C++ standard library headers are usually extensionless I would argue that is bad style.

In Topic: Is there any reason to prefer procedural programming over OOP

24 June 2016 - 10:43 AM

[...]

/sigh...
 
and yet in true gamedev fashion yet another interesting conversation is shut down by the standard 'my way is the right way' argument.  I try... I really do try to get these posts to be more than a simple 'do X not Y' type conversation and to get into why we do what we do.  And yet time and time again I am repeatedly shut down for simply attempting a real conversation.  
 
I will refrain from posting in the future...


You did notice the explicit disclaimer? I kinda wanted to make sure the second part of the post was taken the way it was meant to be taken (in jest and underlining the 'no one really agrees on what OOP is'-nature of the whole thing).

For the record, I also have a degree. I also learnt and used to believe a lot of what you said. However, times have also changed. I got a lot of real life experience. Compilers can now be relied on to support templates in a decent way. I stuck my toe into things which looked pretty crazy at first but actually had a lot of good to speak for them further in.

In Topic: Is there any reason to prefer procedural programming over OOP

24 June 2016 - 02:14 AM

Just for kicks, take a look how much inheritance or polymorhism is used in the C++ standard library.


Not that I disagree with your general point, but I don't know that I would necessarily call the standard library especially object-oriented - in fact, its original designer believes that the C++ standard library (or at least its predecessor) isn't even object-oriented at all, so I would say that the standard library is not really a useful example of "modern OO".


He is certainly entitled to his opinion but in my opinion the standard library contains a lot of what I would consider 'modern OO for C++' (while not 'classically taught OO' which nowadays often feels to me like the 'bad OO' anyway).

PARTNERS