Engineering a list container. Part 1.

[Tim Rentsch]

[description of list structure definitions]

Feel free to comment on this.

Before offering comments I would like to ask a couple of
questions. (I ask because I expect what comments are offered
will likely depend on the answers.)

1. What are you hoping to accomplish by writing (meaning
both designing and implementing) such a package?

2. What are you hoping to accomplish by posting descriptions
(or partial descriptions) of said design and implementation
in the newsgroup here?

Please note that the questions are about what you hope to
accomplish, not why you want to accomplish it (or them) or
why accomplishing it/them might be desirable. What comments
I would offer depends on the goals, but not on what the
underlying motivations might be.

 

[jacob navia]

Le 20/12/2013 15:55, Tim Rentsch a écrit :

[description of list structure definitions]

Feel free to comment on this.

Before offering comments I would like to ask a couple of
questions. (I ask because I expect what comments are offered
will likely depend on the answers.)

1. What are you hoping to accomplish by writing (meaning
both designing and implementing) such a package?

2. What are you hoping to accomplish by posting descriptions
(or partial descriptions) of said design and implementation
in the newsgroup here?

Please note that the questions are about what you hope to
accomplish, not why you want to accomplish it (or them) or
why accomplishing it/them might be desirable. What comments
I would offer depends on the goals, but not on what the
underlying motivations might be.

The answer to (1) and (2) is very simple:

I want to develop the C language and the discussion about it.

This is my stated goal since around 15 years.

Yes, C is an outdated, primitive language that should be forgotten
and replaced by C++. I have heard that many times and if you will
excuse me, I do not buy it.

I have proved that a containers library can be written completely
in C, and be as efficient and concise as the one in C++.

See my answer to Mr Garteth Owen (<[email protected]>)
He said:

--------------------------------------------------start quote
How would you implement the following in CCL?

void complex_function(const std::list<std::list<double> >&);

void make_list_of_lists(size_t siz)
{
using std::list;
list<list<double> > list_of_lists;

for(size_t z=0;z<siz;++z){
list<double> tmp;
FillList(tmp,z);
list_of_lists.push_back(tmp);
}
complex_function(list_of_lists);
}

Don't forget to include cleanup, and some method of propagating memory
exhaustion errors back to the caller.
---------------------------------------------------end quote

I answered:

-------------------------------------------------start quote
Using a GC the code is:
void make_list_of_lists(size_t siz)
{
List *ListOfLists = iList.Create(sizeof(List *));
if (ListOfLists == NULL) {
goto NoMem;
}
for (size_t z = 0; z<siz; ++z) {
List *doubleList = iList.Create(sizeof(double));
if (doubleList == NULL) goto NoMem;
FillList(doubleList,z);
int r = iList.Add(ListOfLists,doubleList);
if (r == CONTAINER_ERROR_NOMEMORY) {
NoMem:
exit(1);
}
}
}

Using manual cleanup:

void make_list_of_lists(size_t siz)
{
List *ListOfLists = iList.Create(sizeof(List *));
if (ListOfLists == NULL) {
goto NoMem;
}
iList.SetDestructor(ListOfLists,
(DestructorFunction)iList.Finalize);
for (size_t z = 0; z<siz; ++z) {
List *doubleList = iList.Create(sizeof(double));
if (doubleList == NULL) goto NoMem;
FillList(doubleList,z);
int r = iList.Add(ListOfLists,doubleList);
if (r == CONTAINER_ERROR_NOMEMORY) {
NoMem:
exit(1);
}
}
complex_function(ListOfLists);
iList.Finalize(ListOfLists);
}

As you can see, C is slightly longer than C++ but there isn't a
factor of three involved, just a few lines.
-------------------------------------------------end quote

It is interesting that you ask me "What are you trying to accomplish"
when, in fact, it should be evident.

Again:

I am trying to develop the C language and the discussion about it.

I have proved with my package that C is just as capable as C++ of
having a containers library.

I spent around 5.000 dollars of my own pocket to go to Portland to
present my work to the C standards comitee, with the idiotic idea
that the committee would be interested in developing the C language.

I learned that the committee (that has many members that are also
in the C++ committee) thinks that any such package would be
a competition for the C++ STL and should be banned.

There were some people that argued otherwise however, people that
told in public that my proposal was the best proposal (for its
documentation and scope) that they had seen in years.

I was very affected by this defeat and haven't touched the package
for almost two years.

But being what I am, I started working in my compiler system again
and posting here again.

 

[Malcolm McLean]

I learned that the committee (that has many members that are also
in the C++ committee) thinks that any such package would be
a competition for the C++ STL and should be banned.

There were some people that argued otherwise however, people that
told in public that my proposal was the best proposal (for its
documentation and scope) that they had seen in years.

I was very affected by this defeat and haven't touched the package
for almost two years.

Sorry to hear this.
There is room for a language which has generic containers with automatic
garbage collection, but not full templates / objects which encourage a
style of programming style with hard to follow flow control and hidden
dependencies.

 

[Tim Rentsch]

[description of list structure definitions]

Feel free to comment on this.

Before offering comments I would like to ask a couple of
questions. (I ask because I expect what comments are offered
will likely depend on the answers.)

1. What are you hoping to accomplish by writing (meaning
both designing and implementing) such a package?

2. What are you hoping to accomplish by posting descriptions
(or partial descriptions) of said design and implementation
in the newsgroup here?

Please note that the questions are about what you hope to
accomplish, not why you want to accomplish it (or them) or
why accomplishing it/them might be desirable. What comments
I would offer depends on the goals, but not on what the
underlying motivations might be.

The answer to (1) and (2) is very simple:

I want to develop the C language and the discussion about it.

This is my stated goal since around 15 years.

Yes, C is an outdated, primitive language that should be
forgotten and replaced by C++. I have heard that many times
and if you will excuse me, I do not buy it.

I have proved that a containers library can be written
completely in C, and be as efficient and concise as the one in
C++. [snip elaboration]

I'm sorry your experience with WG14 was so difficult.

If what you're doing can be done in regular C, ie, does not need
any languge extensions to do it, then IMO it should not be added
to the Standard. It may be of great utility, but there's no need
to add it to the Standard and therefore it should not be added.
You might want to consider offering it in a different venue, eg,
as a stand-alone open source library. Continuing your efforts
to promote it as part of C are likely to be frustrating and
perhaps ultimately counterproductive.

Please understand that in saying this I don't mean to disparage
your efforts. It's just that I believe a different marketplace
would likely be a better bet both for the code you've been
working on and for you personally.

 

[jacob navia]

Le 21/12/2013 03:24, Tim Rentsch a écrit :

If what you're doing can be done in regular C, ie, does not need
any languge extensions to do it, then IMO it should not be added
to the Standard. It may be of great utility, but there's no need
to add it to the Standard and therefore it should not be added.

Does printf, or fopen add anything to the language?
No, they use the language to make a STANDARD way of opening a file
or doing formatted output.

Essentially, the library doesn't add anything to the language itself
but improves the language expressivity because you do not need to
code formatted output AGAIN and AGAIN, you just use printf.

The STL, for instance, doesn't add anything to the language, it USES
templates to provide a STANDARD way of implementing a list, or a
flexible array.

But, as in this group, the C++ people do not want that C develops
because they fear competition from a language that is still
widely used even years after the C++ crusade against C has started.

The C++ people here continue their work with the same arguments:

What is good for C++ is not good for C.

C should not be developed at all.

You might want to consider offering it in a different venue, eg,
as a stand-alone open source library. Continuing your efforts
to promote it as part of C are likely to be frustrating and
perhaps ultimately counterproductive.

This is already the case. I am distributing it for free with a very
liberal license and source code for the sample implementation.

Bt that effort is doomed if the library doesn't become a part of the
standard library.

If the C language needs "_Generics", doesn't it need a standard way of
interfacing with a linked list?

 

[Malcolm McLean]

The STL, for instance, doesn't add anything to the language, it USES
templates to provide a STANDARD way of implementing a list, or a
flexible array.

Exactly. If the container library was standard then you'd use it, without
any questions, because it's the normal way of implementing things like
linked lists. You'd roll your own only for special circumstances, like
you might want your own printf() which used European style comas instead
of periods for decimal points. But if it's non standard you ave two issues,
dependency and familiarity. It makes the library a lot less attractive.

But, as in this group, the C++ people do not want that C develops
because they fear competition from a language that is still
widely used even years after the C++ crusade against C has started.

I don't know. I don't think there's really a C++ plot against C. The name
of C++ is a bit aggressive. If C was a commercial proprietary product, the
owner would definitely have sued.

 

[Tim Rentsch]

Does printf, or fopen add anything to the language?

Yes, they do. The functionality in <stdio.h> adds capabilities
which could not have been provided within the language otherwise.
If you don't understand this you should go back and consider
the question again.

No, they use the language to make a STANDARD way of opening a file
or doing formatted output.

Essentially, the library doesn't add anything to the language
itself but improves the language expressivity because you do not
need to code formatted output AGAIN and AGAIN, you just use
printf.

It's true that <stdio.h> was determined largely by historical
precedent, and that it provides more functionality than it
strictly needs to. However, that doesn't change the essential
property that <stdio.h> provides capabilities which cannot be
written in standard C otherwise. That is a key distinction

The STL, for instance, doesn't add anything to the language, it
USES templates to provide a STANDARD way of implementing a list,
or a flexible array.

That doesn't mean it's a good thing. There are lots of language
design choices made by the C++ community that are quite horrible;
holding up STL as an example just isn't persuasive.

But, as in this group, the C++ people do not want that C develops
because they fear competition from a language that is still widely
used even years after the C++ crusade against C has started.

The C++ people here continue their work with the same arguments:

What is good for C++ is not good for C.

C should not be developed at all.

Making ad hominem remarks doesn't help your case; conversely,
your ideas will be better received if you refrain from engaging
in such comments. You might want to think about that.

This is already the case. I am distributing it for free with a very
liberal license and source code for the sample implementation.

Great! Is it available on github?

Bt that effort is doomed if the library doesn't become a part of
the standard library.

If that's true it shows the library itself is deficient in some
significant way. There needs to be a core group of enthusiastic
users first - if the library cannot attract such a group as a
standalone library then it's not really a viable candidate for
inclusion in the language proper.

If the C language needs "_Generics", doesn't it need a standard
way of interfacing with a linked list?

I'm not sure what to think about the merits of _Generic, but here
again there is a key distinction that _Generic /must/ have
implementation support in order to function, whereas what you're
doing does not. The principle is that only those things that
absolutely require some amount of implementation support should
be considered for being added to the standard library.

 

[Seebs]

Yes, they do. The functionality in <stdio.h> adds capabilities
which could not have been provided within the language otherwise.
If you don't understand this you should go back and consider
the question again.

I'm not sure of that. I believe there are pure-C implementations of
printf, assuming the existence of putchar(). fopen(), at least if
you don't assume POSIX, is suddenly much harder.

It's true that <stdio.h> was determined largely by historical
precedent, and that it provides more functionality than it
strictly needs to. However, that doesn't change the essential
property that <stdio.h> provides capabilities which cannot be
written in standard C otherwise. That is a key distinction
between <stdio.h> and the library you are describing.

While I basically agree, C is full of bits and pieces (like the
str* functions) which are obviously implementable in pure C.

If that's true it shows the library itself is deficient in some
significant way. There needs to be a core group of enthusiastic
users first - if the library cannot attract such a group as a
standalone library then it's not really a viable candidate for
inclusion in the language proper.
Agreed.

I'm not sure what to think about the merits of _Generic, but here
again there is a key distinction that _Generic /must/ have
implementation support in order to function, whereas what you're
doing does not. The principle is that only those things that
absolutely require some amount of implementation support should
be considered for being added to the standard library.

I am inclined to think about going somewhat further, and there might
well be container designs I liked. However, I've previously pointed
out specific ways in which the proposals in question seem contrary
to the Spirit Of C. At least to me. I could imagine someone
designing a list interface that was a good enough fit that I would
support it for inclusion in the C standard.

-s

 

[Tim Rentsch]

I'm not sure of that. I believe there are pure-C implementations
of printf, assuming the existence of putchar(). fopen(), at least
if you don't assume POSIX, is suddenly much harder.

My point is about some way to do basic I/O, not necessarily
printf() specifically. Given that _some_ I/O library needs
to be present, it makes sense for it to provide a convenient
set of functions, not just a minimal set. Whether printf()
might be implementable in terms of other <stdio.h> functions
seems like a quibble. If nothing else, printf() certainly
can be implemented easily in terms of vfprintf(), but that
doesn't mean printf() should be left out.

Having said that, I would like to point out a couple ways that
the *rintf() functions deserve to be part of implementations
rather than not. First, even if all of printf() can be done in
terms of putchar(), some conversion specifiers are pretty hard
to do in an implementation-independent way - at least floating
point, and maybe also %p, really benefit from having more
specific knowledge of internal representations, etc. Second,
the *rintf() functions are unusual in that they take a varying
number of arguments, with types that depend in an intricate way
on the formatting string. Having *rintf() functions be
standardized in the language greatly encourages implementors to
provide specialized checking for the argument types in calls to
these functions (and I certainly have benefited from such
messages, as I expect most C developers have).

While I basically agree, C is full of bits and pieces (like the
str* functions) which are obviously implementable in pure C.

Sure, but these have the advantage that they were already present
in basically every existing implementation at the time. For
functionality which is not yet in many implementations the bar is
naturally much higher, as it should be.

I am inclined to think about going somewhat further, and there
might well be container designs I liked.

Oh, I'm willing to make an exception to the general principle
if there is a compelling argument to do so. But I think the
burden of proof for making a compelling argument should be on
those proposing the addition under consideration, not the other
way around. (And the argument really needs to be a compelling
argument, not just a plausible argument.)

However, I've previously
pointed out specific ways in which the proposals in question seem
contrary to the Spirit Of C. At least to me. I could imagine
someone designing a list interface that was a good enough fit that
I would support it for inclusion in the C standard.

I more or less agree with you on the last point, however the
order of consideration makes a big difference. It's important
to hear first a convincing argument that some functionality (at
least generically) belongs in the Standard, and only after that
enter into a discussion of the merits of a particular proposal.
Not doing that seems kind of cart-before-the-horse, if you know
what I mean.

 

[Seebs]

Oh, I'm willing to make an exception to the general principle
if there is a compelling argument to do so. But I think the
burden of proof for making a compelling argument should be on
those proposing the addition under consideration, not the other
way around. (And the argument really needs to be a compelling
argument, not just a plausible argument.)
Agreed.

I more or less agree with you on the last point, however the
order of consideration makes a big difference. It's important
to hear first a convincing argument that some functionality (at
least generically) belongs in the Standard, and only after that
enter into a discussion of the merits of a particular proposal.
Not doing that seems kind of cart-before-the-horse, if you know
what I mean.

I'm not sure of this. In a lot of cases, I can't usefully evaluate the
utility or benefit of a thing until I've tried to use it. So my evaluation
of whether I need a list library might be very different if I'd had one
for a long time.

-s

 

[jacob navia]

Le 21/12/2013 16:15, Tim Rentsch a écrit :

It's true that <stdio.h> was determined largely by historical
precedent, and that it provides more functionality than it
strictly needs to. However, that doesn't change the essential
property that <stdio.h> provides capabilities which cannot be
written in standard C otherwise. That is a key distinction
between <stdio.h> and the library you are describing.

This is wrong. I have written the xprintf implementations entirely
in C!

The gcc implementation is also wrtten in C. There aren't ANY printf
implemntations written in assembly that I know of.

Great! Is it available on github?

You can download it from

http://code.google.com/p/ccl/

There you will find all the source code and all the documentation.

If that's true it shows the library itself is deficient in some
significant way. There needs to be a core group of enthusiastic
users first - if the library cannot attract such a group as a
standalone library then it's not really a viable candidate for
inclusion in the language proper.

Excuse me but there wasn't ANY user of any template libraries
before the STL came around. What is crucial here is not the
actual containers since those algorithms are known since ages.
(Lists are used since more than 50 years!)

What is crucial in my proposal is a way of interfacing with usual
containers that it is UNIFORM for all containers, hence easier to learn.
But if it isn't a standard it is not available to anyone since
it is not provided FOR FREE with the implementation.

If it is a free library, even if it comes with the source code,
it is NOT available if you do not know about it, and then, even if you
know about it you have to download it, compile it, etc.

I'm not sure what to think about the merits of _Generic, but here
again there is a key distinction that _Generic /must/ have
implementation support in order to function, whereas what you're
doing does not.

No. A standard way of interfacing with containers NEEDS standard
support! Isn't it that obvious?

 

[Malcolm McLean]

Sure, but these have the advantage that they were already present
in basically every existing implementation at the time. For
functionality which is not yet in many implementations the bar is
naturally much higher, as it should be.

Getting the length of a string, comparing two strings, looking for a substring
and so on are very basic operations any program doing even trivial string
processing is likely to need.

Oh, I'm willing to make an exception to the general principle
if there is a compelling argument to do so. But I think the
burden of proof for making a compelling argument should be on
those proposing the addition under consideration, not the other
way around. (And the argument really needs to be a compelling
argument, not just a plausible argument.)

Similarly building a linked list, expandable array, hash table, or tree.
These things have been left out of standard C for various reasons. We
need to identify those reasons, then think if they still apply. I don't
have any strong preconceived views on the matter, you can make a case either
for adding support, standardising in some weaker sense a library, or adopting
a roll you own policy and leaving everything unchanged. The burden of proof
is on the side wanting change, but that shouldn't be used to shut down debate.

 

[Ian Collins]

But, as in this group, the C++ people do not want that C develops
because they fear competition from a language that is still
widely used even years after the C++ crusade against C has started.

The C++ people here continue their work with the same arguments:

What is good for C++ is not good for C.

C should not be developed at all.

Which C++ people would that be? There are quite a few of us here who
use both languages and I haven't seen any such comments.

This is already the case. I am distributing it for free with a very
liberal license and source code for the sample implementation.

Bt that effort is doomed if the library doesn't become a part of the
standard library.

The C committee prefers to standardise existing practice, rather than
adding new language features. The same applied with the part of the C++
standard library that was the STL. The STL was a very commonly used
opensource library before it became part of the language. The bulk of
the new C++ library components started of in boost. I don't think any
of those were totally new.

You should be looking at building a boost like community for C rather
than trying to drive new, relatively untested ideas directly into the
standard.

 

[jacob navia]

Le 22/12/2013 07:59, Gareth Owen a écrit :

Yes. However, in an error case:

The C++ version cleans up the data structures and propagates the error
to the caller using an exception.

The C version calls exit().

1) The C version cleans up the data structures too,
if you desire to do it!
You just add a "goto cleanup" that is shown in the same function.

2) Since C doesn't have exceptions (lcc-win does have them but that is
another story) you can propagate the error with a return code. But
the C++ version has a void return type.

The C version is longer, *and doesn't do the difficult bit*.

Yes it does. You can cleanup if you wish.

The minutes for that meeting exist. If anybody called for the C
Containers library to be banned, it was not minuted. Those minutes
differ considerably in tone to your description of the event.

http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1692.pdf

From the minutes (link above)

David K is concerned about the implementation. If C++ can do this
faster, why do it in C?

Parks points out that for his environment, C and C++ need to be able to
work together, and sees this as a divergent path for his projects.

Not in the minutes was the intervention of somebody
working in the committee telling us that anyway all the C code must
compile as C++ before being accepted in his company, or another
intervention of somebody over the phone that cried that the C committee
would be "laughed at" by the whole world if we dare replicate the STL,
etc etc. The minutes give a very "high" view of what happened.

Anyway, I do not feel like starting again. Let's forget that decision.

 

[Malcolm McLean]

The minutes for that meeting exist. If anybody called for the C
Containers library to be banned, it was not minuted. Those minutes
differ considerably in tone to your description of the event.

Jacob is not a native English speaker. "Banned" isn't quite the right word,
he's looking for "ruled out". But it's close enough. In French I'd say
"interdit", I don't know the nuances.

 

[jacob navia]

Le 22/12/2013 19:49, Gareth Owen a écrit :

But your code does not do this, whereas the C++ code does.
So the length comparison is totally spurious.
Write the cleanup code. Measure its length.

void make_list_of_lists(size_t siz)
{
List *ListOfLists = iList.Create(sizeof(List *));
if (ListOfLists == NULL) {
goto cleanup;
}
iList.SetDestructor(ListOfLists,
(DestructorFunction)iList.Finalize);
for (size_t z = 0; z<siz; ++z) {
List *doubleList = iList.Create(sizeof(double));
if (doubleList == NULL) goto cleanup;
FillList(doubleList,z);
int r = iList.Add(ListOfLists,doubleList);
if (r == CONTAINER_ERROR_NOMEMORY) {
goto cleanup;
}
}
complex_function(ListOfLists);
cleanup:
iList.Finalize(ListOfLists);
}

The number of lines doesn't change.

 

[jacob navia]

Le 22/12/2013 19:50, Gareth Owen a écrit :

Fair enough.

Excuse me, I used the wrong word. I just wanted to say that my
container library project wasn't considered OK by a short
majority of people present.

 

[Ian Collins]

Le 21/12/2013 16:15, Tim Rentsch a écrit :

Excuse me but there wasn't ANY user of any template libraries
before the STL came around. What is crucial here is not the
actual containers since those algorithms are known since ages.
(Lists are used since more than 50 years!)

What is crucial here is is STL was already popular before it became part
of the C++ standard library. In language evolution timescales its
widespread use and eventual standardisation was similar to C's stdio.

 

[jacob navia]

Le 23/12/2013 08:01, Gareth Owen a écrit :

OK, now we're getting somewhere.
The CCL solves that problem using destructors.

This is of course the correct decision. Its the only sane way to unwind
a partially constructed complex object.

But the-other-language manages it all for free for you, in a typesafe
way.

But it forces it upon you!

In C you can do it:

1) Without destructors using a GC In that case the code is even shorter:
void make_list_of_lists(size_t siz)
{
List *ListOfLists = iList.Create(sizeof(List *));
if (ListOfLists == NULL) {
return
}
for (size_t z = 0; z<siz; ++z) {
List *doubleList = iList.Create(sizeof(double));
if (doubleList == NULL) return;
FillList(doubleList,z);
int r = iList.Add(ListOfLists,doubleList);
if (r == CONTAINER_ERROR_NOMEMORY) {
return;
}
}
complex_function(ListOfLists);
}

2) Using a common heap you can free all memory used by all the created
lists in a single call to "DestroyHeap"

3) Using destructors as I showed you in the last message.

Which one is choosen depends on your application and context. Now,
in C++ you have only ONE method: destructors. It is forced upon you
by the language. Method 1 (GC) is inefficient because the destructors
are called anyway. The same for method 2.

Yours is a non-typesafe interface that requires an explicit cast of
a function pointer. Hell, as I've pointed out before, your basic list
type doesn't know type of pointer it contains, which makes
compiler-checked type safety nigh on impossible.

Look C is not C++. In C there is much less hand holding, and you have
more work as a programmer. You gain in flexibility, speed, and other
things. Whichever you prefer it depends ON THE APPLICATION and in the
context your application is being used and developed.

C and C++ are different languages used for different applications.

if (NeedsHandHolding())
goto C++
else
goto C;

As I recall, you have a preprocessor based method of implementing a
typesafe version. Interesting that an attempt to add container
libraries to C has resulted in you reimplementing:

* destructors
* templates
* iterators

Excuse me but iterators, destructors and templates are common data
processing concepts used in MANY languages!

C++ uses them, but also C#, and even venerable FORTRAN has operator
overloading!

You can't say that because I use a list of lists I am reinventing LISP!

 

[Ian Collins]

Le 23/12/2013 08:01, Gareth Owen a écrit :

But it forces it upon you!

In C you can do it:

1) Without destructors using a GC In that case the code is even shorter:

Memory isn't the only resource you may want to release....

2) Using a common heap you can free all memory used by all the created
lists in a single call to "DestroyHeap"

That could be useful, assuming the objects in the container don't have
to do any other clean up when they are destroyed. It would be a problem
for containers of pointers when you want to release the thing pointed to
(which is a common use case).

3) Using destructors as I showed you in the last message.

Which one is choosen depends on your application and context. Now,
in C++ you have only ONE method: destructors. It is forced upon you
by the language.

The objects in containers don't have to have a destructor.

Look C is not C++. In C there is much less hand holding, and you have
more work as a programmer. You gain in flexibility, speed, and other
things. Whichever you prefer it depends ON THE APPLICATION and in the
context your application is being used and developed.

Considering most C is a subset of C++, a C++ solution will never
sacrifice speed or "other things".

The type safety aspect shouldn't be so readily dismissed. Finding an
apple in a list of oranges can lead to some interesting bugs! If I
recall even the Java folks realised this and improved the type safety of
their generics.

Excuse me but iterators, destructors and templates are common data
processing concepts used in MANY languages!

True, but I think the point was with C++ the first two are built into
the language and the third is part of the standard library.