Reply to thread

Message: [QUOTE="jaysome, post: 2874035"] [i] In addition to the correction noted by Keith ("extrn" should be "extern"), it should be noted that defining an actual object in a .h file does not necessarily mean that it will be multiply defined and result in a link or run time error. If the header file is included by a single translation unit, there will be no link or run time errors. You only run into trouble when multiple translation units include said header file and *think* they are accessing the same data (something I have witnessed in practice). Why would you ever want to define an actual object in a .h file? I can think of only one instance, which is if the .h file is shared between two or more programs (and included by a single translation unit in each, of course). I've used this technique, but only sparingly. Think of gcc and gcov using the same objects with file scope internal linkage, as an example (I'm not saying they do this, just that it is an acceptable option, IMHO, especially if there are a lot of the same objects used in both). (My actual usage of the above is almost the same code running as programs/processes on two dissimilar processors, which was one of the requirements necessary to achieve a certain level of system safety assurance). NEVER define an actual object in a .h file, unless you really know what you're doing. Saying a ".h file is NOT a place for headers" is like saying a "house is not a place for a home". I think you meant "objects" instead of "headers". Best regards[/i] [/QUOTE]

Verification