why do some writers declare and define variables separately

[James Kuyper]

I was referring to a parameter used for an additional return value.
Something like

int doSomething( T* someStuff, int* someSize );

where someSize is filled in by the function.

So far, so good - that's what I thought you were talking about - until I
got to the sentence "These leave you with a choice of a compiler warning
or a dummy initial value." How does that sentence apply to someSize?
What would the compiler be warning about? How and why would the dummy
initial value be given? To put it another way, what would code look like
that corresponds to the two choices you mentioned?

 

[Ian Collins]

So far, so good - that's what I thought you were talking about - until I
got to the sentence "These leave you with a choice of a compiler warning
or a dummy initial value." How does that sentence apply to someSize?
What would the compiler be warning about? How and why would the dummy
initial value be given? To put it another way, what would code look like
that corresponds to the two choices you mentioned?

The example I was thinking of:

int n;
int result = doSomething( someBuffer, &n );

Doesn't generate any warnings. I'm sure I've seen used before assigned
warnings either from lint or gcc in such cases.

 

[James Kuyper]

On 09/26/2013 03:10 AM, David Brown wrote:
....

with C99 you can declare (and initialise) your variables anywhere that
you can have a statement

Not exactly. It's only in the block-item-list of a compound statement
that declarations and statements are interchangeable. In all of the
other contexts where a statement is allowed, a declaration is not allowed:

label: statement
case 1: statement
default: statement

if(x) statement
else statement
switch (y) statement
while(z) statement
do statement while(a);
for(int i=0; i<n; i++) statement

Of course, a compound statement is itself a statement, and can therefore
be put in any of those locations, and can contain a declaration - but
you can't put in a bare declaration in any of those locations.

I confess to being surprised by the first three examples. If I hadn't
bothered checking, I would have expected to be able to put bare
declarations in those locations. Having to wrap such a declaration in a
compound statement would limit its scope to that compound statement.
However, an empty statement followed by a declaration is permitted, and
would have the same practical effect as allowing a declaration in those
locations, so it's not an onerous restriction, just a surprising one (at
least to me).

For each of the last six examples, the statement is also a block, which
means that if a declaration were allowed there, the scope of the
declaration would end at the terminating semi-colon. Such a declaration
would be completely useless (except for any side-effects of the
initializers) which is probably why declarations are not allowed in
those locations.

In C++, declarations are statements, and as such are allowed in all of
those locations. That makes more sense in C++ than it would in C,
because a simple declaration of an object that goes out of scope
immediately can still be a very active piece of code, because of the
automatically invoked constructor and destructor.

 

[James Kuyper]

On 26/09/13 13:31, James Kuyper wrote: ....

It is surprising (to me) that you are allowed an empty statement
followed by a declaration in these cases. ...

An empty statement is a statement, and as such can be the statement that
immediately follows a label. Any following declaration would simply be
the next block-item in the block-item-list of the enclosing compound
statement. As such, it's prohibited only if such a block-item would not
be allowed. The only example I can think of would be:

do
loop_body: x++;
int j;
while(a>3);

The 'int j;' declaration is not allowed int that location, but a
statement would be equally disallowed, and it has nothing to do with the
statement label. It's because that labeled expression-statement is the
entire statement controlled by the do-statement, and the next token is
therefore required to be "while".

Something that's almost an example of a prohibited declaration after a
labeled statement would be:

if(a)
case 3: x = z-y;
double d;
else
y = z-x;

The declaration is not itself a problem, but it is parsed as the next
block-item after a complete if() statement, rendering the 'else' keyword
a syntax error. Again, a statement would be just as much of a problem as
a declaration, and the "case 3:" label has nothing to do with it.

... I would think that
declarations at labels could get you into a situation where the variable
is in scope, but you have jumped over the initialisation.

The presence of a labeled statement does make it possible to jump over
the initialization of an object with automatic storage duration. That
would causes problems if an attempt were made to read the uninitialized
value of such an object. However, it's the declarations that precede the
label that are dangerous. There's no special issues with the
declarations that follow it. As a result, there's no particularly good
reason for prohibiting a label on a declaration; I suspect the committee
didn't even think about that issue when they decided to allow mixing of
declarations and statements.

 

[Phil Carmody]

A couple of minor points... If that line is at file scope, it's a
"tentative definition" and, if nothing happens to change things, it will
behave as if there were an initialiser (of zero).


Technically, no. It's covered by the rules for initialising rather than
for assigning.

One of you appears to be talking about one of the two things there
and the other appears to be talking about the other of the two things
there. Perhaps if you used terms like "the former" and "the latter"
then there might be less confusion as to what you're talking about,
and there'd be less violent agreement.

Phil

 

[Phil Carmody]

Gordon Burditt wrote:

Don't snip attributions if you reply.


Yeah right. Utter nonsense.

I once had my manager reassure me that my yearly -20 kloc
"productivity" (in a 500 kloc "module" - hah!) wouldn't
be a problem in my yearly review. I was reassured my his
manager a while later that it indeed wouldn't be a problem.
A little while later, I was told not to do it again by both
of them, as they found it hard to explain to the manager a
layer above them.

Lesson: If you're going to remove sprawling buggy code, at
least replace it with clean compact code plus some additional
function that plots a mandelbrot set, and a Conway's life
simulation, so that the metrics don't show a massive debt.

I'm pleased to say I wasn't payed by "productivity",
but fear that I was in an environment where others were.
Stupid, but matching the evidence.

Surprised anything worked...
Phil

 

[Phil Carmody]

Keith Thompson and I have both informed him that he does not have
permission to quote us without proper attribution. With a few minor
exceptions, I believe that he's avoided directly quoting either of us
since we told him that.

I remember several counter examples to that, as Keith called him
out on it. However, by that stage he was already nesting down in
my killfile, and this just confirmed that he had no interest in
communicating on this medium the way that we've been used
to for the last few decades. I'm sure he has a rad tattoo on
his nasal septum, and called his first child Yoo'neeque too.

Whatever.

Ain't nobody got time for that shit.

Phil

 

[Dag-Erling Smørgrav]

Can anyone tell me why some writers decide to declare and write
definitions for variables separately, rather than together?

That is:
int definelater;
...
definelater = 0;

rather than:
int definelater = 0;

wouldn't the later reduce code lines?

Some people find that the latter style obscures the code, especially if
you declare many variables at once, and especially if some of your
initializations have side effects. In addition, early initialization
hides certain logic bugs by replacing a "use before initialization",
which most compilers will catch, with a "use after initialization but
before assignment of a meaningful value", which they won't.

DES

 

[James Kuyper]

Am Wed, 18 Sep 2013 16:42:10 -0500 schrieb yoodavid:


Many people do this in order to have all the variables declared on
function entry. Littering (initial and/or final) values into there
greatly reduces readability.

Have a look at this example:
---
void foo(){
int a, b, c;
float f, *d,
//some magic
}
---
void foo(){
int a=4, b=-23, c=__SOME_DEFINED_CONSTANT;
float f=0.0, *d=0,
//some magic
}
---

From just looking at the function preamble in the first example I
(hopefully) know all variables used in there, which is not possible (that
easily) on the second one.

For the sake of readability (and ease of maintenance) I usually put each
variable's definition on a different line, whether or not they were
initialized. I also normally line up the variable names. With those
changes, the distinction you make pretty thoroughly disappears:

int a = 4;
int b = -23;
int c = __RESERVED_IDENTIFIER;
float f = 0.0F;
float *d = NULL;

In case I want to patch some function magic, let's say a check of a
called function's return value, somehwere deep inside, I certainly want
to know if the symbol name "tmp", "temp", "funcCheck" or the like is
already in use. I do not want to mind-numbingly parse the whole preamble.
I just want to look at it and see.

I normally just do a text search backwards from the point of use. I
don't find that particularly mind-numbing, even in code like your second
version.

concluding rant: People who declare/define variables somehwere mid-code
shall face martial law, i.e. torture, at least.

There are strong differences of opinion on this matter - otherwise,
support for that feature would not have been added to both C++ and C99,
both evolving from C90.

The strongest argument I've seen given for your point of view is that
declaring them elsewhere it makes it harder to find the variable's
declarations. Personally, I find variables more easily when their
definitions are closer to the point of use; but with a backwards text
search, it's seldom very difficult to find a variable (unless you gave
it a bad name - I never define any identifiers shorter than three
characters, and I try to avoid defining identifiers that are subsets of
other identifiers).

It's also far easier to initialize them with a value that will actually
be used. In some cases, that will allow you to declare them const.

 

[Anand Hariharan]

A couple of minor points... If that line is at file scope, it's a
"tentative definition" and, if nothing happens to change things, it will
behave as if there were an initialiser (of zero).
Technically, no. It's covered by the rules for initialising rather than
for assigning.

By "rules", I assume you are referring to syntactic constructs such as initializer lists?

In C, what are the semantic differences between initialisation and assignment?

- Anand

PS: I've tried to format my post as best as I can. Sorry in advance if Google messes it up.

 

[Ben Bacarisse]

By "rules", I assume you are referring to syntactic constructs such as
initializer lists?

Yes, but I meant all the rules -- semantic ones as well.

In C, what are the semantic differences between initialisation and
assignment?

For variables with simple scalar types, at block scope, in modern C, the
rules are very similar. The only difference of note is that you can
initialise a const scalar, but you can't assign to one.

If the object is not a simple scalar, is at file scope, or you are using
old ANSI C, the differences start to multiply. I wouldn't like to try
to list them all.

PS: I've tried to format my post as best as I can. Sorry in advance
if Google messes it up.

No, you seemed to have tamed the beast. Did you have to do lots of hand
editing?

 

[Tim Rentsch]

According to the Official Definition of OOP -- which exists where,
exactly?

Quoting https://en.wikipedia.org/wiki/Object-oriented_programming -

The Smalltalk language, which was developed at Xerox PARC
(by Alan Kay and others) in the 1970s, introduced the term
/object-oriented programming/ to represent the pervasive use
of objects and messages as the basis for computation. [...]
Smalltalk and with it OOP were introduced to a wider
audience by the August 1981 issue of Byte Magazine.

I think it is fair to say that these statements represent the
generally accepted view in the Computer Science community.

 

[Olle Villesen]

According to the Official Definition of OOP -- which exists where,
exactly?

Quoting https://en.wikipedia.org/wiki/Object-oriented_programming -

The Smalltalk language, which was developed at Xerox PARC
(by Alan Kay and others) in the 1970s, introduced the term
/object-oriented programming/ to represent the pervasive use
of objects and messages as the basis for computation. [...]
Smalltalk and with it OOP were introduced to a wider
audience by the August 1981 issue of Byte Magazine.

I think it is fair to say that these statements represent the
generally accepted view in the Computer Science community.

It seems Simula [0] wins for first object oriented computer language. Even
the inventor of C++ Bjarne Stroustrup talks about Simula this way [1] [2]
and influencing his worldview.

If you prefer to fight "wikipedia wars" then this page [3] says Simula was
the first OO language. This is no proof for me but [1] and [2] are.

Olle

[0] http://staff.um.edu.mt/jskl1/talk.html
[1] http://www.stroustrup.com/hopl-almost-final.pdf
[2] http://www.stroustrup.com/hopl2.pdf
[3] https://en.wikipedia.org/wiki/Simula

 

[Tim Rentsch]

[what is or isn't object-oriented programming]

Sometimes I think the only reason there is OO is to
provide opportunities for the "no true Scotsman" ... thing.

That's an interesting reaction. Probably there is some truth
to it for some people. But I don't think it's universally
true, drawing an analogy with other significant programming
paradigms -

Being able to write a program in Scheme (or ML, or Haskell) is
not the same as understanding functional programming.

Being able to write a program in Prolog is not the same as
understanding logic programming.

Being able to write a program in C++ (or Objective C, or Eiffel,
or Smalltalk) is not the same as understanding object-oriented
programming.

Similarly, some programmers never understand C as anything more
than a glorified assembler, but such people -- even though they
may be quite good at low level work -- don't have the same grasp
as those who understand large-scale procedural programming.

 

[Martin Shobe]

According to the Official Definition of OOP -- which exists where,
exactly?

Quoting https://en.wikipedia.org/wiki/Object-oriented_programming -

The Smalltalk language, which was developed at Xerox PARC
(by Alan Kay and others) in the 1970s, introduced the term
/object-oriented programming/ to represent the pervasive use
of objects and messages as the basis for computation. [...]
Smalltalk and with it OOP were introduced to a wider
audience by the August 1981 issue of Byte Magazine.

I think it is fair to say that these statements represent the
generally accepted view in the Computer Science community.

I don't know about that. In the past, there was another view based off
the SIMULA language (as pointed out elsethread). I suspect, if it's been
settled at all, that it's currently an amalgamation of the two views.

Martin Shobe

 

[Tim Rentsch]

Object-oriented programming - both the term and the concept -
predates not only C++-style destructors but C++ itself.

How does that matter? Why particular style of computer programming
(OOP) can not evolve [snip elaboration]

Lots of people make the mistake of thinking object-oriented
programming is simply a set of language features. Often
the thinking goes something like this:

1. C++ is an object-oriented language.
2. C++ has feature X (perhaps part of class definitions).
3. Therefore, feature X is object-oriented.

Obviously inferences like the above are bogus. The C language
has functions, but that doesn't make C a functional programming
language. If we took a functional language and added exception
handling to it, even if the exception mechanisms affected
functions in some way that doesn't mean exception handling
becomes part of functional programming. The relevant question
is not whether the paradigm of object-oriented programming can
evolve, but whether something like destructors does anything
to evolve it. They haven't.

Anyone who thinks destructors are part of OOP doesn't
understand the term.

What is your ground to say so? [snip elaboration]

At the risk of appearing immodest, try this google search
(including the quotes):

"object-oriented programming will be in the 1980s"

Is it now fair to ask what is your ground for your statements?

 

[Öö Tiib]

Tiib writes:
On Sunday, 22 September 2013 21:28:09 UTC+3, Tim Rentsch wrote:
One of the more useful things from OO is RAII - Resource
Allocation Is Initialization.

RAII is a C++ -ism. It has nothing to do with OOP.

Something it has to do. Destructors have something to do with
OOP (being in set of OOP features of some languages).

Object-oriented programming - both the term and the concept -
predates not only C++-style destructors but C++ itself.

How does that matter? Why particular style of computer programming
(OOP) can not evolve [snip elaboration]

Lots of people make the mistake of thinking object-oriented
programming is simply a set of language features.

Encapsulation is /the/ fundamental feature (not feature like 'if-else' statement). Without
destructors it is annoyingly complex (but possible) to encapsulate precious resources
(like threads, file descriptors, sockets etc.) Have you tried? In language with
exceptions?

I did not say things like:

1. C++ is an object-oriented language.
2. C++ has feature X (perhaps part of class definitions).
3. Therefore, feature X is object-oriented.

Why you snip what I said and post such fallacious logic and then argue against it?

The relevant question is not whether the paradigm of object-oriented programming
can evolve, but whether something like destructors does anything to evolve it.
They haven't.

A feature that makes it possible to have firm encapsulation is very handy for
OOP. That I have already elaborated.

Anyone who thinks destructors are part of OOP doesn't
understand the term.

What is your ground to say so? [snip elaboration]

At the risk of appearing immodest, try this google search
(including the quotes):

"object-oriented programming will be in the 1980s"

Pointless to be too modest anyway. I have read that before and I agree. Lot of people do not see
farther from features. Generally a language does not matter. Lack of features is often annoying
inconvenience. That may make OOP hard or ugly but never impossible. You need trees for
forest. Pine is tree. Therefore pine can be part of forest.

Is it now fair to ask what is your ground for your statements?

You have snipped my elaboration and links. Do you here ask to repost them? Or do you want
my publications? I publish nothing. I make software. I am practicing engineer not teacher. Posting
to usenet just for amusement.

 

[Ben Bacarisse]

For me a destructor is merely a special /method/ that is as strongly
related to /object/'s lifetime as is /constructor/. It fits very
well into OOP. The alternatives like finalizers and disposers feel
inelegant hacks.

It fits when there is a useful concept of lifetime, but, to take one
example, Smalltalk has garbage collection, and there is no concept of
the lifetime of an object that is of any use to the programmer.

In another post (it's a shame I can't reply to both at once) you mention
the huge benefit of destructors in resource management (open file,
dynamically allocated memory and so on). Where the language has the
right concepts, this is true, but it does not imply an object-oriented
language. One can image C+exceptions in which a variable can be tagged
with code to be executed at the end of its lifetime:

FILE *fp = NULL on byebye = { if (fp) fclose(fp); }

We'd have destructors, but not OO. In other words, the two concepts are
orthogonal. Destructors may not even make sense in an object-oriented
language, and they may be present in one that is not OO.

Obviously C++ relates the two by being object-oriented (in part) and by
having destructors, but that does not mean there is any logical
connection between the two concepts.

 

[Tim Rentsch]

[...]
Object-oriented programming - both the term and the concept -
predates not only C++-style destructors but C++ itself.
Anyone who thinks destructors are part of OOP doesn't
understand the term.

According to the Official Definition of OOP -- which exists where,
exactly?

Quoting https://en.wikipedia.org/wiki/Object-oriented_programming -

The Smalltalk language, which was developed at Xerox PARC
(by Alan Kay and others) in the 1970s, introduced the term
/object-oriented programming/ to represent the pervasive use
of objects and messages as the basis for computation. [...]
Smalltalk and with it OOP were introduced to a wider
audience by the August 1981 issue of Byte Magazine.

I think it is fair to say that these statements represent the
generally accepted view in the Computer Science community.

It seems Simula [0] wins for first object oriented computer language. Even
the inventor of C++ Bjarne Stroustrup talks about Simula this way [1] [2]
and influencing his worldview.

There is no question that Simula 67 has classes and inheritance,
and also predates Smalltalk. Calling it the first object-oriented
language, however, is historical revisionism - the term "object-
oriented programming" didn't exist until Alan Kay coined it, and
the standalone adjective "object-oriented" came along only after
that. Moreover it misses a key point - whether a program is
"object-oriented" is not determined by the presence or absence of
certain language features, any more than functional programming is
determined by whether or not a language has functions. Certainly
it is possible to do object-oriented programming in Simula, but
it's also possible in FORTRAN; I have done both.

It's also true that some of the key ideas underlying OOP were
present in earlier systems. Besides Simula, three earlier
examples are cited that influenced Smalltalk, those being Euler,
Sketchpad, and an early filesystem on a Burroughs computer. But
it was Alan Kay who coined the term and first articulated what
he meant by it, so when it comes to defining the term that seems
fairly authoritative.

If you prefer to fight "wikipedia wars" then this page [3] says
Simula was the first OO language.

I'm sure the people who edit wikipedia pages will think what
they want. It's easy enough to see that this is more historical
revisionism, if one is inclined to do so, by reading the early
literature.

This is no proof for me but [1] and [2] are.

I was doing object-oriented programming, as articulated by
Alan Kay, before Stroustrup started work on what was later
to be called C++. I see no reason to consider him an
authority on the subject.

[0] http://staff.um.edu.mt/jskl1/talk.html
[1] http://www.stroustrup.com/hopl-almost-final.pdf
[2] http://www.stroustrup.com/hopl2.pdf
[3] https://en.wikipedia.org/wiki/Simula

 

[glen herrmannsfeldt]

(snip)

It seems Simula [0] wins for first object oriented computer
language. Even the inventor of C++ Bjarne Stroustrup talks
about Simula this way [1] [2] and influencing his worldview.

There is no question that Simula 67 has classes and inheritance,
and also predates Smalltalk. Calling it the first object-oriented
language, however, is historical revisionism - the term "object-
oriented programming" didn't exist until Alan Kay coined it, and
the standalone adjective "object-oriented" came along only after
that. Moreover it misses a key point - whether a program is
"object-oriented" is not determined by the presence or absence of
certain language features, any more than functional programming is
determined by whether or not a language has functions. Certainly
it is possible to do object-oriented programming in Simula, but
it's also possible in FORTRAN; I have done both.

I used an object-oriented graphics system (UG, or Unified Graphics,
in case anyone else here used it) in the early 1970's. It had APIs
in both Fortran and PL/I. Just about every call had a "Graphic
Element" as its first argument, so, yes, I believe you can do
OO programming in Fortran 66. (Some of the API routines might have
been in assembler.)

Even so, I am not convinced one can say that no language was
necessarily "object oriented" before the term was invented to
describe it.

It's also true that some of the key ideas underlying OOP were
present in earlier systems. Besides Simula, three earlier
examples are cited that influenced Smalltalk, those being Euler,
Sketchpad, and an early filesystem on a Burroughs computer. But
it was Alan Kay who coined the term and first articulated what
he meant by it, so when it comes to defining the term that seems
fairly authoritative.

I have the "Handbook of Programming Languages" including vol. 1
(Object-Oriented Languages).

The hereditary graph on the OO side starts with Simula, but there
is no Simula chapter. In the introduction:

"SIMULA 67 was the first example of using classes of objects.
The first truly object-oriented programming language was
Smalltalk named in 1971."

Seems to me one can use the "True Scotsman" analogy here.
Simula was Object-Oriented, but not truly Object-Oriented.

By the way, I remember TXR telling me about Simula on the PDP-10
sometime around 1978, but me not being very interested in it.

-- glen