[Gllug] c++ newbie complier probs

[Nix]

On Wed, 23 Oct 2002, Sean Burlington said:
> Jonathan Harker wrote:
> 
>> #including .cpp files is generally a very bad move. If the ccc stuff is
>> written in a half decent style, you should only need to include the .h file.
> 
>> Generally, you include .h files (which are usually interfaces) and the
>> implementation is tucked away in .cpp files; Your compiler/linker will
>> magically link the corresponding .o (or if there isn't one, compile a fresh
> 
>> one from the .cpp).
> 
> hmm.. the book I am following seems to have bad style
> #include "ccc_empl.cpp"

This used to be common in the days when templates were new and the
idioms for using them were still shaking down. These days, one puts the
entire template in the header and #includes that.

(Of course a proper compiler supports separate compilation of templates
and the `export' keyword. Unfortunately I've never seen a C++ compiler
that supports this, and I'm not even sure if one exists; I hear KAI C++
supported it before Intel borged KAI, but I'm not sure of that.)

>> -I tells the compiler where to look for your .h files
>> -L tells the linker where to look for your .o files
> 
> 
> using -l doesn't hurt -- but I seem to be able ti complie with just specifying the include path (is that supposed to work?)

-l and -L do very different things (by convention, on all Unix systems).

-lfoo looks for lib{foo}.so and lib{foo}.a, in that order, in a
system-specified set of directories. (On old Unix boxes, the .so wasn't
searched; on Linux and *BSD boxes, which use the GNU linker, the order
and nature of the search is configurable by editing a linker script,
although doing so systemwide is a rather bad idea...)

-L adds to the library path which is searched by -l. It does not change
where .o files are searched for; those are always looked for by name
exactly where you specify, just like .c files.

>> #include
>> #include
>> #include "ccc_empl.h"
>>
>> using namespace std;
> 
> unfortunately that doesn't work !
> 
> ccc_empl.h doesn't specify any namespace - and only seems to work if I
> pollute it by specifying namespace std before including it (its a
> slightly old edition - but I have been told in lectures to do it this
> way !)

Your lecturers need re-education. *whip* *crack*

Fixing the .h file to use namespaces is the Right Yay to do it;
namespaces aren't very new anymore, and any decent C++ compiler should
support them. (It's not as though they're terribly hard to implement,
unlike `export', which is a *swine*.

Well, OK, perhaps they're not that easy; getting dependent type lookup
in the presence of templates and Koenig lookup right is fiddly to say
the least, and G++ still doesn't quite get it right; but the lion's
share of stuff works now. All hail CodeSourcery's new C++ parser, fast
may it grow and fix All Known Bugs(TM)... naturally it will introduce
new ones but they'll be smaller. Or else. ;) )

You can always point out to your lecturers that the variant of the
headers that reference names without either using namespace std or
qualifying names with std:: isn't referencing the identifiers it thinks
it is, and quite possibly is not valid C++ at all.

(Of course, they *may* know that...)

>> // #include  -- won't work
>> // #include  -- still won't work
>> // #include  -- catastrophically bad idea! :-)

oo-er.

> ooh - mozillas gone all wierd and hidden the quoted include filenames from me - I wonder if it will still post OK?

Bleah. Bloody broken jumped-up web browser that it is. ;}

> and it's always helpfull to know when you are being taught dodgy stuff !

All too often in C++ courses :(

> looking ahead in the book - it does include header files -but at a much later stage

claiming one pedant point:

#include <iostream>, #include <algorithm>, #include <cstdio> and other
inclusions of Standard-mandated names do not necessarily pull in any
files from anywhere; they can trigger magic inside the compiler that
brings the appropriate names into scope.

(The same is true in C, and I've seen C compilers for shall we say
`unusual, hardware-deprived' boxes that don't use header files.

 OK, it was a BBC Master with a C compiler in ROM. ;} )

> I have to say I was expecting an MSc to be more advanced than this -
> 
> even though it is a conversion sourse ..
> we have mostly been covering basic stuff like loops and conditionals
> so the C++ specific stuff is kind of glossed over (and at the

*sob*

You shouldn't have to teach anyone on a master's course what a loop is,
surely?

> same time we are studying the IEEE standard for storing floating point
> numbers in registers - which seems to me a massive mismatch in detail
> level)

Um. You're studying the details of IEEE754 and *loops* at the same time?!

Bloody 'ell.

> bizarely #include <ccc_empl.cpp> seems to work

It will, as long as you're using -I. to point to the right directory.

> but I'll stick to #include "ccc_empl.cpp"

Good move.

FWIW, "foo" will always search at least as many places as <foo> on any
platform: the Standard says

,----
| 3 A preprocessing directive of the form
|           # include "q-char-sequence" new-line
|   causes the replacement of that directive by the entire contents of the
|   source file identified by the specified sequence between the " delim-
|   iters.  The named  source file is searched for in an implementation-
|   defined manner.  If this search is not supported, or if the search
|   fails, the directive is reprocessed as if it read
|           # include <h-char-sequence> new-line
|   with the identical contained sequence (including > characters, if any)
|   from the original directive.
`----

With GCC, the rules are quite complex, involving two interacting include
paths (see the manual), but basically you can rely on <foo> and "foo"
always searching any paths you've mentioned with -I; "foo" will also
search the current directory (or the directory the include file is in if
it's not in the current directory). <foo> will always search
/usr/local/include, /usr/include[1] and other system include paths if
any (which there probably aren't).


[1] well, almost sort of roughly you can pretend that that's what it's
    searching even though it's actually searching somewhere quite
    different down in the GCC tool directory under /usr/lib/gcc-lib/ ;}

-- 
`The tooth fairy teaches children that they can sell body parts for money.'
                       --- David Richerby

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug