PDA

View Full Version : Reinventing the Wheel



manofsteel972
06-30-2007, 11:47 PM
I noticed that a lot of people advocate using the STL vector, string, etc so as not to reinvent the wheel which is great for production code. You want to have something that speeds up production of a software product and make it easily portable to several platforms. For learning purposes, isn't reinventing the wheel kind of necessary? I read some older articles about programmers creating their own toolkits for programming. Do any of you have your own tookit that you put together? I also see that people still seem to be making their own string classes, BigNum classes, vector and the like despite all the advice to the contrary to just STL.

Do you think that saying well its easier to just use the vector class is better then advocating someone trying to implement their own version? We wouldn't have boost or linux or several other options if someone didn't think they could do it better?

Do you think that creating a personal tookit of your own classes is still advisable? If so, what would you recomend to include in a personal toolkit?

Daved
07-01-2007, 12:09 AM
For learning purposes, reinventing the wheel is not necessary, although it can be quite beneficial. When learning the language, you should first learn how to roll the wheel. This is why we tell people to use vector, string etc. Those tools were created and tested and do what you want better than anything you will build yourself most of the time.

Once you are comfortable and proficient with the use of the tools, then it is certainly a good idea to learn how they work. One way to do that is to create your versions. If you are creating your own versions, then using them in your own hobby code is also a good idea, as you can continue to debug them and learn from your mistakes and successes.

In the case of C++ more than most languages, it seems to me that people reinvent the wheel more than usual. I believe this is because there are so many people who are used to C with classes or pre-standard C++ (because they used it or because they were taught it by someone that used it). I don't think that it happens so often because people are doing it to learn, they often really think it is the best way.

Personally, I'd probably rather learn a different language or learn more tools in C++ than practice re-making existing ones, but I'm sure I'd enjoy that and get something out of it if I did it.

laserlight
07-01-2007, 12:28 AM
For learning purposes, isn't reinventing the wheel kind of necessary?
I agree, at least when one reaches that stage where he/she is able to use wheels effectively and now wants to deepen one's knowledge by learning how to design and make wheels. I just posted this in the C++ programming board, actually:
Write your own vector (and list, set, map, etc) class template to push yourself to your limit, thereafter use standard library containers (and those of Boost) unless that option is somehow not available to you.

Daved
07-01-2007, 12:41 AM
>> thereafter use standard library containers
The only clarification I would make to that is that you should be comfortable using those containers well before you start trying to write your own versions.

manofsteel972
07-01-2007, 01:13 AM
Well a solid understaning of the STL is something I would agree on. I know the main reason for learning STL is to speed up the learning curve. A student doesn't have to spend weeks or months creating their own versions of the STL before they can start using them in a program. They can start off with them right away. They are just a black box and all you have to do is learn the interface. I was just toying with the idea of creating a series of tutorials where you build on the basics with the whole goal being to implement something useful. I was thinking that your own version of the STL would be something that you could use, but since it would be reinventing the wheel why bother. When I do a search for tutorials, i find several that deal with how a linked list works, how a stack works, how to parse strings, etc. I was trying to think of a project that would tie them all together, that would also be useful.

@nthony
07-01-2007, 02:07 AM
Its worth investigating, in many cases a custom implementation can often be more environmentally tailored than its library counterpart, just take a look at some memcpy (http://www.vik.cc/daniel/portfolio/memcpy.htm) implementations.

Prelude
07-01-2007, 06:33 AM
>For learning purposes, isn't reinventing the wheel kind of necessary?
Absolutely. If you don't know how the standard library does things, you're not in a position to use it wisely. That's why you'll see lots of people use a vector when a set would be better suited, all because they simply don't see the difference.

>Do any of you have your own tookit that you put together?
Yes. The more experience you get, you'll find yourself writing the same thing over and over. Your toolkit is a collection of easily reusable code that handles the things you keep repeating.

>I also see that people still seem to be making their own string classes, BigNum classes,
>vector and the like despite all the advice to the contrary to just STL.
Well, the standard library doesn't have a BigNum class. You'll see wannabes of the standard library when people are trying to learn of course, and a lot of people wrote their own classes when the STL wasn't standard. Another reason is that the standard library is very generalized and heavy weight. If you know what you're doing and don't need that kind of flexibility, you can trim the fat by writing your own specialized class.

>Do you think that saying well its easier to just use the vector class is better then
>advocating someone trying to implement their own version?
As with most advice, there are exceptions. Yes, you should prefer to use the libraries that are already written, tested, and in widespread use. No, you shouldn't be adamant about it and keep an open mind when you do need to step off of the beaten path. I think you're trying to apply our advice as gospel, which it isn't. If you don't want to use the standard library, or have a reason not to, don't.

>Do you think that creating a personal tookit of your own classes is still advisable?
Absolutely! A personal toolkit doesn't necessarily duplicate the efforts of the standard library. Sure, it can in some places. But it's there to help you be more productive by, get this, not reinventing the wheel.

>If so, what would you recomend to include in a personal toolkit?
Mine includes binary search tree and linked list implementations that are comparable to the standard library. I even have personal implementations of the standard library that are noticeably better, which I'll use instead. But for the most part, my toolkit consists of reusable chunks of code that I found myself writing often over the years. You can't just say "I'm going to build a toolkit" and do it in a few days. It's tailored to what you do and how you write code, which all comes together over a span of years.

CornedBee
07-01-2007, 06:52 AM
I always wondered about that, Prelude. I can't find your own implementations on eternallyconfuzzled. Any specific reason for that? Also, better in interface or implementation? And if it's implementation, then better than which specific implementation?

Prelude
07-01-2007, 12:01 PM
>I can't find your own implementations on eternallyconfuzzled. Any specific reason for that?
Depending on how I plan to use the code or where I've already used it, I can't make it public domain. And I only put code that's PD on my website.

>Also, better in interface or implementation?
The interface is well defined by the standard. Trying to improve it usually results in something worse, like Microsoft's "safe" library. :rolleyes:

>And if it's implementation, then better than which specific implementation?
The implementations I test against are Visual Studio, Borland, and GCC.

VirtualAce
07-01-2007, 06:08 PM
Way back in the days before the STL I had to write all of this stuff myself. Sad to say my implementations were so specific to my program that they would not serve well as a general purpose container.

But Prelude is right in that if you know how to implement a certain type of container you can trim a significant amount of fat when you roll your own. However performance often comes at the cost of compatibility which usually means yes your container is fast but perhaps not fast or as fast as the STL is in all instances.

I often write my own linked list classes to deal with render lists. A linked list is a very simple structure and I usually do not need all of the features that the STL offers nor do I need to use a library which accounts for all those features.

But for the most part I do use the STL quite heavily and it performs very well across a wide range of applications. Plus it's also nice to be able to use code that while it may not be 100% suited to your app, at least you don't have to code the container. The main bottleneck in my field of choice for programming is getting data to the video card. The less data I have to send across the bus the faster the game will be. So graphics and game programming is not about what you do render and update, it's about what you don't render and update that makes the biggest difference. Container speed is normally a moot point.

My previous version of my StarX engine, then called XSpace, used a vector for all of the lasers that were fired in any one sector. I used a simple brute force approach with no insert operations and never had a problem up to about 5000 lasers. Throw in some models, AI, scripting, etc, and you would have enough lasers and projectile tracking to have a very huge space battle at interactive framerates. The only container I've noticed some slow-downs in was std::map but that had more to do with how I was using it than the container code. You can misuse any type of container or apply it incorrectly or in the wrong situation. That does not mean the container code is bad.


So before you go code your own, understand how the container works in the STL, find out the parts you simply do not need, and profile the STL version and yours before deciding to use your own.

samGwilliam
07-07-2007, 11:47 PM
I tend to do it a lot, sometimes to brush up on my skills (I don't want to distance myself too much from the low-level aspects of the language) and sometimes because I'd rather create my own rather than learn how to use yet another API.

In fact, the reason for writing my (still comparatively small) GUI widgets library (as seen in my synthesiser) was because I couldn't work out how to extract a numeric value from a scrollbar under the Win32 API. I simply got frustrated and wrote my own tools that work how I want them to.

In retrospect, it was the best move because I later implemented some very specific controls (the shaping curves, etc) that probably are not available under the standard library of controls. I suppose I could have just used wxWidgets or something but, again, that means learning yet another API (which I probably should do at some point, though).

The class hierarchy needs some tweaking and there are many more UI elements I want to implement, but I think it's a nice bit of code that I've enjoyed writing.

ChaosEngine
07-08-2007, 03:03 PM
The class hierarchy needs some tweaking and there are many more UI elements I want to implement, but I think it's a nice bit of code that I've enjoyed writing.

This line neatly illustrates the difference between coding for fun and coding for work. I wrote my own GUI library in a job once too. It was really interesting and great fun. But I wasn't allowed start it until the project team had investigated that we really needed our own GUI library.

On your own time, re-invent all the wheels you want. Who knows, you may even come up with a better wheel? But while you're working an employer isn't paying you to make a better STL. He wants you to add saleable value to his software. Re-implementing the STL won't do that.

samGwilliam
07-10-2007, 01:04 PM
True, but I don't even know what STL is.

I'm a C programmer who uses classes occasionally.

CornedBee
07-10-2007, 01:09 PM
Then perhaps you should improve your knowledge of C++.

samGwilliam
07-10-2007, 01:12 PM
Should I?

I'm doing alright so far. I just don't like relying too much on other people's code.

And I don't generally consider myself a C++ programmer.

Daved
07-10-2007, 01:38 PM
>> I just don't like relying too much on other people's code.
That may work in some specific cases, but there are tons of reasons to rely on existing libraries over creating your own.

This is especially true of the standard library (part of which in C++ is referred to as the STL). The interface is standardized, so you can be reasonably sure your code will work for a long time on any platform. This also means that most other developers familiar with the language can understand what the code is doing because the library is part of the language. For your own library, it is almost assured that a developer new to the code will have to learn your API from scratch.

The standard library implementations are thoroughly tested because so many people use them. This contrasts with your own library that gets far less testing and will almost always have far more bugs. In some cases you can optimize library functionality for specific tasks you need, but the standard library implementations have all been highly optimized as well, and in many cases this will still be better than your own.

It seems to be a natural tendency to want to write your own solution rather than search for an existing one, but in the end the effort is much greater and the reward is smaller if you do. This is true even for non-standard libraries. In some cases you will find that there are no widely available and tested libraries for a specific task, and in those cases writing your own makes sense.

Your line probably stops at the C standard library. If you are programming in C++, though, that line should at least extend to the C++ standard library, and probably a lot further.

samGwilliam
07-10-2007, 01:47 PM
Just had a quick look at some STL docs.

Vectors? WTF's wrong with an array? I mean, seriously, it's built into the language. Oh, it says it 'eliminates the chore of dynamic memory allocation'.

I've never had a problem with new and delete - they take about 4 seconds to type. Hardly a 'chore'.

I imagine there's a string one too, when strings are already about as simple as it gets.

Ironic, really, as this seems like the textbook definition of reinventing the wheel for the sake of it.

Daved
07-10-2007, 01:55 PM
That same attitude can be applied to strcpy. How hard is it to write a loop? That's about 8 seconds. But that is also part of the standard library because it is a commonly used task, it is encapsulated in a function so there is no chance for the user to make a mistake and cause a bug by doing it themselves, and it can be optimized by the library implementors to do better than a simple loop.

Have you ever had memory leaks? Have you ever had an error where you deleted something twice? Have you ever tried to resize a dynamic array? Finding and fixing memory leaks is a chore. Finding memory related bugs in general is a chore. Resizing a dynamic array is a chore. The vector class eliminates those chores.

Why would you ever need a nail gun when a hammer will do just fine? Perhaps if you're building a house and hammering in thousands of nails, you'll think differently.

If you prefer C, that's fine, but I think your attitude about C++ is coming from a lack of experience with it.

laserlight
07-10-2007, 01:56 PM
I've never had a problem with new and delete - they take about 4 seconds to type. Hardly a 'chore'.
Typing new and delete (or rather, new[] and delete[]) is not the problem. The problem is having to rewrite the memory management logic for dynamic arrays, and making sure that it is both efficient and correct. For example, you have to ensure that delete[] is properly called. This might be done by using the destructor, but it also means that you have to write it in for every class that uses a dynamic array. Vectors and other standard containers take the memory management chore away by providing well tested and optimised libraries. Instead of having to call delete[] in your own destructor, the container's destructor handles it for you.


Ironic, really, as this seems like the textbook definition of reinventing the wheel for the sake of it.
Hardly. You probably reinvent the wheel far more often.

samGwilliam
07-10-2007, 02:04 PM
I suppose you have to draw the line somewhere. But arrays are built in. It'd be like writing your own add () function, instead of using the + operator (or something). And a string is just an array anyway, so that's equally as futile IMO.

Don't get me wrong, I can see the point of stuff like linked lists but why replace strings and arrays?

And I do tend to pick and choose what elements of C++ I use, but I'm perfectly comfortable with that.

laserlight
07-10-2007, 02:14 PM
But arrays are built in. It'd be like writing your own add () function, instead of using the + operator (or something). And a string is just an array anyway, so that's equally as futile IMO.

Don't get me wrong, I can see the point of stuff like linked lists but why replace strings and arrays?
Hear from the man himself: How do I deal with memory leaks? (http://www.research.att.com/~bs/bs_faq2.html#memory-leaks)

CornedBee
07-10-2007, 02:23 PM
Strings in C are "as simple as it gets"? You have some very low expectations.

Arrays are built in? Yeah, but dynamic arrays? Nope, they aren't.

Daved
07-10-2007, 02:23 PM
>> why replace arrays?
The vector is not a replacement for arrays, it is a replacement for dynamic arrays.

>> why replace strings?
Let's say you are creating a string that holds a bunch of formatted data that you plan to either write out to a file or use directly from the string. You build that string from the data in your app by adding to it (e.g. in a csv or xml format). You don't know how much data there will be, there could be only a little, there could be a lot.

How do you handle that with a C style string? You'd have to use dynamic memory allocation since the string could be huge. But you don't want to over allocate in case there isn't much data to handle. So you allocate something small to start off, and use strcat to append to the string as you go. But then what if the array fills up, you have to create a new array with a larger size and copy the contents from the old array to the new one, then continue concatenating. Just writing this code is a chore, let alone getting it right.

For the string class it would be as simple as:
std::string my_string;
while (more_data())
{
my_string += get_data();
}All that other stuff is handled automatically.

samGwilliam
07-10-2007, 02:25 PM
I'd use a linked list in that case.

Of course, I'd code it myself, too...

Daved
07-10-2007, 02:27 PM
A linked list of chars?

CornedBee
07-10-2007, 02:28 PM
A linked list for a string? You mean per character? Or per buffer chunk? And how do you then handle the thing? Using a bunch of specialized functions? Do you separate them into their own module?

Congratulations, you've just reinvented the wheel.

brewbuck
07-10-2007, 03:28 PM
I'd use a linked list in that case.

Of course, I'd code it myself, too...

Excellent idea. Now instead of using 1 byte per character, you use several times as much. Four bytes or so for the link pointer. One byte for the character itself. And potentially eight or more bytes for memory allocator bookkeeping for each allocated node.

Congrats, your method of increasing memory usage by a factor of 13x has truly impressed me.

ChaosEngine
07-10-2007, 03:28 PM
Vectors? WTF's wrong with an array? I mean, seriously, it's built into the language. Oh, it says it 'eliminates the chore of dynamic memory allocation'.

I've never had a problem with new and delete - they take about 4 seconds to type. Hardly a 'chore'.


Really? let's have a look at a piece of code then.


void SomeFunc(void)
{
int *x = new int[100];

SomeOtherFunc(x);


delete[] x;
}


we've allocated some memory, called a function, deleted our memory like a responsible programmer and all is happy in the valleys, right?

but let's have a look at SomeOtherFunc()


struct big
{
double d[100000];
}

void SomeOtherFunc(int *p)
{
for (int i = 0; i < 200; i++)
{
p[i] = i;
}

big *reallyBig = new big[100000];

// some code

delete[] big;
}

ok this code has 2 problem (apart from not doing anything useful). The first is that we've overwritten the bounds of our array. Not such a big deal, we should've passed in the size of the array, but it wouldn't necessary with a vector (which knows it's size).

The second is a bit trickier. You see, there's a very good chance that we don't have enough memory to allocate reallyBig. On a standards-compliant compiler, that means an std::bad_alloc exception will be thrown. Now we're in really big trouble since x will not be deleted.

ok, but we can catch the exception! so let's rewrite SomeFunc


void SomeFunc(void)
{
int *x;
try
{
x = new int[100];

SomeOtherFunc(x);

delete[] x;
}
catch (std::bad_alloc &)
{
delete[] x;
}
}

ahh, much better. except, we've swallowed the exception so the caller of SomeFunc doesn't know it failed. No problem, let's rethrow the exception.



void SomeFunc(void)
{
int *x;
try
{
x = new int[100];

SomeOtherFunc(x);

delete[] x;
}
catch (std::bad_alloc &)
{
delete[] x;
throw;
}
}


phew! dodged that bullet. except now another coder has changed SomeOtherFunc()!



struct big
{
double d[100000];
}

void SomeOtherFunc(int *p)
{
for (int i = 0; i < 200; i++)
{
p[i] = i;
}

big *reallyBig = new big[100000];

if (!ConnectToInternet())
{
throw Unconnected();
}

delete[] big;
}


ahh crap, now we have to add another catch clause. That sucks. To hell with that, let's just catch all exceptions.


void SomeFunc(void)
{
int *x;
try
{
x = new int[100];

SomeOtherFunc(x);

delete[] x;
}
catch (...)
{
delete[] x;
throw;
}
}


or instead we could just write


void SomeFunc(void)
{
std::vector<int> x(100);

SomeOtherFunc(x);

}

struct big
{
double d[100000];
}

void SomeOtherFunc(std::vector<int> & p)
{
for (int i = 0; i < p.size(); i++)
{
p[i] = i;
}

std::vector<big> reallyBig(100000);

if (!ConnectToInternet())
{
throw Unconnected();
}

}


I know which one is safer. I know which one is cleaner. I know which one is more extensible and I know which I'd prefer.

Feel free to keep using dynamic arrays.

and while I'm at it...

I just don't like relying too much on other people's code.
That statement is completely backwards. I don't like relying on my own code. I much prefer to use some existing code that's been tested and documented.

did it take you long to write your own os? your own compiler? browser? ok maybe that's pushing it, but have you written your own versions of cout/printf? ever written a gui library?

samGwilliam
07-10-2007, 07:25 PM
Not of chars. Clearly I wasn't reading the posts properly. I'd just use a bog-standard array, obviously.

But if a flexible, dynamic method of storage was really that important then I'd use a linked list.

What of it?

samGwilliam
07-10-2007, 07:26 PM
Really? let's have a look at a piece of code then.


void SomeFunc(void)
{
int *x = new int[100];

SomeOtherFunc(x);


delete[] x;
}


we've allocated some memory, called a function, deleted our memory like a responsible programmer and all is happy in the valleys, right?

but let's have a look at SomeOtherFunc()


struct big
{
double d[100000];
}

void SomeOtherFunc(int *p)
{
for (int i = 0; i < 200; i++)
{
p[i] = i;
}

big *reallyBig = new big[100000];

// some code

delete[] big;
}

ok this code has 2 problem (apart from not doing anything useful). The first is that we've overwritten the bounds of our array. Not such a big deal, we should've passed in the size of the array, but it wouldn't necessary with a vector (which knows it's size).

The second is a bit trickier. You see, there's a very good chance that we don't have enough memory to allocate reallyBig. On a standards-compliant compiler, that means an std::bad_alloc exception will be thrown. Now we're in really big trouble since x will not be deleted.

ok, but we can catch the exception! so let's rewrite SomeFunc


void SomeFunc(void)
{
int *x;
try
{
x = new int[100];

SomeOtherFunc(x);

delete[] x;
}
catch (std::bad_alloc &)
{
delete[] x;
}
}

ahh, much better. except, we've swallowed the exception so the caller of SomeFunc doesn't know it failed. No problem, let's rethrow the exception.



void SomeFunc(void)
{
int *x;
try
{
x = new int[100];

SomeOtherFunc(x);

delete[] x;
}
catch (std::bad_alloc &)
{
delete[] x;
throw;
}
}


phew! dodged that bullet. except now another coder has changed SomeOtherFunc()!



struct big
{
double d[100000];
}

void SomeOtherFunc(int *p)
{
for (int i = 0; i < 200; i++)
{
p[i] = i;
}

big *reallyBig = new big[100000];

if (!ConnectToInternet())
{
throw Unconnected();
}

delete[] big;
}


ahh crap, now we have to add another catch clause. That sucks. To hell with that, let's just catch all exceptions.


void SomeFunc(void)
{
int *x;
try
{
x = new int[100];

SomeOtherFunc(x);

delete[] x;
}
catch (...)
{
delete[] x;
throw;
}
}


or instead we could just write


void SomeFunc(void)
{
std::vector<int> x(100);

SomeOtherFunc(x);

}

struct big
{
double d[100000];
}

void SomeOtherFunc(std::vector<int> & p)
{
for (int i = 0; i < p.size(); i++)
{
p[i] = i;
}

std::vector<big> reallyBig(100000);

if (!ConnectToInternet())
{
throw Unconnected();
}

}


I know which one is safer. I know which one is cleaner. I know which one is more extensible and I know which I'd prefer.

Feel free to keep using dynamic arrays.

and while I'm at it...

That statement is completely backwards. I don't like relying on my own code. I much prefer to use some existing code that's been tested and documented.

did it take you long to write your own os? your own compiler? browser? ok maybe that's pushing it, but have you written your own versions of cout/printf? ever written a gui library?

I didn't read a single line of that (and I'm not going to), but it's entertaining to see just how much I've gotten under your skin!!

ChaosEngine
07-10-2007, 08:26 PM
I didn't read a single line of that (and I'm not going to), but it's entertaining to see just how much I've gotten under your skin!!

your loss, bro. You haven't "gotten under my skin", I was trying to help you. It's highly unlikely I'll ever have to deal with your code, so feel free to immerse yourself in all the misery of tracking down memory leaks and stack corruptions.

laserlight
07-10-2007, 10:57 PM
I'd just use a bog-standard array, obviously.
hmm... I am starting to suspect that you think that vectors are not standard. Although we often speak of the STL as if it were like the ATL, the truth is that the "Standard Template Library" really is standard, since it is incorporated into the C++ standard library. In fact, I understand that C++ strings were not from the STL to begin with. Therefore, you could just use a "bog-standard" std::string.


But if a flexible, dynamic method of storage was really that important then I'd use a linked list.

What of it?
What if you need random access? What if you want a container of key/value pairs with faster than linear time search? I think that it is better to be flexible in your choice of container, hence choosing one that best fits your solution. An array (including vectors) is often a reasonable "default" choice.


I didn't read a single line of that (and I'm not going to), but it's entertaining to see just how much I've gotten under your skin!!
You can stop trolling now. If you have made up your mind and refuse to listen to reason, then say so. It is not necessary to scorn the effort taken by someone else to explain things to you. If you continue with such an attitude, then you can expect no help from the users of this message board.

vart
07-11-2007, 12:21 AM
I just don't like relying too much on other people's code.

LOL... Be real - and stop joking...

You do not mean - that in your everyday work you only use your own hand made OS with hand-made compiler? To be sure that your exe relies only on your own hand-made code?

Please, please - leave your fantasies and come back to the real world.

Mario F.
07-11-2007, 05:50 AM
The attitude of the fella isn't new. You see that everywhere and not just in C or C++ circles. Some people "say" (and say is the operative word) they don't use external libraries, standard libraries, other people's code, etc...

It is always quiet entertaining to see these people complete lack of judgment and good reasoning. It is particularly entertaining to imagine these people having to face certain coding challenges like... oh... I don't know... having to handle complex mathematical operations without a math library, or coding their own lossless compression algorithm, or a regular expression parser... all just because they don't use other people's code.

As you say, vart. It's a joke.

MacGyver
07-11-2007, 06:14 AM
I didn't read a single line of that (and I'm not going to), but it's entertaining to see just how much I've gotten under your skin!!

This post is amazing.

I don't like using libraries myself. I've always been fine using standard libraries, but I just didn't like learning the ins and outs of 3rd party libraries that always seemed much larger and more complex than what I was aiming at accomplishing.

As time has gone on and I've been working on different projects, I've come to better appreciate libraries written for multiple platforms that tackle a good portion of what I want to do. Perhaps one reason is that I'm working on more and more larger projects than I have been in the past, although that's not saying much since I haven't really done much. :)

If you can't take the opportunity to read other people's posts, or to realize the benefit of using other tried and tested code, then as ChaosEngine said, it is your loss. I'm not sure why you would take pleasure in throwing someone's explanation back in their face when, by all appearances that I can see, their intent was to help you.

AverageSoftware
07-11-2007, 06:36 AM
Not of chars. Clearly I wasn't reading the posts properly. I'd just use a bog-standard array, obviously.

But if a flexible, dynamic method of storage was really that important then I'd use a linked list.

What of it?

If you need a concrete example, I work on a C++ program that was originally written circa 1995, and it's full of C strings.

This week I converted a few text-intensive functions from character arrays to C++ strings. Removing all of the C string manipulation crap and over allocated buffers trimmed around 500 lines from the program, and has reclaimed several thousand bytes of stack space.

I used to scorn C++ strings and containers too, but experiences like this were a hell of a wake-up call.

whiteflags
07-11-2007, 06:36 AM
The line of thought that you two are discussing is "No one could possibly code this better than me!" It's arrogance more than anything else, and people realize that. As far as I can see there is no reason to drive home the point of someone else if it will fall upon deaf ears in the first place. Let Mr. William be crushed by a wall of code he so enjoys to retype, and retype, and type yet again. This discussion has been over since Chaos Engine stopped responding.

Mario F.
07-11-2007, 11:38 AM
You are right Citizen. To each his own (sp?)

Going back on topic...

Only now, after one year of first starting dabbling in C++, did I start to become interested on the inner workings of the STL. Not so much because I felt a need to understand it, but because of curiosity.

Naturally, because my knowledge of C++ is still so limited, I'm only scratching the surface of what really means "understanding the inner workings of the STL". Nevertheless, the STL is proving to be an excellent learning tool in its own right and "reinventing the wheel" has been on my case a pure learning exercise. In fact, I dislike the term when applied here.

I don't honestly think using arrays is reinventing the wheel. I would rather prefer to think in creating new laws that govern how the wheel turns. Because that's the only use I can think for them when we see what the STL already offers.

What I'm feeling while I'm pretending to be a C++ programmer developing my own game is that arrays are far more common that what one is lead to believe by the literature warnings and advises on that matter. And this goes for other elements of the STL too like std::string. I feel the need to create new laws is very common.

However, my knowledge is flawed by both the fact I still smell like milk when it comes to programming in C++ and because I'm led by several book authors to develop a non-healthy attitude towards not believing in their advise.

When I'm told not to use exceptions when I can avoid it because of the tradeoff in speed and code size and leaves it at that, I have to ask "But what then when speed and size is not a problem, which is the case in most of the applications developed around the world?" The same applies to the STL in the sense that examples like the ones provided by Chaos are much more enlightening than simply advocating "don't do it because of [insert reasons here]" without also debating "When should you do what I'm telling you not to do"

These reasons, my friends are obvious to you. You know your C++ well. But we don't. We still smell like milk. And being youngsters on the matter whe are particularly prone to a) make mistakes in the choices we do, b) only listen to bad advise and c) be religious about our believes.