Date: Tue, 08 Jul 2003 03:06:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "David A. Gobeille" <dgobeille@earthlink.net> Cc: Alin-Adrian Anton <aanton@reversedhell.net> Subject: Re: raw socket programming SOLVED Message-ID: <3F0A97A8.464123FF@mindspring.com> References: <0193271C683D5844A478A359271B8F66147AD8@DC1.dynatec.com> <3F07860E.9060702@reversedhell.net> <20030707162900.B49607@beagle.fokus.fraunhofer.de> <3F078DC9.3080708@reversedhell.net> <20030707164832.L49607@beagle.fokus.fraunhofer.de> <3F0790EF.10407@reversedhell.net> <3F098D11.2070802@earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"David A. Gobeille" wrote: > Shouldn't the #included files themselves #include headers they are > dependant on? With the use of #ifndef and #define in the headers to > keep them from being #included more than once? > > It seems silly(more work) for the programmer to have to arrange > everything in a specific order. The order is documented. Maybe we could have one big header file that declares everything in the right order so that no one has to think at all? 8-) 8-). In general, FreeBSD headers are independent. Unless you have compiler support for precompiled header files, there is a significant reduction in compile time for not having promiscuous headers (headers which include other headers). There are also issues having to do with whether or not certain functions or manifest constants end up in the namespace, and conflict with user header definitions. By including only a minimal set of the headers needed to compile the program, you reduce the possibility of such conflicts occurring. As another point: the craftsman should know his tools; in other words, you should be aware of which headers are necessary, because you know what you are doing (or are able to figure it out, and remember it for the next time you need the information). Finally, POSIX compliance -- strict compliance -- requires that certain headers *not* define values into the implementation space. This is particularly problematic when it comes to inline functions wrapped by macros (for example) or compiler built-ins (for another example) when you want to get a specific implementation, or when the compiler built-in is the only way to do something correctly, as in the recent issues FreeBSD had with alloca() and stack alignment with certain "cputype" values. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F0A97A8.464123FF>