bagchi@dip.eecs.umich.edu (Ranjan Bagchi) (12/29/89)
A C++ project that I'm working on involves a class with a static member. Perfectly acceptable C++ code...two different .cp files #include the .h which defines this class. Everything compiles fine. What bothers me is when I blink everything together into executable code, blink complains about multiply defined code. I have isolated it to the presence of the static class members. When I transfered the code to *NIX and g++'ed everything together, there was not a burble. What I'm asking is if there's any way to tell blink to "chill", and that the static members are supposed to be there. The object files do link, incidently...eveyrthing runs as expected. Warnings of any kind bug me, though. -rj bagchi@sparky.eecs.umich.edu
rosenber@ra.abo.fi (Robin Rosenberg INF) (12/31/89)
I don't have the manuals here, but i think I can recall something about using an option to the compiler to avoid this problem. Check the options for CC and I'll think you'll find the answer. ----- Robin Rosenberg
ghewes@bbn.com (Gerald Hewes) (01/11/90)
I may be late in the discussion, but the problem with statics between UN*X and AMIGA arises from the fact that blink does not allow multiple declarations of external symbols. When you include header files with such definition you run into trouble. To avoid this, CC and lc both have flags to turn any declaration into a harmless external definition. UN*X on the other hand allows multiple declarations. It will allocate memory to fit the largest declaration. Of course no type checking is done. This means that the two following files will link fine with no warning whatsoever: file1.c char container; file2.c double container[100]; The linker will allocate enough room for the 100 double's. As to which linker philosophy (the Un*x version hides a lot of bugs and conflicts) is better is a subjective answer.