Re: Whats the best language to learn...

cr88192 wrote:
for example, in my uses I reserve the right to lump a whole bunch of classes
in a single header file, continue using a lot of my custom "home-brew" stuff
(and refrain from STL and friends), ...

So rather than use well-tested, efficient and easy-to-use STL data
containers, you prefer developing your own? Is this even so when some
STL data container would be just perfect for a given task?

This really is one typical symptom of the C-hacker syndrome, and one
which I will never understand.

naturally C lacks some things: OO features; dynamic typing; garbage
collection; ...

but, these can be done manually to good effect as well.
The problem with C is that since it doesn't have good native support
for any of those, hacking some kind of support ends up being awkward and
very laborious to use.


not particularly, if they are done well...

Yes, particularly. Especially when compared to other languages with
native support.

Moreover, *creating* such a library is an enormous job which would be
much simpler with a language with better native support for OOP (not to
talk about how much more efficient the library becomes).

again, not really.

actually, I will take the stance that it is my personal opinion that
libraries, even those themselves written in C++ and using OO internally,
should in general not use OO for the external API (and should infact
constrain themselves strictly to what is available in C, if not much more).

So you would force the user of the library to manually destroy the
library, etc? What for?

if you don't want data to be accessible, don't give a pointer to a struct
(or, possibly, access to the struct itself). instead, if the data is to be
passed at all, pass it as an opaque void pointer

*blergh*

destruction is similar:
people don't free the objects, rather they are to be destroyed again, by
calling special functions.

Which you need to remember to call at each exit point of your
function, or wherever you need the object to be destroyed. Of course
functions may have surprising exit points, making the task even more
difficult.

in practice, this usually works pretty well

Except that it's very error-prone and the reason why so many programs
leak memory and other resources.

For example, I might typically have something like this somewhere:

enum ButtonIndex
{ OK_BUTTON, CANCEL_BUTTON, HELP_BUTTON, BUTTONS_AMOUNT };

The actual button objects are then stored in an array (sized with
BUTTONS_AMOUNT), at their respective locations, using those enumerated
values as their indices.


but, this approach is also commonly performed with '#define's, which in many
cases may offer advantages over enums.

Yeah, advantages like automatic renumbering of the indices? Advantages
like having the index being its own separate type? That's exactly why I
prefer the enum.

I use notepad.

*blergh*
.