Re: Calling C library functions from C++ program
On Dec 11, 6:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Dec 10, 5:39 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
The problem is that no two people agree exactly what
"method" should mean in C++.
I do use "method" to mean "member
function," just for brevity.
Except that not everyone understands it that way.
I've never seen any confusion on the matter, but I take your
word for it, and rethink the terminology.
Most of the time, there is no real confusion. Human languages
contain a lot of redundance, and context helps. (In practice,
too, most of the people who use the word "method" are OO freaks,
and don't have any non-member functions:-).)
(Eiffel seems to speak of commands and queries, which
correspond more or less to non-const and const functions in
C++. A decidedly better choice than method.
The advantages are simple: they don't have the ambiguity of
"method", which is already used in another sense in software
Of course they do. To me, a "command" is an object
representing a user request, and "query" is a specification of
information to be obtained from a relational database. I'm
pretty sure "method" is more widely understood than "command"
I didn't say that they were perfect. Just better than "method".
It's true that if I hear the word "query", I think data base,
and if I hear the word "command", I think of something entered
at the command line. But neither word comes up otherwise in C++
(or Eiffel, or whatever compiled programming language I'm
using). Where as I use different methods to develop C++ code
all the time. It's all a question of how much the context might
and they distiguish between const and non-const.
So do "const" and "non-const."
With regards to clarity, the "official" C++ terminology is
pretty close to perfect for C++ (where there is no distinction
between functions and procedures, or whatever you want to call
them). With regards to verbosity, "non-const non-virtual member
function" isn't the shortest thing around:-). But most of the
time, context will allow dropping some of the adjectives, with
no loss of understanding.
And I wouldn't use "command" and "query" in a C++ community,
because no one would understand what I was talking about.
Similarly, I don't normally complain if someone uses method, as
long as the context makes it clear. Because people understand
the term---whether it was well chosen to begin with or not.
Conceptually, there's a real difference. Practically, it's
harder to say: in theory, a function returns a value, and
doesn't modify state (doesn't do anything), where as a
procedure (or whatever you want to call it) "does something"
(so you wouldn't want to use it in an expression). In
practice, some things that are conceptually functions will
modify state (e.g. rand()), and its frequent that a
procedure which does something will also want to report
whether whatever it was trying to do succeeded. Which sort
of blurrs the distinction at the language level, or rather
means that the distinction at the language level doesn't
correspond to the distinction at the conceptual level.
I had also heard that functions mapped data from one space to
another (i.e. returned values), whereas procedures did not.
That's more or less the "theory" I was thinking about. The
The only prohibition I've ever heard on side effects, outside
of functional programming is for "predicates." I am firmly of
the opinion that if something has side effects, it should not
be called a predicate.
When I said "in theory", I thought it would be understood: in an
ideal world. I'm well aware that practical considerations
intervene. (And the reason you hear more about the prohibition
on side effects in functional programming is that functional
programmers tend to be more concerned with theory than C++
programmers, who are, judging from those I know, generally
Still, in practice, it seems safer to make the distinction
between a procedure call and an assignment statement, rather
than just depending on side effects.
I don't know that "just" depending on side effects is any less
clear than assignment.
One rule that I've found useful for ensuring clarity is that a
statement does one, and only one thing. Statements that modify
10 or 15 different variables, or that modify a lot of variables
while also controlling flow, make programs harder to understand.
So having an assignment statement, and a procedure call
statement, makes some sense.
But again, it's a general rule, not something absolute. IMHO, C
goes too far in one direction, Pascal too far in the other, but
on the whole, I'd favor something closer to Pascal than to C.
In particular, given a vector v, v.insert(3) seems much
clearer to me than (say) v += 3 (the string style) or v << 3
(the Qt list style).
I'm totally in agreement there. But v.insert() doesn't have to
be a function (in the Pascal sense); it could be a procedure.
Where the discussion becomes interesting (because there is no
one right answer) is when one introduces the possibilities of
chaining, or something like v.erase( iter ), which returns a
valid iterator so you can continue iterating. The Pascal rule
that you can't ignore a return value doesn't work well with
these sort of functions.
Similarly, I'm fine with assignment statements that have no
immediate side-effects, e.g. those used in expression
Well, they do have side effects in the compiler (and of course,
they're always constant expressions fully evaluated by the
The important point here, however, is that the idioms we use
have grown up within the language, based on the language. Had
the language been different, we'd have developed different
idioms. In the end, you always end up with a complex total
which is more than just the sum of its parts. I find
discussions about "what if" some aspect of the language were
different interesting, abstractly, but in practice, of course,
you can't just change one part and expect everything else to
remain the same, and you can't really know what the effect would
be on everything else.
James Kanze (GABI Software) email:email@example.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34