quote:

---

Surely putting the function body in the class definition tells the compiler that it would like the function to be inlined?

---

Yep it does, but I wasn''t thinking only of member functions - I meant template functions in general (e.g. std::find_if). But you''re probably write that it could cause problem with template classes.

Templates are great, easily one of the best features of C++. You can do some really cool things with them.

The problem is that you can easily confuse the hell out of other programmers with a template. The other problem is compatibility, although the range of C++ compilers have gradually added support for templates (this started several years back but took some time to come through) it''s still difficult to ensure that a template can compile with all compilers. It''s not uncommon for some compilers that claim complete compliance to throw errors up on very trivial matters.

So, as much as we like them we tend to use templates minimally. As for STL, that too is great. But I read the comments from people who say ''use STL, great time saver, etc'' with some humor. I''m not sure these people have ever worked across different formats at once. Unfortunately here STL too can suffer and you can quickly find that one compiler vendors interpretation of STL can be annoyingly different to another.

Our answer to the problem, in addition to minimizing the use of templates for the foreseeable future was to write our own version of STL that we can ensure works on the various compilers we use. This might attract a few flames or comments that something unholy was done here, but the fact is STL was causing us problems and we completely got around them and get a better, leaner, meaner, faster, and more portable (or should I say more controlled portable version) of the same things. We did admittedly cut out quite a few of the STL things we would clearly never use and we took advantage of being able to customize the memory management of resizable vectors, etc in a better way for each machine we work.

What did we give up? In terms of functionality, nothing. Like I said we got everything we wanted out of it and disposed of things we would never use. Of course, we gave up the benefit of having a good, tried and tested, debugged, etc version of STL and we did have to go through a process to get it to the same state. However, once we got that point we never looked back, our own STL with our own debugging traps and memory management that I mentioned earlier is too much to do without now.

The "truncated after 255" error is easy to disable - I do it all the time with #pragma warning.

Templates enable generic program which is very powerful and very fast. I''m really not overly concerned with compile times as much as with the end result - a stable, well-defined, and functional program.

I''ll be the first to say the MS is really dropping the ball with their VC++ compiler and not supporting member templates correctly. I''ve always thought MSVC supported partial specialization - I''ll have to check it out.

Unless you are developing for embedded systems (or limited memory) I wouldn''t quibble over 60KB here or there for an executables size.

Dire Wolf
direwolf@digitalfiends.com

quote:

---

The "truncated after 255" error is easy to disable - I do it all the time with #pragma warning.

---

You must be one of the lucky ones That pragma doesn''t help me most of the time.

Q122539

Here is the pragma statement that I use to fix the truncation error:

Something I've discovered is that the pragma must be placed before any include statement that brings in STL headers.

Example:

#include "CSettings.h"

#pragma warning( disable : 4786 4503 )

#include &ltwindows.h>
#include &ltstring>
#include &ltmap>

you would think that this would fix the truncation warning. If CSettings.h happens to pull in a STL header the pragma statement won't work. Since we are only disabling a warning, I typically make the #pragma statement the first line in a header or source file that includes map etc.

So, try this instead:

// whatever.cpp

#pragma warning( disable : 4786 4503 )

#include "CSettings.h" // may include STL headers

#include &ltwindows.h>
#include &ltmap>
#include &ltlist>

Hope this helps.

BTW Thanks for the IP to the Boost site.

Dire Wolf
direwolf@digitalfiends.com

Edited by - Dire.Wolf on January 4, 2001 1:38:32 AM

quote:

---

Original post by Dire.Wolf

I''m really not overly concerned with compile times as much as with the end result - a stable, well-defined, and functional program.

---

When compile times get to being 35 minutes rather than 5 minutes, it does get to being a hindrance on the development process...

quote:

---

Unless you are developing for embedded systems (or limited memory) I wouldn''t quibble over 60KB here or there for an executables size.

---

More like 600kb difference, in my experience.

quote:

---

Original post by Kylotan
When compile times get to being 35 minutes rather than 5 minutes, it does get to being a hindrance on the development process...

---

Yes templates increase the compile time, but they shouldn''t increase it by that much. That sounds more like an STL issue than a templates issue (which you alluded to in your first post). Our program at work is over 585,000 lines, over 3,100 files, and contains more than 90 templates (with every single one being instantiated multiple times) and I compile in 12 minutes flat (no STL).

Also, if compile times are an issue with you I would recommend staying away from VC++ as from what I''ve heard their compile times are MUCH slower than other compilers like BC++.

quote:

---

Original post by Kylotan
More like 600kb difference, in my experience.

---

Still wouldn''t make a difference to me. With games coming out on multiple CD''s I could care less about a few hundered extra kb if it means I get better reusability/maintainability.


Personally I, like freakchild, never use STL for a few reasons. One being the portability problems and the bugs that DO exist in it (and different bugs for every STL version). Another reason is that I want to KNOW how to create a linked list if I need one. And since the only way to learn is to actually CREATE one, I''ll have no reason to use the STL for linked lists since I''ll have my own tested version. Same goes with every other feature that STL contains. It''s not hard to create a linked list, or queue, or string class.


- Houdini

Houdini,

The one reason to use the STL is that it is standardized. It is doubtful that someone could create a faster vector class that maintains exception-safe and exception-neutral criteria and is faster than the STL one.

If you want to write a linked list to understand how its done - that's great and understandable. When you are coding in a non-game programming environment (mainly services delivery) you most certainly want to use tried and proven implementations over some personal implementation (unless the personal implementation fits a certain criteria or need).

I was just like you a while back. I didn't like reusing libraries because I always wanted to be in control of the details. As I started working in a corporate environment I realized that due to time constraints or compatibility reasons, it was better to start reusing code than reinventing the wheel. Why write a linked list for production code when one exists already?

Even though I'm preaching the value of reusing code, outside of my "corporate job" you'd never ever catch me reusing libraries other than the STL. I like to write my own networking, filesystem, windowing classes etc.

If you are concerned about portability of the STL you may want to look at STLPort. It seems to be very compliant with the STL spec not to mention being highly portable to other compilers.

Still, each and every one of us is entitled to his or her opinions. I feel that using the STL is a good thing and that it is compiler vendors who are hurting its usefullness.

Take care,

Dire Wolf
direwolf@digitalfiends.com

P.S. Does anyone know where to find the STL specification?

Edited by - Dire.Wolf on January 4, 2001 1:25:54 PM

STL != collection classes. The three main parts are the algorithms, iterators and containers but it also comes with various adapters (e.g. std::back_inserter) that make it work together nicely.

Another good thing about having something that''s standard is that you''re not the only that uses it, so other people write code that works with STL and you can use it no problem (e.g. boost). You could give all your own collection classes an STL style interface, but then you might as well just use STLport (and get the cool debug mode) then spending your time writing code that you don''t already have, or that don''t work the way want.

quote:

---

P.S. Does anyone know where to find the STL specification?

---

It''ll be in the C++ standard, you can get it from here but it''ll cost you $18

quote:

---

The one reason to use the STL is that it is standardized. It is doubtful that someone could create a faster vector class that maintains exception-safe and exception-neutral criteria and is faster than the STL one.

---

I had created a calculations DLL for our product at work and I needed some kind of dynamic array/linked list so I used the STL vector class.

I ran into a problem when the time came to port it over to Windows CE. Turns out that Windows CE doesn''t support the STL.

So I wrote my own version of STL''s vector class, tested it, fixed the few bugs, ported it, and everything worked like a charm.

I ran a performance test on STL''s vector and my version, by adding 1 million integers one at a time, then removing all 1 million one at a time. The results were that they were perfectly even. Mine was 1 millisecond faster first run, then 1 millisecond slower, then perfectly even, etc, etc.

For curiosity sake, my push_back function is ~20% faster, but my pop_back is about ~20% slower. I have yet to go through and look for tweaks to speed it up.

quote:

---

I was just like you a while back. I didn''t like reusing libraries because I always wanted to be in control of the details. As I started working in a corporate environment I realized that due to time constraints or compatibility reasons

---

Absolutely agreed that if you have time constraints that you should use whatever libraries will help you get the job done. Mind you, in may case it actually slowed down production, but I don''t too many people will port their games to Windows CE

quote:

---

Why write a linked list for production[i/] code when one exists already?

---

If it''s for production and you have time constraints and you''ve NEVER EVER written a linked list before, then I agree, absolutely. But I''m sure that just about every one has written a linked list, whether on their own or in school. And once you''ve written one you should never, EVER have to write one again (except for those C programmers who can''t use templates).

So my question is, once you''ve written one, WHY would you ever need to use STL''s?

As for the other classes (vector, string, etc) I feel the same way. I feel I should know how to write a vector or string class, and once I do I never have to use another version again.

Maybe it has to do with the fact that I program to learn, rather than for the end product...


- Houdini