Re: contiguous in memory
On May 1, 1:46 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Apr 30, 6:39 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Victor Bazarov wrote:
Pascal J. Bourguignon wrote:
[..]
If you want to have some relationship between the two
variables, you could do:
auto int variables[2];
#define v1 variables[0]
#define v2 variables[1]
and then, &(v1) - &(v2) == 1
I'd probably go with
int variables[2], &v1 = variables[0], &v2 = variables[1];
Especially if there's an unrelated v1 or v2 in some later
scope.
You can always #undef them at the end of the function.
You can work around almost anything. That doesn't make it a
good idea.
Whether this is a "work-around" or simple "correct use of the
tool" depends. In this particular case, I'd not use a macro,
because C++ has a better mechanism. In some other cases,
however, I've found macros with limited scope to be useful. C++
can require a lot of boilerplating, and macros are one way of
handling it.
Like Victor, macros bother me at some very fundamental
level, and given that there's a good solution which doesn't
use macros, I'd use it.
They bother me when they are mixed in with code proper, since
they play by a completely different set of rules.
True, but then, almost by definition, so does much that
*generates* code. Using macros for e.g. constants is a bad
idea, because C++ has support for constants (C didn't, and still
doesn't) at the language level---there's no need for code
generation. But there are cases where code generation is
relevant---in such cases, you have three choices: an external
generator, templates and macros. And which one is most
appropriate depends on the context, and what you are generating.
[example deleted...]
This seems simple in a Usenet post, but it took several
miserable hours to debug in the real world.
Macros can certainly be (and in the past, often have been)
misused. If there's another alternative which provides the same
functionality, I'll generally prefer it. But that isn't always
the case.
The preprocessor can be used for great things, but it is not a
general-purpose programming tool. In particular, it often has
nasty interactions with the language being preprocessed.
I think the problem would better be described as that it has no
interactions with the language being preprocessed. It just does
a textual substitution, with no consideration about the context
(and when things like name binding are considered, the context
affects the meaning of a sequence of tokens very much).
This is one of the reasons I said that you need an #undef. It
guarantees that the macro won't be expanded outside of the scope
where its expansion makes sense. (But there are other macros
where #undef doesn't make sense.)
--
James Kanze (GABI Software) email:james.kanze@gmail.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