Function header files

On Feb 15, 7:04*pm, alanxx <alanxxi...@gmail.com> wrote:
> Hi,
>
> I am a student of C/C++. One of the mistakes I often make is forgetting to include the appropriate header files for the standard functions I use. Isthere an easy way (a website?) to find out where a certain standard function is prototyped in? I can find answers via google search or MSDN library, but it's more time consuming than I'd prefer. Ideally, I would prefer to just go to a website, type in the name of the function in a search box and find out what header file I should include and how it is defined. Thanks for your help!
>
> alanxx

The cplusplus.com website might be what you're looking for. If you
type in a function name in the search box, you get a web page of the
function plus its header on the navigation bar to the left.

Hope it helps.
John D.

Le 16/02/11 13:00, Ralph Spitzner a écrit :
> jacob navia wrote:
>> #include <conio.h>
>
> "conio.h is a C header file used in old MS-DOS compilers to create text
> user interfaces. It is not described in The C Programming Language book,
> and it is not part of the C standard library, ISO C nor is it required
> by POSIX."
>
> Sorry don't take seriously, just couldn't resist :-)
>
>
> -rasp
>
>

conio.h describes the interface for old Dos functions in lcc-win that
allows you to use the old Borland "gotoxy()" text mode packages and
have text mode with colors and simple "graphics" using special
characters.

If you do not like it you just erase that line. The concept is clear.

jacob navia wrote:
> Le 16/02/11 13:00, Ralph Spitzner a écrit :
>>
>> Sorry don't take seriously, just couldn't resist :-)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> If you do not like it you just erase that line. The concept is clear.
>


Not flaming you here. I just thought of it as being 'funny' finding such
a dinosaur, looking at all the C99 etc. discussion going on here.

-rasp

On Feb 16, 9:47*am, jacob navia <ja...@spamsink.net> wrote:
> Le 16/02/11 13:00, Ralph Spitzner a écrit :
>
> > jacob navia wrote:
> >> #include <conio.h>
>
> > "conio.h is a C header file used in old MS-DOS compilers to create text
> > user interfaces. It is not described in The C Programming Language book,
> > and it is not part of the C standard library, ISO C nor is it required
> > by POSIX."
>
> > Sorry don't take seriously, just couldn't resist :-)
>
> > -rasp
>
> conio.h describes the interface for old Dos functions in lcc-win that
> allows you to use the old Borland "gotoxy()" text mode packages and
> have text mode with colors and simple "graphics" using special
> characters.
>
> If you do not like it you just erase that line. The concept is clear.

Along the lines you're talking about it's not uncommon to write a
"project.h" file which includes the relevant header files for the
project. I wouldn't just blindly include all of the headers from /usr/
include mostly because they're not all compatible but also it DOES add
to compile times (hint: think of builds over NFS).

Tom

jacob navia <jacob@spamsink.net> writes:
> Le 16/02/11 13:00, Ralph Spitzner a ecrit :
>> jacob navia wrote:
>>> #include <conio.h>
>> "conio.h is a C header file used in old MS-DOS compilers to create text
>> user interfaces. It is not described in The C Programming Language book,
>> and it is not part of the C standard library, ISO C nor is it required
>> by POSIX."
>>
>> Sorry don't take seriously, just couldn't resist :-)
>
> conio.h describes the interface for old Dos functions in lcc-win that
> allows you to use the old Borland "gotoxy()" text mode packages and
> have text mode with colors and simple "graphics" using special
> characters.
>
> If you do not like it you just erase that line. The concept is clear.

Fair enough. I suppose there's a similar story for <process.h>.

But why is <malloc.h> in the list? Does it give you something that
<stdlib.h> doesn't?

If you're going to use that approach, perhaps it would be better to have
"stdheader.h" include just the standard headers; if you're using
features from <conio.h> it might be better to emphasize that by
including it directly in your source file.

(Personally I've never done that kind of thing, and it *feels* like
poor style, but I'm not sure I can articulate why.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Feb 16, 11:00*am, Keith Thompson <ks...@mib.org> wrote:
> (Personally I've never done that kind of thing, and it *feels* like
> poor style, but I'm not sure I can articulate why.)

I'm not sure it is bad "style", but it can certainly cause performance
issues in a large scale build to access/read/parse all the unneeded
header files, particularly if they aren't on a local filesystem.
Certainly, including unneeded headers that might change (standard
headers
don't much in practice) introduces unneeded dependencies into the
build process.
It is vexing if someone touches a file that shouldn't trigger a
global
rebuild of targets but does.

To OP, I'd personally just learn which standard functions go with
which headers.
May take a while, but the C standard library isn't THAT huge...

-David

ImpalerCore <jadill33@gmail.com> writes:

> On Feb 15, 7:04Â*pm, alanxx <alanxxi...@gmail.com> wrote:
>> Hi,
>>
>> I am a student of C/C++. One of the mistakes I often make is
>> forgetting to include the appropriate header files for the standard
>> functions I use. Is there an easy way (a website?) to find out where
>> a certain standard function is prototyped in? I can find answers via
>> google search or MSDN library, but it's more time consuming than I'd
>> prefer. Ideally, I would prefer to just go to a website, type in the
>> name of the function in a search box and find out what header file I
>> should include and how it is defined. Thanks for your help!
>>
>> alanxx
>
> The cplusplus.com website might be what you're looking for. If you
> type in a function name in the search box, you get a web page of the
> function plus its header on the navigation bar to the left.

I'd advise against using this site unless you are working in C++.
It works for common C functions but fails for a lot of newer C99
functions.

--
Ben.

David Resnick <lndresnick@gmail.com> writes:
> On Feb 16, 11:00Â*am, Keith Thompson <ks...@mib.org> wrote:
>> (Personally I've never done that kind of thing, and it *feels* like
>> poor style, but I'm not sure I can articulate why.)
>
> I'm not sure it is bad "style", but it can certainly cause performance
> issues in a large scale build to access/read/parse all the unneeded
> header files, particularly if they aren't on a local filesystem.
> Certainly, including unneeded headers that might change (standard
> headers don't much in practice) introduces unneeded dependencies into
> the build process. It is vexing if someone touches a file that
> shouldn't trigger a global rebuild of targets but does.

For the truly standard headers (those defined by the language
standard), updates shouldn't be much of an issue -- and if the
standard headers provided by the implementation are updated, you
probably *should* recompile everything.

I suppose there's a corner case where you have a "stdheader.h",
and the implementation is updated piecemeal, so an update that
affects only <math.h> causes an unnecessary rebuild. I don't know
how often that would occur in practice.

> To OP, I'd personally just learn which standard functions go with
> which headers. May take a while, but the C standard library isn't
> THAT huge...

I tend to agree.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Feb 16, 11:14*am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> ImpalerCore <jadil...@gmail.com> writes:
> > On Feb 15, 7:04*pm, alanxx <alanxxi...@gmail.com> wrote:
> >> Hi,
>
> >> I am a student of C/C++. One of the mistakes I often make is
> >> forgetting to include the appropriate header files for the standard
> >> functions I use. Is there an easy way (a website?) to find out where
> >> a certain standard function is prototyped in? I can find answers via
> >> google search or MSDN library, but it's more time consuming than I'd
> >> prefer. Ideally, I would prefer to just go to a website, type in the
> >> name of the function in a search box and find out what header file I
> >> should include and how it is defined. Thanks for your help!
>
> >> alanxx
>
> > The cplusplus.com website might be what you're looking for. *If you
> > type in a function name in the search box, you get a web page of the
> > function plus its header on the navigation bar to the left.
>
> I'd advise against using this site unless you are working in C++.
> It works for common C functions but fails for a lot of newer C99
> functions.

On Feb 15, 7:04 pm, alanxx <alanxxi...@gmail.com> wrote:
> Hi,
> I am a student of C/C++.

I think it does pretty decent for the core standard library, but I
agree that its C99 documentation is practically non-existent.

I refer people to this website as a supplemental resource who are
learning C. The books I have don't reference in detail most of the
C99 stuff (I don't own any new C teaching books that talk about C99
though they are probably out there). If you advise against the site,
do you have an alternative that's better?

Best regards,
John D.

On 02/17/11 05:07 AM, David Resnick wrote:
> On Feb 16, 11:00 am, Keith Thompson<ks...@mib.org> wrote:
>> (Personally I've never done that kind of thing, and it *feels* like
>> poor style, but I'm not sure I can articulate why.)
>
> I'm not sure it is bad "style", but it can certainly cause performance
> issues in a large scale build to access/read/parse all the unneeded
> header files, particularly if they aren't on a local filesystem.

The opposite may also be true; if your compiler supports pre-compiled
headers, it can speed things up. Unless you have an awful lot of
headers and not a lot of RAM, the OS will probably have cached them all
on first read, so remote files doesn't usually have too big an impact.

> To OP, I'd personally just learn which standard functions go with
> which headers.
> May take a while, but the C standard library isn't THAT huge...

Agreed.

--
Ian Collins

ImpalerCore <jadill33@gmail.com> writes:

> On Feb 16, 11:14Â*am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> ImpalerCore <jadil...@gmail.com> writes:
>> > On Feb 15, 7:04Â*pm, alanxx <alanxxi...@gmail.com> wrote:
>> >> Hi,
>>
>> >> I am a student of C/C++. One of the mistakes I often make is
>> >> forgetting to include the appropriate header files for the standard
>> >> functions I use. Is there an easy way (a website?) to find out where
>> >> a certain standard function is prototyped in? I can find answers via
>> >> google search or MSDN library, but it's more time consuming than I'd
>> >> prefer. Ideally, I would prefer to just go to a website, type in the
>> >> name of the function in a search box and find out what header file I
>> >> should include and how it is defined. Thanks for your help!
>>
>> >> alanxx
>>
>> > The cplusplus.com website might be what you're looking for. Â*If you
>> > type in a function name in the search box, you get a web page of the
>> > function plus its header on the navigation bar to the left.
>>
>> I'd advise against using this site unless you are working in C++.
>> It works for common C functions but fails for a lot of newer C99
>> functions.
<snip>
>
> I think it does pretty decent for the core standard library, but I
> agree that its C99 documentation is practically non-existent.
>
> I refer people to this website as a supplemental resource who are
> learning C. The books I have don't reference in detail most of the
> C99 stuff (I don't own any new C teaching books that talk about C99
> though they are probably out there). If you advise against the site,
> do you have an alternative that's better?

I'd advise using local documentation -- from an IDE or manual pages.
Since there are lots of manual page websites, I suppose I am indirectly
recommending them. For example:

http://www.linuxmanpages.com/

Using the text input box + "3. Subroutines" drop-down does a reasonable
job.

For just standard C, the draft PDF (link posted elsewhere) is excellent
since, at least in my PDF reader, I can type a partial function name and
that section can be viewed immediately. A different reader might make
it less useful, though.

--
Ben.

On 2011-02-16, alanxx <alanxxiang@gmail.com> wrote:
> I am a student of C/C++. One of the mistakes I often make is
> forgetting to include the appropriate header files for the standard
> functions I use. Is there an easy way (a website?) to find out where
> a certain standard function is prototyped in? I can find answers via
> google search or MSDN library, but it's more time consuming than I'd
> prefer. Ideally, I would prefer to just go to a website, type in the
> name of the function in a search box and find out what header file I
> should include and how it is defined. Thanks for your help!

You might try the Dinkumware site:

http://www.dinkumware.com

--
ike
SDF Public Access UNIX System - http://sdf.lonestar.org

On Feb 16, 6:00*pm, Keith Thompson <ks...@mib.org> wrote:
>
> If you're going to use that approach, perhaps it would be better to have
> "stdheader.h" include just the standard headers; if you're using
> features from <conio.h> it might be better to emphasize that by
> including it directly in your source file.
>
> (Personally I've never done that kind of thing, and it *feels* like
> poor style, but I'm not sure I can articulate why.)
>
It's the job of a standards body.

Imagine you are writing a few string functions - strcount(), let's
say, which counts all instances of ch in str.

Naturally such a valuable and reuseable function should be avialable
to others, so it's
stdheader.h
strcount.h
strcount.c

Now someone else writes a block allocator.

stdhdr.h
blockmalloc.h
blockmalloc.c

Now someone else wants to write a suffix tree. it calls both strcount
and the block allocator.

stdheader.h
strcount.h
strcount.c
stdhdr.h
blockmalloc.h
blockmalloc.c
stdheader.h
suffixtree.h
suffixtree.c

See the problem?

On Feb 17, 2:36*am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Feb 16, 6:00*pm, Keith Thompson <ks...@mib.org> wrote:
>
> > If you're going to use that approach, perhaps it would be better to have
> > "stdheader.h" include just the standard headers; if you're using
> > features from <conio.h> it might be better to emphasize that by
> > including it directly in your source file.
>
> > (Personally I've never done that kind of thing, and it *feels* like
> > poor style, but I'm not sure I can articulate why.)
>
> It's the job of a standards body.
>
> Imagine you are writing a few string functions - strcount(), let's
> say, which counts all instances of ch in str.
>
> Naturally such a valuable and reuseable function should be avialable
> to others, so it's
> stdheader.h
> strcount.h
> strcount.c
>
> Now someone else writes a block allocator.
>
> stdhdr.h
> blockmalloc.h
> blockmalloc.c
>
> Now someone else wants to write a suffix tree. it calls both strcount
> and the block allocator.
>
> stdheader.h
> strcount.h
> strcount.c
> stdhdr.h
> blockmalloc.h
> blockmalloc.c
> stdheader.h
> suffixtree.h
> suffixtree.c
>
> See the problem?

Actually, I see no problems. Please explain your point further.
If their implementations of library functions require them to use
other library functions, that doesn't impact the interfaces. It is
only if they want to expose in their interface something defined
in another header that there is an issue. Or perhaps I'm missing
your point.

-David

On Feb 16, 3:12*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 02/17/11 05:07 AM, David Resnick wrote:

> > I'm not sure it is bad "style", but it can certainly cause performance
> > issues in a large scale build to access/read/parse all the unneeded
> > header files, particularly if they aren't on a local filesystem.
>
> The opposite may also be true; if your compiler supports pre-compiled
> headers, it can speed things up. *Unless you have an awful lot of
> headers and not a lot of RAM, the OS will probably have cached them all
> on first read, so remote files doesn't usually have too big an impact.

I can't see how including a header that includes all system headers
in every file could ever speed things up relative to the selective
inclusion in each file of exactly what is needed. Why would this be?
I'm a bit murky on pre-compiled headers, haven't dealt with them,
but do they work if they have anything that depends on the compile
time
defines that riddle many system headers?

Mostly moot for system headers I agree, as they are mostly on the
local filesystem, etc. None of the regular code I use is on the
local filesystem (we use Clearcase, which uses a virtual file
system with the files residing elsewhere on a view server).
Certainly
for normal header files, it is a cost to include files you don't care
about, as the time to rebuild a large code base is significant and
unneeded depencencies make it worse...

-David