Back to General and Gameplay Programming

Is it just me or do these programming techniques suck?

mattnewport · 2005-06-17T22:19:48

I'm working on a large multi platform (including consoles) C++ project which uses a number of programming techniques that I think are bad choices and in some cases which fly against all the advice I've seen given by books on good C++ style. Now I know some of the engineers who've developed this thing are not complete idiots so I'm wondering if I'm missing some compelling arguments for doing things the way they are done - perhaps some alternate schools of thought on what I thought were established best practices. In many cases I think I know the reasons the choices were made (usually performance related) and can sort of understand them but just don't think the benefits are worth the costs in terms of extra maintenance, extra development time and difficulty of debugging. Much of it seems to be one giant exercise in premature optimization. If anyone can offer good arguments in support of these techniques or point me at resources that argue for them I'd be interested to see if I'm missing something. 1.) Coding standard that requires no headers to include other headers. I've seen plenty of books that say any header should be able to compile on it's own as the only line in a .cpp file. This prevents situations where you must include headers in exactly the right order to get anything to compile. Obviously in general it's a good idea for headers not to include other headers unless they really have to but this is the first time I've seen it mandated that headers should not include headers even when they will not build without them. This causes numerous headaches: you have to get the include order exactly right in your .cpp file to use a header; you have to figure out all the implicit dependencies in a header file yourself in order to use it; you can't look at a header file and tell at a glance what it is physically dependent on; you can't know for certain what any given function call or type in a header will resolve to since it depends on what happens to be included before this header in any given .cpp file. This seems monumental idiocy to me. Am I missing something? 2.) Classes that are not. It is standard practice throughout the code base to have 'classes' whose size and members are not fixed and are only implicitly defined. The classes provide static functions for determining their real size based on their initialization parameters (the size can and often does vary from instance to instance) and provide a static initialization function. Creating an instance of the class involves allocating the amount of memory returned by the size function then calling initialize on this chunk of raw memory (making sure you use exactly the same parameters as you used to get the size). The class will typically have a few members declared and then will tack a whole bunch of arbitrary data on to it's own tail, the layout and size of which varies and is defined implicitly in the code that manipulates it. This approach saves the space required for an occasional pointer but at what a cost... You can no longer use standard C++ new and delete; you can't use sizeof(); you can't create arrays of the object; you have a maintenance nightmare (since the actual layout of the data is not defined explicitly anywhere, it is all implicit in the code that manipulates the data); you have no hope of automating serialization by analyzing the declaration of the class... I could go on. This seems to me like a crazy way to go about software engineering. Is it common practice in embedded systems or some other area that I'm maybe not familiar with? 3.) Funky auto-generated headers. Presumably partly in order to reduce the pain induced by 1.) there is a custom tool that takes in a big bunch of cpp files and include directories and spits out a concatenated header containing all the necessary headers in one big lump. It doesn't always work correctly. Even if it did this seems pointless - are there really still compilers that are so bad at handling include guards that this makes a difference to build times? Is it worth the pain? 4.) No run time memory allocation. I can understand the rationale of this for many systems but it's not really true in this case. What they really mean is that they don't perform it, not that it is not needed. Instead clients must query the static size function mentioned above for each class and allocate all the memory required themselves before passing it to the initialization function. It seems to me this doesn't buy you much over simply always using a client provided memory allocator for all internal allocations. That will do for now, there's other design decisions which make me want to tear my hair out but I've ranted enough for one afternoon. So can anyone offer any good justifications for any of these techniques? Are they more widely used than I realise? Or is this really as crazy as I think it is?

General and Gameplay Programming Programming

Started by mattnewport June 16, 2005 06:41 PM

36 comments, last by Hamster 18 years, 10 months ago

mattnewport

1,039

Author

June 17, 2005 01:18 PM

Quote:Original post by Teknofreek
The only one that holds some merit to me is not allocating any memory in the core code. You could use custom allocators, but that scheme has its own quirks. For example, what happens if you want to use different allocation strategies for large and small objects? What if you want to use different strategies for objects that are allocated once per game/level/etc versus objects that are constantly being created and destroyed during the game. And so on. The problem with simply providing alloc/free callbacks is that it might not allow for enough customization.

Another way to go about it would be to allow the users to customize the memory allocation via template policies. That can also get a bit icky, hard to debug, and it may confuse some less experienced programmers. Personally, I think I prefer this approach to simple callbacks though.

You're right, a simple callback approach would not be as flexible as the current system. To address those limitations my preference would be for some kind of template based allocator scheme as well, something like the STL allocators. I don't think it would be any more confusing for less experienced programmers than the current scheme. In fact, for less experienced C++ programmers it's probably much less confusing. C programmers might be more comfortable with the current system. A template based allocator scheme can be made easy in the simple case (for STL containers you don't even have to know the allocators exist if you're happy with the default behaviour) and just as flexible in the general case. It would require a bit more up front engineering and design effort but I think the payoff would be well worth it.

Quote:
However, I think the real reason that the no-allocation policy feels so icky in this case is because of #2. If the class size was consistent, it would be easy to write some wrappers to allocate arrays, and so on.

That definitely makes things worse. What really bothers me is that it throws out the window any possibility of the compiler helping you catch your mistakes. Subverting the type system like this makes it much harder to catch errors at compile time which is where they are easiest and cheapest to fix.

Quote:
Well, if you are working with the same stuff I'm working with...good luck! The tools that accompany the stuff I'm working with make the engine-side code look like gold!

Ha, we very well might be working on the same project if that's the case [smile]

Game Programming Blog: www.mattnewport.com/blog

mattnewport

1,039

Author

June 17, 2005 01:27 PM

Quote:Original post by Saruman
Quote:Original post by mattnewport
1.) Coding standard that requires no headers to include other headers.

David Eberly actually talks about this in his Game Engine Architecture book. One reference that he makes is when he worked for a company that had all the includes in the headers... and when he went through and changed it the build times went from ~30 minutes to ~3 minutes.

I haven't read that book, I've read 3D Game Engine Design but not the Architecture book. I'd be surprised if he really went through and removed all the includes from the headers and got a speed up. Removing all unnecessary includes from the headers would speed up the build but if you remove the necessary headers you've just got to move the same includes into the .cpp files so I don't see how you'd get a speed up. As I said before I think it's vitally important on a large C++ project to minimize your physical dependencies but not including headers in other headers does nothing to achieve that; you still have exactly the same physical dependencies it's just you have to manually specify them everywhere you include the header.

Game Programming Blog: www.mattnewport.com/blog

Dmytry

1,151

June 17, 2005 01:40 PM

1:That's weird. It's exactly replacing "good dependancy" (trackable by ANY automatic tool that looks for includes) with "bad dependancy" where you have no idea WTF header needs to work, and in what order. It merely hides dependancy, makes dependancy be more obscure.
Only removal of unnecessary includes could speed it up. compilers are good at handling #pragma once or even could deduce it from definitions.

2: Premature optimization?
I did it only once for really heavily used struct, when performance is critical without doubt (software renderer). But, doing that with classes? OMG.

3:
if there was any reason behind 1 (premature attempt at compile speed optimization?), it's destroyed by 3 .

4: if 2 is not scary yet, that makes 2 even more scary.
I don't like allocations either, but sometimes 'em are unavoidable, and to avoid, one just allocate big chunks which sucks.
I prefer to allocate everything that possible at initialization, and possibly do some allocations in render-prepare time.(work on software non-realtime renderers) but really, it wouldn't be possible to write what i'm working on now with such rules.

in summary, lot of people do completely idiotic things. Sometimes(hopefully rarely enough) even I do something stupid.

Raghar

June 17, 2005 01:54 PM

Quote:Original post by mattnewport
I've seen plenty of books that say any header should be able to compile on it's own as the only line in a .cpp file. This prevents situations where you must include headers in exactly the right order to get anything to compile.

But each .cpp file would compile on it's own. It will also remove nasty polution of a namespace. The best solution would be don't use .h files at all - use Java multiplatform, async memory allocation, inner classes, escape analysis, heavy inlining independend on compile time informations. The other alternative is to remove .h files from C++ standard, and change datatype definition in C++ standard to fixed predefined size. BTW most of large projects did that by macros. __int64 as long and __int32 as int

Quote:handling include guards that this makes a difference to build times? Is it worth the pain?

You are using include guard? Oups, I use Eclipse and dynamic recompilation in such stages of the project, if first global compile after multiple independend standalone compiles didn't work without problems. And when I use C++ I'd let compiler do its work without compiler guards. It could compile it on background in a separate directory and I, if neccessary, could look at the error output of the previous build. Does Eclipse have something like a fast C++ recompiler? It has several plugins one of them could do it considerably easier.

Quote:No run time memory allocation.

They are scared of memory allocaction? Some Java developers were scared by realocation of a small objects. They were sisies. If it isn't in tight loop... it's nearly harmless. In comparison to Bush talks... ~_^

What if you'd build your own memory manager? It might simplify and speed up things, and there are some fast memory managers for speedy DEALOCATION, like copying generational garbage collector.

Quote: you can't use sizeof(); you can't create arrays of the object; you have a maintenance nightmare (since the actual layout of the data is not defined explicitly anywhere, it is all implicit in the code that manipulates the data); you have no hope of automating serialization by analyzing the declaration of the class

sizeof() isn't neccesary reliable in every situation. Size of [FP] would be 80 bits, but size of [SSE2/4] would be 32 bits. It's the same datatype. Of course C++ doesn't alow so much low level, but no sizeof() is no loss, it's easy to work even without it. (Imagine how many times Java programmers wanted to know how many big is theirs class or datatype. Would you believe they finished theirs program without knowing such information, and it was working? Actually the answer was: It depends, on JIT optimalizations, amount of memory, and CPU architecture. For example refferences are 64 bits on 64 bit computers. And yes you can have in one program sizeOf(byte) both equal 1 and 4.)

Do you claim you can't do:
int32[] refferences = new int32[amountOfObjects];
class a = new someClass();
refferences[i++] = a;

I think it would work without problems. Just be careful with nulling.

Automatic serialization is automatic nightmare after you discover you could do it better, change serialization algorithms...

You know size and you could blit it to file, so these worries are too early... Just you wait at the end of the project. ^_^

Anonymous

June 17, 2005 02:19 PM

Quote:Original post by Raghar
Quote:Original post by mattnewport
I've seen plenty of books that say any header should be able to compile on it's own as the only line in a .cpp file. This prevents situations where you must include headers in exactly the right order to get anything to compile.

But each .cpp file would compile on it's own. It will also remove nasty polution of a namespace.

Not sure exactly what you're getting at there, could you elaborate?

Quote:The best solution would be don't use .h files at all - use Java multiplatform, async memory allocation, inner classes, escape analysis, heavy inlining independend on compile time informations. The other alternative is to remove .h files from C++ standard, and change datatype definition in C++ standard to fixed predefined size. BTW most of large projects did that by macros. __int64 as long and __int32 as int

Using Java is not an option on this project, several of the platforms we have to support have no Java runtime and even if they did Java's performance characteristics are not appropriate for this software. Also, all the clients for our library use C++. It would be great if C++ didn't need header files and had a compilation model more like Java or C# but it doesn't so we have to make the best of what's available. C99 defines fixed size integer and floating point types, we plan to adopt those types for this project.

Quote:
Quote:handling include guards that this makes a difference to build times? Is it worth the pain?

You are using include guard? Oups, I use Eclipse and dynamic recompilation in such stages of the project, if first global compile after multiple independend standalone compiles didn't work without problems. And when I use C++ I'd let compiler do its work without compiler guards. It could compile it on background in a separate directory and I, if neccessary, could look at the error output of the previous build. Does Eclipse have something like a fast C++ recompiler? It has several plugins one of them could do it considerably easier.

We're not using Eclipse, I'm not really familiar with it. I'm not sure you understand what you're getting at with the include guards - I don't know of any C++ compiler that doesn't require either include guards or a proprietary equivalent (like #pragma once) for correct operation. If you want to stick to standard C++ and get correct behaviour you have to use include guards and you have to hope that your compiler is smart enough to only open the files once (most are these days).

Quote:
Quote:No run time memory allocation.

They are scared of memory allocaction? Some Java developers were scared by realocation of a small objects. They were sisies. If it isn't in tight loop... it's nearly harmless. In comparison to Bush talks... ~_^

What if you'd build your own memory manager? It might simplify and speed up things, and there are some fast memory managers for speedy DEALOCATION, like copying generational garbage collector.

On many of the platforms we work with and with the near realtime constraints we have to operate under there are good reasons to worry about run time memory allocation. It's not just the speed of the allocation we have to worry about but the fact that there is a hard limit on the total memory available, possible concerns about fragmentation due to not all platforms supporting virtual addressing, etc. Generally the clients of our libraries expect to be able to control all the memory allocations our library uses so writing our own memory manager isn't really an option.

Quote:
Quote: you can't use sizeof(); you can't create arrays of the object; you have a maintenance nightmare (since the actual layout of the data is not defined explicitly anywhere, it is all implicit in the code that manipulates the data); you have no hope of automating serialization by analyzing the declaration of the class

sizeof() isn't neccesary reliable in every situation. Size of [FP] would be 80 bits, but size of [SSE2/4] would be 32 bits. It's the same datatype. Of course C++ doesn't alow so much low level, but no sizeof() is no loss, it's easy to work even without it. (Imagine how many times Java programmers wanted to know how many big is theirs class or datatype. Would you believe they finished theirs program without knowing such information, and it was working? Actually the answer was: It depends, on JIT optimalizations, amount of memory, and CPU architecture. For example refferences are 64 bits on 64 bit computers. And yes you can have in one program sizeOf(byte) both equal 1 and 4.)

sizeof(float) can vary across platforms but on any given platform it's always fixed for any specific bit of code. Anyway, the real problem with this system is not so much that the user doesn't know the size of the class but that the compiler doesn't know the size of the class. That means you can't declare arrays of the type, use pointer arithmetic, use new or delete on the object, etc.

Quote:
Do you claim you can't do:
int32[] refferences = new int32[amountOfObjects];
class a = new someClass();
refferences[i++] = a;

I think it would work without problems. Just be careful with nulling.

That looks like Java to me so no, we can't do that.

mattnewport

1,039

Author

June 17, 2005 02:20 PM

Oops, that AP was me.

Game Programming Blog: www.mattnewport.com/blog

Anonymous

June 17, 2005 02:35 PM

Quote:Original post by Dmytry

I don't like allocations either, but sometimes 'em are unavoidable, and to avoid, one just allocate big chunks which sucks.
I prefer to allocate everything that possible at initialization, and possibly do some allocations in render-prepare time.(work on software non-realtime renderers) but really, it wouldn't be possible to write what i'm working on now with such rules.

This may sound stupid, but what exactly defines a run-time allocation? How does this differ from other types of allocation?

Anonymous

June 17, 2005 02:51 PM

(2) sounds like a flexible array member in C99. It was non-standard, but often-used technique in C (Used often enough that the committee finally gave the technique its blessing). The C99 version goes something like:

struct SomeStruct {
int somevar;
// ...
char anotherVar;
int data[];
};

sizeof returns the size of the struct less the last element (although it will include any padding between anotherVar and data).

Dmytry

1,151

June 17, 2005 02:58 PM

Quote:Original post by Anonymous Poster
Quote:Original post by Dmytry

I don't like allocations either, but sometimes 'em are unavoidable, and to avoid, one just allocate big chunks which sucks.
I prefer to allocate everything that possible at initialization, and possibly do some allocations in render-prepare time.(work on software non-realtime renderers) but really, it wouldn't be possible to write what i'm working on now with such rules.

This may sound stupid, but what exactly defines a run-time allocation? How does this differ from other types of allocation?

It may mean literally anything, as any allocation is "runtime". What is usually meant, allocations and deallocations during most of program run time. Like allocating string for user input when he enters this input. I wouldn't want allocations to happen in pixel loop of raytracer, for example; but allocations prior to rendering are okay. Number of allocations and deallocations should be keept minimal.

edit: indeed, also there could be memory fragmentation issues. But you still can use good garbage collection in such case.

[Edited by - Dmytry on June 17, 2005 4:58:05 PM]

flangazor

516

June 17, 2005 04:07 PM

I've worked on an embedded system that in some cases was to run for weeks at a time (preferably indefinitely). Using new and delete in this system resulted in memory fragmentation over time and so the system would slow down considerably after a few days. It's really hard to sort out, so I think 4 is a good policy for some systems.

FWIW, Fortran77 doesn't have dynamic allocation.

Is it just me or do these programming techniques suck?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Is it just me or do these programming techniques suck?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines