Reference question

[Larry.Martell]

I have only been working with C++ for 3 years, and I've come across
some code I don't understand.

static struct ct {
char ns, fl;
short sf;

struct st
{
char sy, fq;
ct* n;
} __attribute__ ((packed)) * sta;

st& os() const
{
return (st&) sf;
}
} __attribute__ ((packed)) *mc;

My confusion is about the os method. It appears to me that it returns
a reference to the st struct. But how does returning sf become a
reference to st?

TIA
-larry

 

[Micha³ 'Khorne' Rzechonek]

Beats me.  They are probably trying to rely on some obscure memory
layout compatibility that exists between the beginning of the 'st'
struct and a 'short'.  Generally speaking a cast like that is a VERY BAD
IDEA(tm).

I concur. Things like this are common in C and other code fiddling
with
memory on byte level. Atrribute "packed" is a good way to map some
buffer
to well defined fields.

I would add static asserion checking for sizeof(short) being no less
than
sizeof(st), though.

 

[Christopher]

I have only been working with C++ for 3 years, and I've come across
some code I don't understand.

static struct ct {
        char  ns, fl;
        short sf;

        struct st
        {
                char sy, fq;
                ct* n;
        }  __attribute__ ((packed)) * sta;

        st& os() const
        {
                return (st&) sf;
        }

} __attribute__ ((packed)) *mc;

My confusion is about the os method. It appears to me that it returns
a reference to the st struct. But how does returning sf become a
reference to st?

TIA
-larry

This code was written by one of those people that would get me fired
for arguing with them too much.
I would go to thier desk and tell them to stop writing garbage. I mean
everyone should know what a ct is and what its used for with our ESP
powers right?
Same for an ns, fl, or st right?

The names make it so obvious what this code is for!

 

[Larry.Martell]

This is one my own personal peeves. It blows my mind how differently
some people feel about abbreviations in code. "It's clear enough to
*me*, and to all these other people who've spent the last several years
immersed in this code base; why isn't it clear to *you*? You're just
being pedantic. Jeez, it seems like each new candidate we hire takes
longer than the last to come up to speed. The quality of candidates
must be dropping."

I know it's crappy code - it's some of the worst code I've ever seen.
I didn't write it, I inherited it - and I have to support and modify
it. I plan to completely rewrite it - once I understand it and have
the time to work on it.

 

[Chris Gordon-Smith]

This is one my own personal peeves. It blows my mind how differently
some people feel about abbreviations in code. "It's clear enough to
*me*, and to all these other people who've spent the last several years
immersed in this code base; why isn't it clear to *you*? You're just
being pedantic. Jeez, it seems like each new candidate we hire takes
longer than the last to come up to speed. The quality of candidates
must be dropping."

This reminds me of the quote:-

"Programs must be written for people to read, and only incidentally for
machines to execute." I think may be from Abelson and Sussman.

I agree of course that names such as "st" are an outrage. I suppose that it
is possible to go too far. When I look at code I have written in the past I
sometimes think I might have opted for something a little more concise. For
example, I used to write 'Molecule_Type', but now I write 'MolType'. I
probably won't go further to 'MolTp', and I hope I never resort to the
awful 'mt'.

Another thing to add about the above code (apart from the fact that it
probably should never have been written), is that if it must be written,
then it should be commented.

 

[James Kanze]

Beats me. They are probably trying to rely on some obscure
memory layout compatibility that exists between the beginning
of the 'st' struct and a 'short'. Generally speaking a cast
like that is a VERY BAD IDEA(tm).

The key, I think, is the presence of __attribute__((packed)) all
over the place. This is obviously very platform dependent code
(and probably very low level); without knowing the exact
platform, and the context in which it occurs, we can't say any
more (and knowing all that, of course, the response would be off
topic here). Generally speaking, as you say, the cast like that
is a very bad idea, but I can imagine cases in the kernel of an
OS where it might be appropriate.

(One thing does worry me a bit---the __attribute__ is g++
syntax, so I would assume g++. And g++ generates bad code when
such casts are used, on the grounds that the results are
undefined behavior. So the "implementation defined" behavior of
what he is doing is "undefined behavior".)

 

[Stefan Ram]

sumOfTheThingsICareAbout = firstThingICareAbout (...)
Have you ever tried to read Java code? The long-names-are-good
designers had a field day there, and the result is often quite hard to
read.

I am using a preprocessor affecting »character literals« with
more than a few characters. Thus »'a'« is not changed, but

'sum of the things I care about'

is being replaced by

sumOfTheThingsICareAbout

.

An initial number sign »#« will uppercase the next character.
Non-alphanumerics are converted, so:

'the sum x + y'

becomes

theSumX_43_Y


This preprocessor is written in Perl:

First, I try to avoid to modify real character constants
or strings containing single quotes:

while( $text =~ s{^([^"'\r\n]*(??:"(?:[^"\r\n]|\\")*"|'(?:[^'\r\n]|\\')*')[^"'\r\n]*)*)'([^'\\\r\n][^'\r\n]+)'}{ $1 . camel( $path, $2 ) }gem ){}

Then, I will modify the long names found via:

sub camel($$)
{ my( $path, $text )= @_;
$text =~ s{^\043([a-zA-Z])}{uc($1)}ge;
$text =~ s{([^a-zA-Z0-9_  ])}{ "_" . ord( $1 ). "_" }ge;
{ my $sp = chr( 160 );
$text =~ s{${sp}([a-zA-Z0-9_])}{uc($1)}ge; }
{ my $sp = chr( 32 );
$text =~ s{${sp}([a-zA-Z0-9_])}{uc($1)}ge; }
if( $text eq 'class' ){ $text = 'class_'; }
return $text; }

And, yes, »'class'« becomes »class_«.

Problem:

When one searches for occurrences of a name in the source code,
one needs to search for more variants, i.e., for both
»'a b'« and »aB«, or, if one doesn't, one might miss some
occurrences.

 

[Stefan Ram]

(2) No individual piece of code should have to refer to lots of
different long names. Nobody here is defending that.

Donald Knuth is not here, but he also is not nobody.

And he is using identifiers (enclosed between "@<" and "@>") like:

@<Check the ``constant'' values for consistency@>=
bad:=0;
if (half_error_line<30)or(half_error_line>error_line-15) then bad:=1;
if max_print_line<60 then bad:=2;

(...)

@<Report overflow of the input buffer, and abort@>=
if format_ident=0 then
begin write_ln(term_out,'Buffer size exceeded!'); goto final_end;
@.Buffer size exceeded@>
end
else begin cur_input.loc_field:=first; cur_input.limit_field:=last-1;
overflow("buffer size",buf_size);
@:TeX capacity exceeded buffer size}{\quad buffer size@>
end

(...)

http://ftp.funet.fi/pub/TeX/TeX-3.1/tex/tex.web

He also seems to have a means to abreviate long names.
"@<Types...@>" seems to refer to the long name beginning
with "Types", given that this is not ambigous.

 

[Chris Gordon-Smith]

Within the set of code that works with Molecules, you only have to call
it Type. (I'm not in love with that name, either.) This avoids the
long names (which neither you nor I seem to like very much), without the
need for abbreviating the English words used in those names.

using Molecule::Type;

This might be OK if we were talking about a set of code that deals with
Molecules. In fact, Molecule_Type is a class that deals with a paricular
type (or species) of Molecule. It handles the properties (Mass etc.) of
that type (or species). There is a separate class (Molecule) that deals
with actual instances of Molecule Types.

So if I were going to use a namespace called Molecule; it would be for the
code handling the actual instances. I would still need a class / namespace
/ module to handle the Molecule Types (chemical species), and I would need
a name for that class / namespace / module that was both descriptive and
not unduly long.

 

[Chris Gordon-Smith]

Why does 20% concern you? Just how many names per line are you trying
to achieve?


Boo hoo. Nobody ever taught you about inline wrapper functions? If the
meaning is already clear from context, use a simple name like "time".

But presumably time_since_epoch() is a particular kind of time function (as
opposed, for example to time_of_arrival()). If we use a name like 'time',
then it is short, but does not adequately describe what it is. Perhaps it
will sometimes be evident from the context, but this will not always be the
case. Even where the meaning can be inferred from context, this seems to
make the job of the reader harder than if a more descriptive name were
used.

 

[Chris Gordon-Smith]

Yes, that's why I said "if the meaning is already clear from context."
Frankly, a name like time_since_epoch doesn't really bother me. Suppose
the name were a little longer, though, e.g. time_since_platform_epoch
(since the epoch is not the same on all platforms), or
time_since_posix_epoch, or seconds_since_posix_epoch_as<long long>. At
some point, it becomes unreasonable to pack all relevant information
into the name, and context-specific abbreviations become necessary. In
well-factored code, I think the abbreviations tend to be obvious; in
poorly factored code, people just resort to using arbitrary prefixes of
the individual words, or omitting the vowels, etc. You end up with
monstrosities like sec_since_ep_ll. Those get on my nerves.

OK. I think we are all agreed that names like sec_since_ep_ll are an
abomination. But how to avoid them without getting to excessively long
names? Are we saying that the way to do it is modularisation? By enclosing
a name within the scope of a namespace or class we enclose it within a
context, thereby limiting the number of words needed for the name to
adequately describe the thing (variable, function etc.) that it represents.

If this is the conclusion then its yet another benefit of modularisation.
Not only does it enable the complexity of large scale systems to be managed
and minimised, thereby helping to keep them maintainable. It also helps
readability of small scale items of the system by enclosing them within a
particular context and avoiding the need for very long names or crypic
abbreviations.