The Big Programming Thread - Page 139

On May 30 2012 03:43 gyth wrote:

It isn't fair to indict OOP based on how C++/java tacked on their buzzword support.

On May 30 2012 07:38 Millitron wrote:
Speaking of heated debate topics, why is GO TO considered such a bad feature for a language to have?

I mean, I get that if you are completely careless with it, you can access memory that hasn't been allocated for your program, but it's extremely hard to screw up that bad. You almost have to force it to happen.

The thing is though, GO TO provides an effective way of exiting complex control structures. It is a gigantic pain to try to get a large group of nested for-loops to terminate early without GO TO, but with GO TO, it can be done with the addition of a single if-statement.

I was making a Turing Machine simulator for a class I was taking. The simulator was written in Java. The state of the machine ended up being stored in a 4D array, meaning it had to be accessed by a nesting of for-loops. It was such a pain to break out of those loops without GO TO.

On May 30 2012 01:26 typedef struct wrote:
This debate says a lot about object-oriented programming in general. You'd never find this kind of disagreement about a fundamental concept in a functional language/style.

Moving the functionality into the class you are accessing (the technique getdatsu posted) is only the correct solution if said functionality is something the class is directly responsible for. If not, you're just adding more responsiblities to the class (in violation of the Single Responsiblity Principle).

Friend is almost never the answer, and if you're new to C++ you should forget that keyword exists (as evidenced by the fact that plenty of good OOP languages don't have it).

Providing a getter method is usually the best solution. You can see this by exploring one of the many well-written open-source OOP code bases out there. You will see getters/setters used, but not abused.

It's pretty easy to tell if you're overusing getters/setters, because you'll get f*cking sick of writing them and be tempted to just make everything public. If you run into this situation, you probably have too few classes for what you are trying to do, and should break some of them up.

On May 30 2012 08:15 RoyGBiv_13 wrote:


Work for a company that builds a C/C++ compiler. Here is my chiming in on why getters/setters is bad from a performance standpoint (thus design), and also why you should be glad GOTO has been wiped.

These practices are not mainstream, and have for the most part been purged from the global corporate and open source code base, and for a reason! It is dismal that getters/setters is being snuck back in by high school CS teachers and design by committee curriculum. (I do not mean that any getter or setter is bad design, just that ALL classes MUST have getters/setters, and ALL variables MUST be private)

Lets talk performance. Ill start with GOTO because its an easy target:
Back in ye olden BASIC times, GOTO's were the go to (heh) method for program flow. This was alright, and did not typically affect speed of computations nor code size in any significant manner, because the code assembled almost directly into its literal machine code translation, with no optimizations. Then came Dennis Ritchie and C.

A compiled language will look almost nothing like itself when turned into machine code. Most notably is the inclusion of the stack and functions. Function calls replaced the LABEL A -> GOTO B -> GOTO A spaghetti by including the address of the branch to instruction onto the stack, and branching to the stack popping upon returning form a function. This is incredibly faster as a processor optimized for branch prediction would almost always have the next instruction loaded into the cache, compared to the GOTO method.

This is one of many reasons why people tell you to never use GOTO under any circumstance. It may seem efficient at the time, but in reality, it provides even more complexity where well thought out program flow would be better to begin with.

For Getters/Setters, the compiler will optimize out getters and setters 90% of the time and turn them into inline functions, which will be effectively what you wanted to put in your code anyway. the other 10% of the time, in things such as generic classes (http://en.wikipedia.org/wiki/Template_(C%2B%2B) )or getting/setting 32-bit or 64 bit structs that would like to be optimized into registers , you will feel a significant performance hit by using this sort of code design. It is not poor design to completely neglect getters and setters from code, as they definitely have their design uses for abstraction.

It is poor design to write code that needlessly complicated where a more understandable alternative exists that is also closer to what the cpu actually does. It should be noted that I have encountered a non-zero number of bugs due to getters/setters.

On May 30 2012 10:12 hacklebeast wrote:
Any suggestions for a c++ compiler? I don't need anything special, just something that works and is free (at least i'm assuming there are free ones beyond trial periods). I could just go down the list of them on wikipedia, but I figure asking TL is better than guess and check.

On May 30 2012 10:12 hacklebeast wrote:
Any suggestions for a c++ compiler? I don't need anything special, just something that works and is free (at least i'm assuming there are free ones beyond trial periods). I could just go down the list of them on wikipedia, but I figure asking TL is better than guess and check.

On May 30 2012 11:45 Zeke50100 wrote:


As mentioned before, Microsoft Visual Studio C++ Express is probably the best, free IDE available for C++ on Windows; however, it essentially only compiles for Windows. If you're specifically looking for a multi-platform compiler, I would recommend Qt.

On May 30 2012 09:47 sluggaslamoo wrote:
C++/Java/C#.net are pretty bad OO languages and are based on the Strousup stream of OO which was terribly designed in the first place.

There are much better functional/OO hybrids out there these days, but even Smalltalk which was the original true OO language (yes Simula was the first OO but I'm talking about in a practical sense) works completely different to mainstream OO languages.

See Ruby as a great example of a fully OO language which is based on Allen Kay's OO principles rather than Strousup's OO principles.

On May 31 2012 20:57 ForgottenOne wrote:


Can you, please, point me to some good reads on these topics?