Any Tips On Writing More Efficient Code?

[Disch]

I don't understand what you mean, Lumpkin. How is vector more difficult than the alternatives? When do you have to use for loops with a vector that you don't also have to with arrays?

[N36fSL3A]

No, I mean replacing my current code I'd have to add more lines.

When do you have to use for loops with a vector that you don't also have to with arrays?

unsigned char* pixels = new pixels[imgsize];

std::ifstream file("example.dat");

file.read(pixels, imgsize);

[htirwin]

@lumpkin:

std::vector<unsigned char> pixels(imgsize, 0);

std::ifstream file("example.dat");

file.read(&pixels[0], imgsize );

[N36fSL3A]

wat



But still, I really don't need to use the extra variables it declares. Seems like a waste.

[Disch]

+1 htirwin

Raw pointers are 'bad' anyway. If you don't want a vector this would be my next approach:

std::unique_ptr<unsigned char[]> pixels( new unsigned char[imgsize] );

std::ifstream file("example.dat");

file.read(pixels.get(), imgsize);

RAII fo-evah

[N36fSL3A]

I don't understand what's so bad about them.

[BHX]

Lumpkin wrote:

Much faster that 2D arrays, and much simpler as well.

Huh? How is forcing a list to imitate a table faster than a multidimensional array that is designed to do tables? At least that is my understanding of 1D and 2D arrays, anything higher than that(3D, 4D, etc.), from my understanding is tables of tables

@Zereo
I wouldn't say they are better than another, I just made a poor choice of words. For my needs they are normally very interchangeable so I just decide which to use depending on if I have static maps I want to create or if I want to have some levels bigger than others.

[Disch]

I don't understand what's so bad about them.

Manual cleanup.

RAII is practically bulletproof.

[N36fSL3A]

I always use RAII when dealing with raw pointers.

@BHX
http://www.cplusplus.com/forum/articles/17108/

[htirwin]

But it's nice to have as many components of your program as possible, self contained so that you reduce the complexity made by the combination of components that makes up your program. So rather than have one class that manually allocates a bunch of stuff and deletes a bunch of stuff in the destructor, it's nice to have the components wrapped in their own RAII data structures so that they just free the memory when they go out of scope and you can add them or remove them and not worry about some other piece of code that is tied to them which is mixed in with your other code.

[3qX21hU5]

BHXSpecter wrote:

I wouldn't say they are better than another, I just made a poor choice of words. For my needs they are normally very interchangeable so I just decide which to use depending on if I have static maps I want to create or if I want to have some levels bigger than others.

Sorry about that, I didn't mean to imply that you said that. I was more just talking about the subject in general.

I just find it weird when people try and compare vectors and arrays in a general sense (IE vector's are better then arrays or vice versa). I can understand if there was a specific instance that they were comparing the two.

But trying to say arrays are always better then vectors or should I always use vectors instead of arrays just seems pointless to me. They both have their uses.

[o1vk4iN6]

@Lumpkin

try
{
    char* crybabycrymakeyourmothersigh = new char[100];

    throw;

    delete[] crybabycrymakeyourmothersigh;
}
catch( /* ... */ )
{
    // ...
}

There are numerous ways you could very easily forget to free memory.

[N36fSL3A]

That's not what I do. I barely use exceptions first off.

My code usually looks like

class MyClass
{
    MyClass();
    ~MyClass();
    // .....

    Uint8* ptr;
}

MyClass()
{
    ptr = new Uint8[100];
}

~MyClass()
{
    delete[] ptr;
}

(The RAIIght way to go...)

[o1vk4iN6]

So what's the problem ? It does exactly that except it's called implicitly, less writing for you.

[ne555]

¿where is your copy constructor?
¿where is your assignment operator?
¿why are you coding the same thing over and over again?

[Disch]

Lumpkin: But if you do that you also have to write copy ctor / copy asssignment / move ctor / move assignment.

Besides that's reinventing the wheel. unique_ptr already does all that, so why not use it?

[BHX]

Okay, first I respect Disch as a programmer so this isn't an attack on him.

Did you even read the full thing or just see the title and blindly agree?

Disch from that link wrote:

I probably should've made the article less opinionated. I actually tried to tone it back (I really dislike MD arrays), but it is still pretty 1 sided.

In any event, I agree that in general arrays should be avoided and that a container class should be used. But since STL doesn't provide a MD container, you're better off getting one from somewhere else (boost?) or making your own (above). It's much more preferable to vectors of vectors, IMO... and that's really the point I was trying to get across here.

Stroustrup quote from the article wrote:

The built-in arrays are a major source of errors – especially when they are used to build multidimensional arrays.
For novices, they are also a major source of confusion. Wherever possible, use vector, list, valarray, string, etc.

The article is based off Disch's opinion that they are evil. They are a major source of errors, but human error is also a major source of errors. For novices they're a source of confusion, but so is learning the driving laws and rules for getting your license. Confusion doesn't make something evil (otherwise anyone starting a new job would never get good as they would quit saying it was 'evil').

The first and most dominate error I can think of with arrays is declaring it to be a size (say 30 ints int array[30];, numbers 0 to 29) and then trying to access out of bounds on it array[31];.

Also, raw pointers, again opinion of preference. Everything Disch is saying is bad about them, others may not have a problem with. Lumpkin, you have to learn all aspects of C++ and form your own opinion of them and not blindly follow someone else's opinion on the feature. Just like I've seen mixed feelings on Boost here (for and against), but I've only used it once and it wasn't enough to form an opinion on it so I have not passed my judgement on it.

Lastly, Disch is right on the passing arrays to functions, but I can't say I've ever seen anyone use built-in arrays of different sizes often. When I code something and know my arrays are going to be separate sizes I either use vectors or just go through the added trouble of making separate special functions specifically for those arrays. Still doesn't make them evil, just adds a few extra lines and steps to your code.

[Albatross]

When Disch calls something "evil", it's typically because its makes making errors easier. In other words, Disch says it's evil = it's easy to misuse. :P

-Albatross

[BHX]

In that case I still stand by it isn't evil. Human error is evil as it is human error that makes it easy to misuse. :P

[Disch]

Something difficult to use is more prone to error than an alternative that is easier to use... therefore the more difficult thing is evil.

Human error is always a factor but the easier something is to use, the less chance there is for human error.