Looking for critique/criticism

[Fizzgig]

Hey folks!

Been a while. I blame school starting up again and MIT's OpenCourseWare for being awesome... the latter anyway.

I'm going to try and keep this short this time; except for the question section at the end.

So, last time I asked for input I learned a lot. By a lot I mean truckloads. I was wondering if you would be so kind as to give me critique again? It's the same program as last time with all the recommended changes implemented as far as I know. If you're interested in a side by side comparison: My attempt at FileHandling up for your inspection

The only thing I wasn't able to do was incorporate iterators. Mainly because I need to create a custom iterator and figure out how to make a single iterator work on two vectors simultaneously. Can't really explain that last one better, my attempt at it is in the code commented out.

Now compiling with CodeBlocks (-wall -pedantic). After doing some research, I'm now comfortable in using CodeBlocks over the recommended compiler, mainly because the version of GCC it uses hasn't implemented any C++ 11 features. It scares me how much it sounds like I know what I'm talking about in this paragraph...

One last important thing (forgive me for bolding, but I really would like input on this):
Last time all the feedback was on how I implemented my solution and not so much the solution itself. Don't get me wrong, as I've said, that feedback has taught me a lot. I would however really appreciate some feedback on the solution; would you use/recommend something else? Perhaps something along the lines of databases? Something else? Or is my solution what you would recommend?
Either way, how would you advise obfuscating the contents of the file (Don't want players reading ahead)? Somehow encryption seems ill-suited to me.

On to code!
contentblock.h:

#ifndef CONTENTBLOCK_H
#define CONTENTBLOCK_H

#include <vector>
#include <string>
#include <iostream>

class contentBlock {
      public:
             // Set Functions
             void setBlockID(int blockid);
             void setText(std::string text);
             void setChoiceAmount(int choices);
             void addChoiceText(std::string choicetext);

             // Get Functions
             int getChoiceAmount();
             int getNextBlock(int ChoiceIdentifier);
             int getBlockID();

             contentBlock(int id, std::string &text, int choices, std::vector<int> &choiceids, std::vector<std::string> &choicetexts);
             friend std::ostream& operator<<(std::ostream &os, const contentBlock &block);

      private:
              int Choices, BlockID;
              std::string Text;
              std::vector<std::string> ChoiceText;
              std::vector<int> m_nextblockids;
};

#endif

contentblock.cpp:

#include "contentblock.h"

void contentBlock::setBlockID(int id) {
     BlockID = id;
}

void contentBlock::setText(std::string text) {
     Text = text;
}

void contentBlock::setChoiceAmount(int choices) {
     Choices = choices;
}

void contentBlock::addChoiceText(std::string choicetext) {
     ChoiceText.push_back(choicetext);
}

int contentBlock::getChoiceAmount() {
    return Choices;
}

int contentBlock::getNextBlock(int ChoiceIdentifier) {
       return m_nextblockids[ChoiceIdentifier];
}

int contentBlock::getBlockID() {
       return BlockID;
}

std::ostream& operator<<(std::ostream &os, const contentBlock &block) {
    os << "==========" << block.BlockID << "==========" << std::endl;
    os << block.Text << std::endl;
    os << "************************" << std::endl;
    os << "**Please Select:[1.." << block.Choices << "]**" << std::endl;
    os << "************************" << std::endl;

    for (int i = 0; i < block.Choices; i++)
        os << i+1 << ") (" << block.m_nextblockids[i] << "):" << block.ChoiceText[i] << std::endl;

    os << "=========/" << block.BlockID << "==========" << std::endl;
    os << "Option (999 exits): ";
    return os;
}

contentBlock::contentBlock(int id, std::string &text, int choices, std::vector<int> &choiceids, std::vector<std::string> &choicetexts)
: Choices(choices), BlockID(id), Text(text), ChoiceText(choicetexts), m_nextblockids(choiceids) {}

main.cpp:

#include <fstream>
#include <sstream>
#include "contentblock.h"

std::vector<contentBlock> readContent(std::string file);
void treeLoop();
int StringToNumber (std::string &text);
int getUserInput();

int main () {

    treeLoop();

    return 0;
}

std::vector<contentBlock> readContent(std::string file) {
      //variable setup
    int blockid, choices;
    std::string Temp, text;
    std::vector<contentBlock> Block;

      //stream setup
    std::ifstream contentStream(file.c_str());

      //if to check file access.
    if (contentStream.fail())
        std::cout << "File access failed.\n";

      //while to read contents of file
    int i = 0;
    while (contentStream.good()) {
        std::vector<std::string> choicetext;
        std::vector<int> nextid;

          // Retrieve and set BlockID
        getline(contentStream, Temp, '#');
        blockid = StringToNumber(Temp);

          // Retrieve and set Text
        getline(contentStream, Temp, '#');
        text = Temp;

          // Retrieve and set ChoiceAmount
        getline(contentStream, Temp, '#');
        choices = StringToNumber(Temp);

          // Retrieve and set NextIDs and ChoiceTexts
        for (int j = 0; j < choices; j++) {
            getline(contentStream, Temp, '#');
            nextid.push_back(StringToNumber(Temp));

            getline(contentStream, Temp, '#');
            //DEBUG: std::cout << "Block " << i +1 << ": " << Temp << std::endl;
            choicetext.push_back(Temp);
        }

        contentBlock temp(blockid, text, choices, nextid, choicetext);
        Block.push_back(temp);
        i++;
    }// end while

    return Block;
} // end readContent function

void treeLoop() {
      // variable setup
    std::vector<contentBlock> primaryVector;
    int ChoiceSelector, PrimaryVectorSize, CurrentBlock, Temp;
    std::vector<int> TempVector;
    std::vector<int>::iterator IntVectorIterator;

    primaryVector = readContent("Story.txt");
    PrimaryVectorSize = primaryVector.size() - 1;

      // Create vector of BlockIDs
    for (int i = 0; i < PrimaryVectorSize; i++)
        TempVector.push_back(primaryVector[i].getBlockID());

      // Need to write custom iterator for this
    /*for(IntVectorIterator = primaryVector.begin();
            IntVectorIterator != primaryVector.end();
            IntVectorIterator++) {

        TempVector.push_back(*IntVectorIterator.getBlockID());
    }*/

      // For debugging purposes.
    /*std::cout << "Array contents:\n";
    for (int i = 0; i < PrimaryVectorSize; i++)
        std::cout << i << ":" << TempVector[i] << std::endl;*/

      // Initial setup. Will change this when I add save/load functionality.
    CurrentBlock = 0;
    std::cout << primaryVector[0];
    ChoiceSelector = getUserInput();

      // Runs until the user enters '999' as input.
    while (ChoiceSelector != 999) {

          // while to check and correct input.
        while (ChoiceSelector < 1 || ChoiceSelector > primaryVector[CurrentBlock].getChoiceAmount()) {
                std::cout << "You have entered an invalid choice. Please select one from the list. [1.." 
                          << primaryVector[CurrentBlock].getChoiceAmount() << "]: " ;
                ChoiceSelector = getUserInput();
        }// end inner while

        Temp = primaryVector[CurrentBlock].getNextBlock(ChoiceSelector - 1);

          // runs comparison to determine what the NextBlock is going to be.
        for (int i = 0; i < PrimaryVectorSize; i++) {
            if (TempVector[i] == Temp) {
                //DEBUG: std::cout << "Temp: " << Temp << " vs TempVector[" << i << "]: " << TempVector[i] << std::endl;
                std::cout << primaryVector[i];
                CurrentBlock = i;
                break;
            } // end if
        }// end for

        /*for(IntVectorIterator = TempVector.begin();
                IntVectorIterator != TempVector.end();
                IntVectorIterator++) {
            if (*TempVector == Temp) {
                std::cout << primaryVector[i]; // This is going to be a problem
                CurrentBlock = i;
                break;
            } // end if
        }// end for  */

    ChoiceSelector = getUserInput();
    }// end outer while
}// end treeLoop function

int StringToNumber (std::string &text) {
    std::stringstream ss(text);
    int result;
    return ss >> result ? result : 0;
}

int getUserInput() {
    std::string userinput;
    std::cin >> userinput;

    while (StringToNumber(userinput) == 0) {
        std::cout << "Incorrect input. Please enter a valid choice: ";
        std::cin >> userinput;
    }

    return StringToNumber(userinput);
}

To accomodate the change of the IDs from strings to int, I'm uploading a new .txt should you want to see the code in motion. You don't need to change the extension this time. Find attached.


Now for a murderous tl;dr section. Enter at own risk...

Questions
(In no particular order)

I got a little lazy with my questions last time; I apologize to anyone who managed to read through that.


1) I created a new thread because I was unsure of the rules on Necro'ing here. I read the forum rules. I read that bumping isn't allowed, but to a lot of people bumping and necro'ing isnt the same thing. Could someone give me the rundown on this?

2) Totally unrelated: Having done some rudementary research on the subject, should I ever go into something involving 3D (Games, visualization, CAD, etc) I will be using OpenGL (Mainly because I'm a sucker for the underdog). I was wondering... all these 3D modelling programs (3DS Max, Maya, etc), the files they output - how do you write code that work with them? Do you have to use libraries? Who maintains those, the companies themselves or 3rd parties? Or is it a case by case thing?

3) Related to #2: In my reseach, I mostly got the impression that OpenGL is playing catch-up with DirectX's feature set. Should a person have/want to write an OpenGL game engine from the ground up wanting a specific feature from DirectX that OpenGL lacks, can it be coded into the engine itself? My uneducated guess would be that if you could that, there would be a drop in the execution speed of that feature. I base that on my idea that it would have to work through more layers of software than it would if it was "lower down" in OpenGL itself. Please feel free to correct me on this. Now a really out there question: Say you wanted to write a game engine, but didn't want to use OpenGL or DirectX and do everything from the ground up (Which I know is kind of insane)... is that even doable? Would graphics card drivers still work or would you need to write new ones? How big a task is this? Could you possibly do this in say... 3 years?

4) In the previous thread, I asked for book recommendations and phantomotap kindly supplied a list. I found a very cheap second-hand copy of Effective C++, 3rd Edition, but it's a first print. Should I rather buy the PDF online (Which is slightly more expensive)? In fact, in general, should I worry if I can't get the latest Editions or prints? Online stores make it so hard to find out which print (versus editions) of a book they are actually selling...

5) After the refactoring of my program, the .exe size doubled. Should this worry me? If you have the time, would you mind speculating as to why this is the case, either way?

6) Getting back to GCC not having the C++ 11 features (At least, not all of them). Please don't think me entitled in asking this, in fact I'm asking to get informed and avoid that. C++ 11 was ratified in 2011 and we are rapidly nearing the end of 2012. My assumption is that these things are mostly maintained/updated by volunteers (and would thus take longer). What is a reasonable timeframe of when we can expect full C++ 11 support? I REALLY want to sink my teeth into that new thread stuff C++ 11 brings (Even though my understanding of anything beyond the most rudimentary is severly lacking). I like punching above my weightclass

I feel like I'm forgetting something... perhaps I can edit it in should I remember in time...

[grumpy]

On your code, rather than passing std::string's by value, pass them by const reference. Since passing by value actually creates a copy, and copying an std::string can mean copying a significant amount of data (depending on its contents) better to avoid the copy. Optionally, you can do that with any type, but the gains are greater for objects that do (or potentially do) have a fair amount of data to be copied. [Don't, however, extrapolate from my advice and start trying to return references to privsate class data from from your member functions - that is a really bad idea. In some circumstances, using references is a good idea, but not in all circumstances].

The purpose of stream insertion operators (operator<<) is, conventionally, to write an object to any stream in a manner that allows it to be re-read using extraction operators (operator>>). Using your implementation of a stream operator to write out a series of user prompts is not a good idea. Better to leave that sort of thing outside the implementation of stream operators, and allow code that users the operators to do things like prompting users (eg assuming they know the stream being written to is std::cout).


There are a few stylistic things I might quibble over, but overall your code is not bad. I do believe in functions being named in a manner that conveys information about what it achieves, rather than how it is implemented. For example treeLoop() is more informative about the fact your function contains a loop, but not particularly informative about what is actually being achieved.

I generally suggest avoiding comments if at all possible. Instead break the code into small pieces, and ensure both variables (within functions), the arguments (of functions), and the functions are all well named enough that the names convey useful understanding to the reader, without needing comments. I'm not saying never use comments. But use other approaches (naming things, structure, etc etc) to make your code understandable, and minimise the need for comments.

The only thing I wasn't able to do was incorporate iterators. Mainly because I need to create a custom iterator and figure out how to make a single iterator work on two vectors simultaneously. Can't really explain that last one better, my attempt at it is in the code commented out.

Unless you have a specific need for iterators that affect two vectors simultaneously, avoid them. There is no prize for maximising the number of techniques you employ. The real prize is code that works, is easy to understand, easy to get right, and easy to change without breaking it.

One last important thing (forgive me for bolding, but I really would like input on this):
Last time all the feedback was on how I implemented my solution and not so much the solution itself. Don't get me wrong, as I've said, that feedback has taught me a lot. I would however really appreciate some feedback on the solution; would you use/recommend something else? Perhaps something along the lines of databases? Something else? Or is my solution what you would recommend?
Either way, how would you advise obfuscating the contents of the file (Don't want players reading ahead)? Somehow encryption seems ill-suited to me.

Encryption is a technique for reducing chances of people accidentally getting access to key data (or even reduce the chances of them deliberately getting access to key data, depending on strength of the encryption). I would suggest, if you care about protecting particular data, you spend a bit of time looking up computer security techniques, including encryption. Lack of understanding of a good technique is a poor excuse for developing a weaker technique that is easy to use.

That's a generic, high handed comment, I admit. But it's hard to give specific responses to your question, without detailed thought about what your program needs to do (as opposed to what features are "nice to have").


Your questions 1-4 are really things you need to decide for yourself. What works for one person does not work for another. People are pesky like that.

5) After the refactoring of my program, the .exe size doubled. Should this worry me? If you have the time, would you mind speculating as to why this is the case, either way?

It needn't worry you unless you are working on a machine with very limited memory, and a very small storage.

As to why, there are many reasons. In general, the effect of refactoring on (say) executable size is very sensitive to how the compiler (or its optimiser) is implemented. Which means it is often hard to explain, without looking into the internal workings of your compiler.

Generically, however, refactoring usually means your code contains a lot of small functions that are hard to break down further - it takes more advanced techniques by the compiler to optimise for size. That makes it harder for the compiler to apply certain optimisation techniques that recognise repetition of code within a function, or to eliminate instances of dead or repeated code.

However, the advantage is usually code that is easier to maintain. Given a choice between code with a small executable or code that is easier to maintain, I'll go for the maintainable code, unless the target machine has very limited resources.

6) Getting back to GCC not having the C++ 11 features (At least, not all of them). Please don't think me entitled in asking this, in fact I'm asking to get informed and avoid that. C++ 11 was ratified in 2011 and we are rapidly nearing the end of 2012. My assumption is that these things are mostly maintained/updated by volunteers (and would thus take longer). What is a reasonable timeframe of when we can expect full C++ 11 support? I REALLY want to sink my teeth into that new thread stuff C++ 11 brings (Even though my understanding of anything beyond the most rudimentary is severly lacking). I like punching above my weightclass

Well, put it this way .... The C++ standard evolved for ten years before it was ratified in 1998. Even with that history, it wasn't until about 2002 or 2003 that available compilers supported a substantial proportion of that standard (in both language and library).

Support of C99 (the 1999 C standard) was still relatively uncommon in 2004, but is more common now.

Generally, unless you are prepared to pay really good money for a team to develop a complete C++11 compiler and library, you can expect to wait at least five years for a complete implementation, whether commercially or not. It takes time to do these things right.

Compilers are complex bits of code. C++ is a pretty complex language and library, and C++11 introduces a fair number of new language and compiler features.

[hk_mp5kpdw]

Your classes "get" member functions should be declared const.



... Dark Crystal fan?

[manasij7479]

6) Getting back to GCC not having the C++ 11 features (At least, not all of them). Please don't think me entitled in asking this, in fact I'm asking to get informed and avoid that. C++ 11 was ratified in 2011 and we are rapidly nearing the end of 2012. My assumption is that these things are mostly maintained/updated by volunteers (and would thus take longer). What is a reasonable timeframe of when we can expect full C++ 11 support? I REALLY want to sink my teeth into that new thread stuff C++ 11 brings (Even though my understanding of anything beyond the most rudimentary is severly lacking). I like punching above my weightclass

Btw.. GCC 4.7 's threading library is just about complete. (afaik)
Don't confuse core language features with libraries.(I 'think' the thread library still depends on pthreads to compensate....but my assumption may be terribly wrong)

(At this moment, you'll not find anything significant missing when it comes to learning std::thread s. I just did a month ago.)

[kmdv]

On your code, rather than passing std::string's by value, pass them by const reference. Since passing by value actually creates a copy, and copying an std::string can mean copying a significant amount of data (depending on its contents) better to avoid the copy. Optionally, you can do that with any type, but the gains are greater for objects that do (or potentially do) have a fair amount of data to be copied.

If we are talking about C++11 here, it should be mentioned that it isn't necessarily like this.

There are already many articles about move-semantics, but reading them one might still not see all the advantages. There are many situations where you actually want a parameter (like the one of type std::string) to be passed by value instead of by reference.

Let's consider a simple class with one parametrised constructor (pre C++11):

class Info
{
public:
    explicit Info(const std::string& textA):
        mTextA(textA)
    {
    }
private:
    std::string mTextA;
};

Reading further about move-semantics, you might want to eliminate an unnecessary string copy:

class Info
{
public:
    explicit Info(const std::string& textA):
        mTextA(textA)
    {
    }
    explicit Info(std::string&& textA):
        mTextA(std::move(textA))
    {
    }
private:
    std::string mTextA;
};

Good, but what about a 2-parameter function? Would you implement all the possible combinations?

class Info2
{
public:
    Info(const std::string& textA, const std::string& textB):
        mTextA(textA), mTextB(textB)
    {
    }
    Info(std::string&& textA, const std::string& textB):
        mTextA(std::move(textA)), mTextB(textB)
    {
    }
    Info(const std::string& textA, std::string&& textB):
        mTextA(textA), mTextB(std::move(textB))
    {
    }
    Info(std::string&& textA, std::string&& textB):
        mTextA(std::move(textA)), mTextB(std::move(textB))
    {
    }
private:
    std::string mTextA;
    std::string mTextB;
};

Implementing n-ary function would result in 2^n overloads.

You do not need all this stuff at all. All you need is to pass the string by value, and let the caller choose whether to copy that string, or to move it:

class Info3
{
public:
    Info(std::string textA, std::string textB, std::string textC):
        mTextA(std::move(textA)),
        mTextB(std::move(textB)),
        mTextC(std::move(textC))
    {
    }
private:
    std::string mTextA;
    std::string mTextB;
    std::string mTextC;
};

As an example:

Info info1("message..."); // The compiler chooses to move its argument.

std::string processedData = ...;

Info info2(processedData); // The compiler chooses to copy its argument.

Info3 info3("one", processedData, "two"); // The compiler chooses to copy the second argument, and to move the other two.

... = processedData;

Conclusion:

Always pass by value if you intend to make a copy.

This means that if you plan to move to C++11 (move-semantics are already supported by GCC and MSVC), some of your code passing things by value (SetXXX, constructors, etc.) requires almost no changes, except the explicit calls to std::move(), which are necessary.

Don't, however, extrapolate from my advice and start trying to return references to private class data from from your member functions - that is a really bad idea. In some circumstances, using references is a good idea, but not in all circumstances

I wouldn't consider it a really bad idea. I meet many similar situations, and what I do is simply proper documenting such functions to be actually returning by value, and that const reference is only an optimisation. Certainly, storing such references is a really bad idea.

[grumpy]

You're over-estimating the value of move semantics, kmdv. With pass-by-value, move semantics can contribute to a performance improvement, but not in all cases. With pass-by-const-reference, such optimisation is never necessary.

My reason for not returning references to private data comes down to maintaining encapsulation. Also, there are only three things that can be done with a const reference returned by a function. The first is to store the reference (which you apparently agree is a bad idea). The second is to create a copy of the object referred to ..... which often negates the point of your optimisation. The third is to discard the return value (or reference) which, usually, means that the function is poorly designed (a design of a function is questionable if it returns a large object, by reference or by value, that the caller does not necessarily need).

[kmdv]

With pass-by-value, move semantics can contribute to a performance improvement, but not in all cases. With pass-by-const-reference, such optimisation is never necessary.

I have shown a simple rule of thumb, which enables reducing operation complexity from O(n) to O(1). Saying that it is never necessary with pass-by-const-reference makes me think you did not understand my example.
Certainly, there are situations where passing using move-construction could be slower (e.g. large trivially copyable objects), but such are exceptions like many others, and should be profiled first.

[Fizzgig]

The purpose of stream insertion operators (operator<<) is, conventionally, to write an object to any stream in a manner that allows it to be re-read using extraction operators (operator>>). Using your implementation of a stream operator to write out a series of user prompts is not a good idea. Better to leave that sort of thing outside the implementation of stream operators, and allow code that users the operators to do things like prompting users (eg assuming they know the stream being written to is std::cout).

I think I get what you are saying here, I'm just struggling to see how I'm going to go about making that work here. I will think on it.

I generally suggest avoiding comments if at all possible. Instead break the code into small pieces, and ensure both variables (within functions), the arguments (of functions), and the functions are all well named enough that the names convey useful understanding to the reader, without needing comments. I'm not saying never use comments. But use other approaches (naming things, structure, etc etc) to make your code understandable, and minimise the need for comments.

The comments within the functions, etc. were just to help me speed read through stuff when looking for logical errors, etc. I will remove them. Are you saying however that I shouldn't use those massive blocks of comments I usually see people use just above a function? Or is that one of the exceptions you were talking about?

Encryption is a technique for reducing chances of people accidentally getting access to key data (or even reduce the chances of them deliberately getting access to key data, depending on strength of the encryption). I would suggest, if you care about protecting particular data, you spend a bit of time looking up computer security techniques, including encryption. Lack of understanding of a good technique is a poor excuse for developing a weaker technique that is easy to use.

That's a generic, high handed comment, I admit. But it's hard to give specific responses to your question, without detailed thought about what your program needs to do (as opposed to what features are "nice to have").

I'm not exactly sure what you are trying to say here. I know more or less the basics of what's involved with encryption, I just don't know if it's a suitable solution to what I want to achieve. As to what I actually aim to achieve is; how to put it...
I'm writing this very "basic" game in order to learn more/faster. Having a project to work on is something that got recommended to me by countless people as an effective strategy for learning to program. What I want this game to do is very simple 5-stat combat (RPG jargon: Strength vs Dexterity, etc) with a complex dialog system. That's my main focus here, is creating a simple way to move about in a complex dialog tree. That's why that function was called treeLoop() (A name I now in hindsight realize is a bad name) -- it looped through my dialog tree. As to the specifics of why I want to make this file unreadable to everything other than my program, to a reasonable degree, is basically because it contains the story/dialog and, should this game ever become a *real* thing, I wouldn't want players to be able to read ahead. That was a long sentence. The reason I think encryption is ill-suited is basically because it would be "overkill". Too much security at too high a price (De/encryption to my knowledge is CPU hungry - eager to be proven wrong).

Your questions 1-4 are really things you need to decide for yourself. What works for one person does not work for another. People are pesky like that.

I must have explained myself very poorly then, because #4 should be the only opinion-based question. I will endeavour to better:

#1) As I've come to understand the terms;
Bumping: A thread you have vested interest in is low on the first page or may have crossed over into the 2nd or 3rd pages of the (sub)forum simply based on the high-traffic of incoming (new) threads, or because the people who can/should reply aren't online at the time. You make a new post within that thread to "bump" it back to the top of the first page so it doesn't fall into obscurity.
Necro posting: The time varies from forum to forum, but generally there is a set amount of time after the last post within a thread has occurred that the thread is then considered "dead". Posting in this thread essentially "brings it back to life" in the eyes of the VirtuaPopulace and is tantamount to sacrilege for some (Much like how typing in all caps is seen as shouting), regardless of how relevant/informative/helpful your post might happen to be.
While I do see that the distinction itself could be subjective, how a forum comes down on it cannot be. The only way that could work is if it's left up to the individual moderators' discretion.
The only reason I'm asking really is because I would like to reply to some folks here: Questions about C++ and programming in general from a newbie
Otherwise I will send them PMs and hope they don't mind.

#2) I guess what I'm asking here is; are there premade libraries available? Should they exist, do the companies themselves maintain/distribute these or 3rd parties?

#3) For instance, can someone code a specific feature, let's say some new shader technology that DirectX has but OpenGL lacks, into the engine itself? Would this then run slower than it would if it were "native" to OpenGL?
Second part of the question: Could that be done? With no direct support from the hardware companies, could you make something like DirectX/OpenGL? Would you have to make new GFX-card drivers or is that unnecessary?
I know the second part is slightly crazy, but I'm interested in discussing its hypothetical feasibility.

#4) I guess I'm just asking for your opinions here. Should I expend extra time and energy in tracking down latest editions/prints or not?

Generically, however, refactoring usually means your code contains a lot of small functions that are hard to break down further - it takes more advanced techniques by the compiler to optimise for size. That makes it harder for the compiler to apply certain optimisation techniques that recognise repetition of code within a function, or to eliminate instances of dead or repeated code.

This makes a lot of sense. Thanks for taking the time to explain it.

Well, put it this way .... The C++ standard evolved for ten years before it was ratified in 1998. Even with that history, it wasn't until about 2002 or 2003 that available compilers supported a substantial proportion of that standard (in both language and library).

Support of C99 (the 1999 C standard) was still relatively uncommon in 2004, but is more common now.

Generally, unless you are prepared to pay really good money for a team to develop a complete C++11 compiler and library, you can expect to wait at least five years for a complete implementation, whether commercially or not. It takes time to do these things right.

Compilers are complex bits of code. C++ is a pretty complex language and library, and C++11 introduces a fair number of new language and compiler features.

Thanks for taking the time to explain this to me, really. I guessed at some of this, but it's nice to know.

Your classes "get" member functions should be declared const.



... Dark Crystal fan?

Done. Also, I wondered if/when someone would pick up on that, hehe.

Don't confuse core language features with libraries.

Please keep in mind that my competence level should be considered as extreme basic. I've only very recently taken up coding in as serious capacity as I am able to for the moment. Currently, I'm like a kid in a candy store (if free samples were the order of the day), stuffing my face with anything I can get my hands on. Basically what I'm saying here is; I'm still learning and I'm bound to make silly errors, but as you guys are talking I'm making notes (to research full meanings, etc. later).

@kmdv: What you and grumpy are discussing at the moment is a little over my head, tbh (But I will make a note of this and try to research it at some point). What I can say is this however; while I did talk about C++ 11, technically I'm not allowed to use it atm. Long story.