10 most used

P

Profetas

Hi I am starting a project in C.
And I would like to hear from you the 10 most used c library.

just say the ones that pop up in your head.


Thanks
 
E

Emmanuel Delahaye

Profetas said:
Hi I am starting a project in C.
And I would like to hear from you the 10 most used c library.

just say the ones that pop up in your head.

The standard C library, of course. Others are off-topic in this newsgroup.

BTW, your question is silly to me. On the projects I work for (embedded
software for digital network hardware products [1]), the extra libraries I
use depends on the environment (system, I use psos, for example), the
application (I build my personnal library from modules written for previous
projects [2]).

I don't really understand the actual meaning your question.
 
M

Malcolm

Profetas said:
Hi I am starting a project in C.
And I would like to hear from you the 10 most used c library.

just say the ones that pop up in your head.
There's no sensible answer because it depends what you are doing. For
instance some embedded systems come with almost no libraries at all, whilst
a system like MS Visual C ships with literally thousands of functions.

In beginner programs printf() is used heavily, whilst it is often not used
at all in graphical programs. Some programs do a lot of work with files,
whilst others don't acess files at all. If you are a business programmer you
might never use the maths library, if you are a games programmer then you
will use it constantly.
 
P

Profetas

Sorry, I misunderstood his question.

That is what I ment the ones that I use is
malloc.h
string.h
stdio.h

I want the ones that you use that I have not listed above.
 
J

Joona I Palaste

That is what I ment the ones that I use is
malloc.h
string.h
stdio.h
I want the ones that you use that I have not listed above.

malloc.h is non-standard, needless and probably deprecated as well. All
its functionality can be found in stdlib.h.
 
A

Arthur J. O'Dwyer

Non standard. You probably want <stdlib.h> instead. Note that the <>
are part of the header.

Are they? I thought the header only contained preprocessor
directives, type definitions and 'extern' declarations... ;-)
Please read again your C-book and learn urgently the difference between a
library and a header.

If his C book is the Standard, he won't learn anything relevant
there. N869 uses the word "library" as a noun in only two places I
can find: as part of the phrase "the standard library" and in footnote
5.1.2.3#2[10] (non-normative), which refers to "the floating-point
environment library <fenv.h>". 5.1.1.1 also mentions that compiled
TUs can be stored in "libraries," but that's hardly descriptive enough
to serve as a "difference" between headers and libraries from the
OP's point of view.

I'm not suggesting it wasn't a pointless question... :)

-Arthur
 
E

Emmanuel Delahaye

Arthur J. O'Dwyer said:
Are they? I thought the header only contained preprocessor
directives, type definitions and 'extern' declarations... ;-)

True enough, thanks for the correction. My sentence was badly worded. I
actually meant

Note that the said:
Please read again your C-book and learn urgently the difference between a
library and a header.

If his C book is the Standard, he won't learn anything relevant
there. N869 uses the word "library" as a noun in only two places I
can find: as part of the phrase "the standard library" and in footnote
5.1.2.3#2[10] (non-normative), which refers to "the floating-point
environment library <fenv.h>". 5.1.1.1 also mentions that compiled
TUs can be stored in "libraries," but that's hardly descriptive enough
to serve as a "difference" between headers and libraries from the
OP's point of view.

"standard library" is clear enough to me. It's definitely not a header.

That said, I hope that the OP's C-book is not the standard. Too hard to read
to a newbie.

In addition, "the floating-point environment library <fenv.h>" is very
confusing to me, because, as you know, <fenv.h> is NOT a library! (Ok, it was
in a non-normative section...)
 
T

Thomas Matthews

Profetas said:
standard C



That is what I ment the ones that I use is
malloc.h
string.h
stdio.h

I want the ones that you use that I have not listed above.

Are you after the most popular header files or
perhaps the most common functions or some common
identifier?

For example, EXIT_SUCCESS and EXIT_FAILURE are common
identifiers from stdlib.h. However, if I am writing
a program the uses a lot of I/O, I'll include stdio.h,
but on an embedded system, I may not include any
library header files.

Also, how are you applying this information?



--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
K

Keith Thompson

Emmanuel Delahaye said:
True enough, thanks for the correction. My sentence was badly worded. I
actually meant

Note that the <> are part of the _name of the_ header.

I don't believe that's correct; I think the '<' and '>' are part of
the syntax of the #include directive.

C99 6.19.2p2:

A preprocessing directive of the form

# include <h-char-sequence> new-line

searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the
entire contents of the header. How the places are specified or the
header identified is implementation-defined.

Note that it's the sequence *between* the delimiters that identifies
the header.

On the other hand, section 7 of the standard consistently refers to
the standard headers as <assert.h>, <complex.h>, <ctype.h>, etc.
 
D

Dan Pop

In said:
malloc.h is non-standard, needless and probably deprecated as well. All
its functionality can be found in stdlib.h.

Avoid topics you have no clue about. The only correct part of your
statement is that malloc.h is non-standard. Because of this, it cannot
be deprecated (only standard features can). And there is plenty of
malloc.h functionality that cannot be found in stdlib.h.

Dan
 
C

CBFalconer

Dan said:
Avoid topics you have no clue about. The only correct part of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
your statement is that malloc.h is non-standard. Because of
this, it cannot be deprecated (only standard features can).
And there is plenty of malloc.h functionality that cannot be
found in stdlib.h.

The following is malloc.h as found on my system. Please point out
the functionality that cannot be found in stdlib.h.

/* Copyright (C) 1995 DJ Delorie, see COPYING.DJ for details */
#ifndef __dj_include_malloc_h_
#define __dj_include_malloc_h_

#ifdef __cplusplus
extern "C" {
#endif

#ifndef __dj_ENFORCE_ANSI_FREESTANDING

#ifndef __STRICT_ANSI__

#ifndef _POSIX_SOURCE

#include <stdlib.h>

#endif /* !_POSIX_SOURCE */
#endif /* !__STRICT_ANSI__ */
#endif /* !__dj_ENFORCE_ANSI_FREESTANDING */

#ifndef __dj_ENFORCE_FUNCTION_CALLS
#endif /* !__dj_ENFORCE_FUNCTION_CALLS */

#ifdef __cplusplus
}
#endif

#endif /* !__dj_include_malloc_h_ */
 
K

Keith Thompson

CBFalconer said:
The following is malloc.h as found on my system. Please point out
the functionality that cannot be found in stdlib.h.
[snip]

On the other hand, I have a (very old) system whose <malloc.h>
contains declarations for a type called "struct mallinfo" (containing
information about the current state of the heap), a function
mallinfo() that returns a value of that type, and a function mallopt()
that presumably allows some control over the inner workings of
malloc(), free() and friends.

It's entirely non-standard (pre-standard, in fact), and I've never
felt the need to use it.
 
R

Rob Thorpe

CBFalconer said:
The following is malloc.h as found on my system. Please point out
the functionality that cannot be found in stdlib.h.

/* Copyright (C) 1995 DJ Delorie, see COPYING.DJ for details */
#ifndef __dj_include_malloc_h_
#define __dj_include_malloc_h_

#ifdef __cplusplus
extern "C" {
#endif

#ifndef __dj_ENFORCE_ANSI_FREESTANDING

#ifndef __STRICT_ANSI__

#ifndef _POSIX_SOURCE

#include <stdlib.h>

#endif /* !_POSIX_SOURCE */
#endif /* !__STRICT_ANSI__ */
#endif /* !__dj_ENFORCE_ANSI_FREESTANDING */

#ifndef __dj_ENFORCE_FUNCTION_CALLS
#endif /* !__dj_ENFORCE_FUNCTION_CALLS */

#ifdef __cplusplus
}
#endif

#endif /* !__dj_include_malloc_h_ */

It's a non-standard header. So what it contains can vary with the
system, maybe Dan's has more in it. The glibc malloc.h provides
rather more features.
 
C

CBFalconer

Keith said:
CBFalconer said:
The following is malloc.h as found on my system. Please point
out the functionality that cannot be found in stdlib.h.
[snip]

On the other hand, I have a (very old) system whose <malloc.h>
contains declarations for a type called "struct mallinfo"
(containing information about the current state of the heap), a
function mallinfo() that returns a value of that type, and a
function mallopt() that presumably allows some control over the
inner workings of malloc(), free() and friends.

It's entirely non-standard (pre-standard, in fact), and I've
never felt the need to use it.

Which (the non-standard) was precisely what Joona pointed out in
the first place, which makes criticizing its functionality
somewhat moot.
 
D

Dan Pop

In said:
Keith said:
CBFalconer said:
Dan Pop wrote:

malloc.h is non-standard, needless and probably deprecated as
well. All its functionality can be found in stdlib.h.

Avoid topics you have no clue about. The only correct part of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
your statement is that malloc.h is non-standard. Because of
this, it cannot be deprecated (only standard features can).
And there is plenty of malloc.h functionality that cannot be
found in stdlib.h.

The following is malloc.h as found on my system. Please point
out the functionality that cannot be found in stdlib.h.
[snip]

On the other hand, I have a (very old) system whose <malloc.h>
contains declarations for a type called "struct mallinfo"
(containing information about the current state of the heap), a
function mallinfo() that returns a value of that type, and a
function mallopt() that presumably allows some control over the
inner workings of malloc(), free() and friends.

It's entirely non-standard (pre-standard, in fact), and I've
never felt the need to use it.

Which (the non-standard) was precisely what Joona pointed out in
the first place, which makes criticizing its functionality
somewhat moot.

If Joona simply mentioned that <malloc.h> is non-standard, he would have
been right and I wouldn't have objected.

Like many other headers, <malloc.h> originated under Unix and the typical
<malloc.h> found on Unix systems has features not present in <stdlib.h>.
Features accurately mentioned by Keith.

Therefore, Joona's statement, as such, was flatly wrong.

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,280
Latest member
BGBBrock56

Latest Threads

Top