Re: "Must instantiate controlled types at library level." Why?

[Martin Krischik <krischik@users.sourceforge.net>]

James Kanze wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
> So bool and complex are not first class in C, because you need to "turn
> them on"?  I'm afraid I don't really understand this distinction.  (The
> way most C++ intantiations implement this is extremely primitive.  But
> there's nothing second class about it, in the context of the language.)

Well ISO 9899:1999(6.2.5) declares both _Bool and _Complex as keywords and
therefore first class. bool and complex on the other hand are macros and do
not feature in the language at all.

> |>  vector <> is not a first class citizen because you need "#include
> |>  <vector>"
> 
> And on many of the early C implementations I'used, float wasn't first
> class, because you needed to link in a special library to get it?

float is a keyword. So float is first class.

Neither the Ada ISO standart nor the C/C++ ISO standart define how linking
is done. So if you compiler vendor thinks that the float library need to be
linked separately is not the fault of the language.

> More precisely: First class is what you like, and second class is
> everything else.

OK, you win. Lets try an other definition: First class are the atomic
feature of an language. Those which can not be broken down further.

> |>  The argument is that everything inside a language need to be
> |>  implemented with first class citizen - they are the fondatation of
> |>  everything else and design errors in this area have profound
> |>  consequences.

> And one of the basic premises of Stroustrup is that there should be as
> little in the language as possible.  I don't necessarily agree with this
> attitude; some things, like closure, can really only be done effectively
> from within the language.  But just saying it is bad, or second class,
> doesn't prove anything.

I do like second class features as well. In fact I also spend a lot of time
creating those second class features so I like well defined building blocks
to do that.

> |>  1) #include instead of an proper import/with.
> |>  2) implicit type convertion.
> |>  3) arrays are pointers.
 
> Arrays aren't pointers.  There's just another implicit type conversion.

You are right. But a particular nasty case of  implicit type conversion
which deserves to be named separately - you loose the size of the object
which leads to nice things like Blaster32.

Blaster32 was a nice supprice when I came out of holiday last year. Without
Linux I would not able to keep the computer running long enough to download
the patch.

> And you don't mention the declaration syntax, which is enough to drive
> any sane man up the wall.

Ah, yes good point. Hint: try to use the "auto" keyword for better
readability.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com