Templates - efficiency and implementation - General and Gameplay Programming

Ben Sizer · 2001-01-05T08:05:31

Ok, I am getting more and more disillusioned with templates the more I use them. Yes, things like the Standard Template Library give me a lot of efficiency in terms of how quickly I can implement things? But at what cost? Firstly, compile times. A simple C/C++ file with just ''C'' features, maybe the odd inherited class or two, compiles very swiftly. Throw a templatized list in there, or a map, and it starts taking 2 to 5 times longer. The amount of include files is probably a major culprit too: if I wish to use a STL list, including the "list" header in turn includes the "cstddef", "functional", "iterator", "memory", "stdexcept", and "xutility" headers, which in turn includes "stddef.h", "xstddef", "utility", "xmemory", "exception", and "xstring"... etc. A lot of these included files are just template functions that are there just in case I use them, which a lot of the time, I won''t. Secondly, executable/object file size. If I use an STL list, for example, it has to create a new instantiation of the code for every different type that uses it. Even if they are completely equivalent, eg. int* and char* behave exactly the same way in terms of storing them in a container class. You are just manipulating blocks of 4 bytes, essentially. Technically, certain parts of a template class can be shared (eg, where the functionality doesn''t depend on the type) which could reduce the amount of duplicated instantiation that goes on... ... but this is surely made irrelevant by the fact that the STL template code is all inlined in the classes, so it is almost certainly all just expanded inline in your code. Every single push_back() and pop_front() and remove() is getting expanded inline, for every use of the function, no matter whether it''s the same type and could therefore share the implementation. In every single file that uses it. A program with only 12 lines of code in a single function (main), that includes the "map", "string", and "iostream" headers is 120kb in release build. Expanding to almost 10k per line of my high-level-language. Doesn''t that seem a bit much? And if I wanted very similar functionality in a different source file, all the identical code appears to get re-inserted there too. If the code gets too bloated, then the benefits of inlined code start to get outweighed by the problems of having too much code for the cache to hold at once. Maybe it would be worthwhile just making an "stl.h", including every single STL header, and precompiling it? Is there some other way I can wrap these classes or otherwise use them that will let me use their functionality as function calls rather than inline expansions everywhere throughout my code, duplicating functionality a billion times? And, perhaps more importantly to me, cut my 35 minute rebuild times to a more manageable 10 minutes or so? I welcome opinions from those who are more knowledgable in compiler implementation and efficient template usage than myself, as I expect I have got some of my facts wrong... but who knows.

JD

208

January 04, 2001 02:15 PM

Here''s the id of the article describing msvc++ deficiencies: Q243451. It doesn''t support template member functions correctly. That is you must have the function definition inside the class definition for it to work. I''ve also read that you can precompile the .cpp files in msvc++ 6.

Forged3D world editor

Wilka

122

January 04, 2001 02:17 PM

quote:

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

Because it works with std::find_if, std::upper_bound, std::copy and any STL compatible algorithm you or anyone else writes ever again. The STL collections also have a consistent interface, so you can switch between by a few charters (assuming you''re using typedefs or, ugh, #define). So if you start with a list, but it''s push_back is to slow you can switch to vector or deque and the rest of code just works.

Even it you do write you''re own container, it would be a good idea to give an STL style interface.

Also lost of people make versions of STL, and they''re all working to make their own version the best. So each new version of STLport you get improvements to your own code for free e.g. the new geet fast allocators (courtesy of SGI). Most people I know wouldn''t bother trying to improve their own linked if it was already as good as they need. But that doesn''t mean it can''t be better.

quote:

Turns out that Windows CE doesn''t support the STL.

Windows CE can''t support STL, that''s the job of the compiler. But what do you mean by "doesn''t support"? If you mean it doesn''t come with a version of STL, why not just copy the files from the compiler that does to the one that doesn''t. Or does the compiler not support templates?

quote:

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

That makes perfect sense, but once you have made a linked list class and you understand the way they work you''ll be able to write them in your sleep. So why not just leave that one alone and use the one that gives you most flexibility?

If you need something that STL doesn''t offer then it''s great to write your own, but when it does have what you need I don''t see a point in writing your own unless it''s to understand how they work.

Dire.Wolf

122

January 04, 2001 02:56 PM

Cool, it looks like we are all in agreement

Dire Wolf
direwolf@digitalfiends.com

[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com

Houdini

266

January 04, 2001 03:18 PM

quote:
Original post by Wilka
Because it works with std::find_if, std::upper_bound, std::copy and any STL compatible algorithm you or anyone else writes ever again. The STL collections also have a consistent interface, so you can switch between by a few charters (assuming you''re using typedefs or, ugh, #define). So if you start with a list, but it''s push_back is to slow you can switch to vector or deque and the rest of code just works.

A very good point, and it''s something I''ve thought about myself. For the simple game I''m writing now I''m going to stick with the version I got, but for my next project I''m going to redesign the container classes the RIGHT way, using the same basic idea that STL uses.

Too many people who use C++ don''t use OOP very well. STL uses a very good implementation and I''m sure I''ll learn a lot by following it. And once I''m done it''ll be much easier to design other code the same way since I''ve had the practice.

quote:
Original post by Wilka
Even it you do write you''re own container, it would be a good idea to give an STL style interface.

Agreed, my version is very close, although it isn''t an exact copy. Damn those all small case function names messing with my coding standard

quote:
Original post by Wilka
Also lost of people make versions of STL, and they''re all working to make their own version the best. So each new version of STLport you get improvements to your own code for free e.g. the new geet fast allocators (courtesy of SGI). Most people I know wouldn''t bother trying to improve their own linked if it was already as good as they need. But that doesn''t mean it can''t be better.

True, but with each new version of STLport''s or VC++''s STL you have the chance of introducing new bugs into your code. Heck, that''s one of the reasons people recommend STLport, because of the bugs that other versions of STL contain.

Also, if you had a production app ready, would you compile it with a new version of STL without doing a full regression test on the program? I wouldn''t. If you have code that''s fast and works, you shouldn''t use new versions of it unless you need to (ie bug fixes) or have the time to do a full retesting of the product. That just isn''t worth the effort unless the new version contains something you want/need.

Which of course works both ways. If I need extra functionality in my vector class, you either wait for a new version of STL or add to your own. Same thing with speed. For instance, I just went through and did a little tweaking of my own vector class and it''s 50% faster than STL''s in debug and 20% faster in release. Now I''m not saying that I can write better/faster code than what''s in the STL. If I''m not mistaken STL uses exception handling which I don''t use in my program. That''s a speed increase. It may also have some extra error checking/functionality that I may not need either.

quote:
Original post by Wilka
Windows CE can''t support STL, that''s the job of the compiler. But what do you mean by "doesn''t support"? If you mean it doesn''t come with a version of STL, why not just copy the files from the compiler that does to the one that doesn''t. Or does the compiler not support templates?

The compiler supports templates, but it comes with no version of STL. When I tried to copy VC++''s version and use that I got a ton of compile errors. I checked the MSDN and it specifically states that the Windows CE developement toolkit doesn''t support STL. And unfortunately I don''t know of any other compilers for Windows CE other than Microsofts

quote:
Original post by Wilka
That makes perfect sense, but once you have made a linked list class and you understand the way they work you''ll be able to write them in your sleep. So why not just leave that one alone and use the one that gives you most flexibility?

If you need something that STL doesn''t offer then it''s great to write your own, but when it does have what you need I don''t see a point in writing your own unless it''s to understand how they work.

Another good point, and I don''t see any big reason not to use STL''s at that point. Of course, knowing that you are using your own source code is a nice piece of mind in case you DO need something the STL doesn''t offer later. That of course comes at the cost of not getting free upgrades.

- Houdini

- Houdini

Wilka

122

January 04, 2001 03:48 PM

quote:

I checked the MSDN and it specifically states that the Windows CE developement toolkit doesn''t support STL. And unfortunately I don''t know of any other compilers for Windows CE other than Microsofts

Dam MS, they just want everyone to be happy with CArray

quote:

Also, if you had a production app ready, would you compile it with a new version of STL without doing a full regression test on the program? I wouldn''t. If you have code that''s fast and works, you shouldn''t use new versions of it unless you need to (ie bug fixes) or have the time to do a full retesting of the product. That just isn''t worth the effort unless the new version contains something you want/need.

Completely correct, changing any of the libraries that you''ve been using when you don''t have time do it properly is just silly - unless there are some things you need in the version (e.g. bug fixes), if there is you''ll have to try and make time

Kylotan

Author

10,513

January 04, 2001 04:48 PM

quote:
Original post by Houdini

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

I have no idea how long it would take without templates, for obvious reasons. But it does seem to be too long. My project contains 49113 lines of code, including a few blank lines, and about 170 files, for comparison purposes.

quote:

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

Anyone have any good links on using other compilers with the Visual Studio environment?

quote:

(me)
More like 600kb difference, in my experience.
(end me)

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.

Yeah. But, it -shouldn''t- be that big. Bigger programs are slower programs and take longer to download... and I know that I personally am getting annoyed at ''small'' programs getting bigger and bigger. (Anyone seen the latest ICQ download?) It''s not a trend I''d like to see continue. I am interested in finding out if I can fix that, rather than just disregarding it, as I''m sure it should be feasible to obtain reusability and maintainability without paying that price.

Wilka

122

January 04, 2001 05:01 PM

quote:

Anyone have any good links on using other compilers with the Visual Studio environment?

You could try Intel.

Kylotan

Author

10,513

January 04, 2001 05:02 PM

Wilka, here''s an example of the STL bug/issue I was talking about:

compiled in MSVC5.0:

  #include <list>using namespace std;class Myclass;typedef list<Myclass*> myclassList;int main(){	myclassList xlist;	xlist.push_back(NULL);	xlist.push_back(NULL);	xlist.remove(NULL);	return 0;}

And it gives this:

C:\Program Files\DevStudio\VC\INCLUDE\xmemory(33) : error C2027: use of undefined type ''Myclass''

Which is this line:

  // TEMPLATE FUNCTION _Destroytemplate<class _Xyzzy> inlinevoid _Destroy(_Xyzzy _FARQ *_P){_DESTRUCTOR(_Xyzzy, _P); }  // <------------ dis one

Seems to work fine in Borland C++ Builder 4, though. *sigh*

Kylotan

Author

10,513

January 04, 2001 05:06 PM

Let me add the word free to the ''other compilers'' concept

I am but a penniless student.

Wilka

122

January 04, 2001 06:38 PM

MSVC6 gives:

fd34.exe - 0 error(s), 0 warning(s)

Not that it helps your problem though

Borland 5.5 also handles it fine, you can download it for free here , but it doesn''t integrate with VC''s IDE. You should be able to set it up with some custom build steps, but that depends how determined you are

Although if you have Borland C++ Builder 4 you might be able to just drop this compiler in cos it should have all the same options. But I guess you want to stick with the VC IDE. If it wasn''t for it''s IDE, I probably would have stopped using it ages ago

Templates - efficiency and implementation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Templates - efficiency and implementation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines