Thread: Reinventing the Wheel

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?

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.

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.

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 implementations.

>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.

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?

>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.

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

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.

Originally Posted by samGwilliam

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.

Then perhaps you should improve your knowledge of C++.