contiguous in memory

Discussion in 'C++' started by Hicham Mouline, Apr 30, 2009.

  1. void f()
    {
    auto v1;
    auto v2; // consecutive in source code
    ....
    }

    Are there any guarantees by c++ that the 2 auto variables are such that &v2
    == &v1 + sizeof(v1) ? are they contiguous?

    if not, my question becomes empirical here
    1. under x86-64, is this always true?
    2. under x86-64 msvc, is this always true?
    3. under x86-64 g++4.x is this always true?

    regards,
     
    Hicham Mouline, Apr 30, 2009
    #1
    1. Advertising

  2. Hicham Mouline wrote:
    > void f()
    > {
    > auto v1;
    > auto v2; // consecutive in source code


    "auto" what? You don't have a type specified, and no initialisation to
    derive the type from.

    > ....
    > }
    >
    > Are there any guarantees by c++ that the 2 auto variables are such that &v2
    > == &v1 + sizeof(v1) ? are they contiguous?


    No, of course not. Not to mention that the optimizer can omit placing
    them in memory altogether.

    >
    > if not, my question becomes empirical here


    A question cannot be empirical. An answer can be.

    > 1. under x86-64, is this always true?


    Not likely. Why would it differ from the general answer?

    > 2. under x86-64 msvc, is this always true?


    Ask in the msvc newsgroup.

    > 3. under x86-64 g++4.x is this always true?


    Ask in the gnu newsgroup.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Apr 30, 2009
    #2
    1. Advertising

  3. "Hicham Mouline" <> writes:

    > void f()
    > {
    > auto v1;
    > auto v2; // consecutive in source code
    > ....
    > }
    >
    > Are there any guarantees by c++ that the 2 auto variables are such that &v2
    > == &v1 + sizeof(v1) ? are they contiguous?


    No, there's no guarantee. In particular you may have &v1 < &v2 or &v1 > &v2 .


    > if not, my question becomes empirical here
    > 1. under x86-64, is this always true?


    Depends on the compiler.

    > 2. under x86-64 msvc, is this always true?


    What is documented?


    > 3. under x86-64 g++4.x is this always true?


    What is documented?

    AFAIK, nothing is documented and there may be optimization levels such
    as whatever may happen. In particular, with some optimization levels,
    if you don't take the address of a variable, or even if you take its
    address at a different time, it may be stocked in a register, or not
    exist at all in the generated code.

    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

    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Apr 30, 2009
    #3
  4. 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];

    Macros give me the creeps.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Apr 30, 2009
    #4
  5. Pascal J. Bourguignon wrote:
    > "Hicham Mouline" <> writes:
    >
    >> void f()
    >> {
    >> auto v1;
    >> auto v2; // consecutive in source code
    >> ....
    >> }
    >>
    >> Are there any guarantees by c++ that the 2 auto variables are such that &v2
    >> == &v1 + sizeof(v1) ? are they contiguous?

    >
    > No, there's no guarantee. In particular you may have &v1 < &v2 or &v1 > &v2 .

    [snip]
    > 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

    Why the macro and not references? It would lead to much more natural
    'scoping' in this case.

    Alan
     
    Alan Woodland, Apr 30, 2009
    #5
  6. Hicham Mouline

    Phlip Guest

    >> auto int variables[2];
    >> #define v1 variables[0]
    >> #define v2 variables[1]
    >>
    >> and then, &(v1) - &(v2) == 1


    > Why the macro and not references? It would lead to much more natural
    > 'scoping' in this case.


    More to the point, I thought 'auto' was abandoned / ignored / deprecated or
    something - same as 'register' and 'entry', right?
     
    Phlip, Apr 30, 2009
    #6
  7. Phlip wrote:
    >>> auto int variables[2];
    >>> #define v1 variables[0]
    >>> #define v2 variables[1]
    >>>
    >>> and then, &(v1) - &(v2) == 1

    >
    >> Why the macro and not references? It would lead to much more natural
    >> 'scoping' in this case.

    >
    > More to the point, I thought 'auto' was abandoned / ignored / deprecated or
    > something - same as 'register' and 'entry', right?


    'entry'? What's 'entry'?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Apr 30, 2009
    #7
  8. Hicham Mouline

    James Kanze Guest

    On Apr 30, 6:39 pm, Jeff Schwab <> 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.

    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. But the solution with macros does work, provided
    you don't forget the #undef.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 1, 2009
    #8
  9. Hicham Mouline

    James Kanze Guest

    On Apr 30, 6:54 pm, Victor Bazarov <> wrote:
    > Phlip wrote:
    > >>> auto int variables[2];
    > >>> #define v1 variables[0]
    > >>> #define v2 variables[1]


    > >>> and then, &(v1) - &(v2) == 1


    > >> Why the macro and not references? It would lead to much
    > >> more natural 'scoping' in this case.


    > > More to the point, I thought 'auto' was abandoned / ignored
    > > / deprecated or something - same as 'register' and 'entry',
    > > right?


    > 'entry'? What's 'entry'?


    A reserved word in K&R C, for some yet unimplemented
    functionality. Probably planned to be the same thing as entry
    in Fortran---an alternative entry point into a function.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 1, 2009
    #9
  10. In message <gtcl32$efr$>, Victor Bazarov
    <> writes
    >Phlip wrote:
    >>>> auto int variables[2];
    >>>> #define v1 variables[0]
    >>>> #define v2 variables[1]
    >>>>
    >>>> and then, &(v1) - &(v2) == 1

    >>
    >>> Why the macro and not references? It would lead to much more natural
    >>> 'scoping' in this case.

    >> More to the point, I thought 'auto' was abandoned / ignored /
    >>deprecated or something - same as 'register' and 'entry', right?

    >
    >'entry'? What's 'entry'?


    Fortran, sorry, FORTRAN, IIRC.

    --
    Richard Herring
     
    Richard Herring, May 1, 2009
    #10
  11. Hicham Mouline

    James Kanze Guest

    On May 1, 1:46 pm, Jeff Schwab <> wrote:
    > James Kanze wrote:
    > > On Apr 30, 6:39 pm, Jeff Schwab <> 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 1, 2009
    #11
  12. Hicham Mouline

    James Kanze Guest

    On May 1, 12:16 pm, Richard Herring <junk@[127.0.0.1]> wrote:
    > In message <gtcl32$>, Victor Bazarov
    > <> writes


    > >Phlip wrote:
    > >>>> auto int variables[2];
    > >>>> #define v1 variables[0]
    > >>>> #define v2 variables[1]


    > >>>> and then, &(v1) - &(v2) == 1


    > >>> Why the macro and not references? It would lead to much more natural
    > >>> 'scoping' in this case.
    > >> More to the point, I thought 'auto' was abandoned / ignored /
    > >>deprecated or something - same as 'register' and 'entry', right?


    > >'entry'? What's 'entry'?


    > Fortran, sorry, FORTRAN, IIRC.


    It's listed as a keyword in K&R I. The only other mention of it
    is immediately after the list of keywords: "The entry keyword is
    not currently impolemented by any compiler but is reserved for
    future use."

    That future never came.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 1, 2009
    #12
  13. * James Kanze:
    > On May 1, 12:16 pm, Richard Herring <junk@[127.0.0.1]> wrote:
    >> In message <gtcl32$>, Victor Bazarov
    >> <> writes

    >
    >>> Phlip wrote:
    >>>>>> auto int variables[2];
    >>>>>> #define v1 variables[0]
    >>>>>> #define v2 variables[1]

    >
    >>>>>> and then, &(v1) - &(v2) == 1

    >
    >>>>> Why the macro and not references? It would lead to much more natural
    >>>>> 'scoping' in this case.
    >>>> More to the point, I thought 'auto' was abandoned / ignored /
    >>>> deprecated or something - same as 'register' and 'entry', right?

    >
    >>> 'entry'? What's 'entry'?

    >
    >> Fortran, sorry, FORTRAN, IIRC.

    >
    > It's listed as a keyword in K&R I. The only other mention of it
    > is immediately after the list of keywords: "The entry keyword is
    > not currently impolemented by any compiler but is reserved for
    > future use."
    >
    > That future never came.


    To supplement that, the 'fortran' keyword of K&R I C was spelled in *lowercase*,
    that is, 'fortran', not 'Fortran' or 'FORTRAN'.


    Just my 3c,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
     
    Alf P. Steinbach, May 2, 2009
    #13
  14. Hicham Mouline

    James Kanze Guest

    On May 2, 1:05 am, "Alf P. Steinbach" <> wrote:
    > * James Kanze:
    > > On May 1, 12:16 pm, Richard Herring <junk@[127.0.0.1]> wrote:
    > >> In message <gtcl32$>, Victor Bazarov
    > >> <> writes


    [...]
    > >>>> More to the point, I thought 'auto' was abandoned /
    > >>>> ignored / deprecated or something - same as 'register'
    > >>>> and 'entry', right?


    > >>> 'entry'? What's 'entry'?


    > >> Fortran, sorry, FORTRAN, IIRC.


    > > It's listed as a keyword in K&R I. The only other mention
    > > of it is immediately after the list of keywords: "The entry
    > > keyword is not currently impolemented by any compiler but is
    > > reserved for future use."


    > > That future never came.


    > To supplement that, the 'fortran' keyword of K&R I C was
    > spelled in *lowercase*, that is, 'fortran', not 'Fortran' or
    > 'FORTRAN'.


    In my copy of "The C Programming Language" (1st edition),
    "fortran" isn't in the list of keywords. It does say, however,
    that "Some implementations also reserver the words `fortran' and
    `asm'."

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 3, 2009
    #14
  15. * James Kanze:
    > On May 2, 1:05 am, "Alf P. Steinbach" <> wrote:
    >> * James Kanze:
    >>> On May 1, 12:16 pm, Richard Herring <junk@[127.0.0.1]> wrote:
    >>>> In message <gtcl32$>, Victor Bazarov
    >>>> <> writes

    >
    > [...]
    >>>>>> More to the point, I thought 'auto' was abandoned /
    >>>>>> ignored / deprecated or something - same as 'register'
    >>>>>> and 'entry', right?

    >
    >>>>> 'entry'? What's 'entry'?

    >
    >>>> Fortran, sorry, FORTRAN, IIRC.

    >
    >>> It's listed as a keyword in K&R I. The only other mention
    >>> of it is immediately after the list of keywords: "The entry
    >>> keyword is not currently impolemented by any compiler but is
    >>> reserved for future use."

    >
    >>> That future never came.

    >
    >> To supplement that, the 'fortran' keyword of K&R I C was
    >> spelled in *lowercase*, that is, 'fortran', not 'Fortran' or
    >> 'FORTRAN'.

    >
    > In my copy of "The C Programming Language" (1st edition),
    > "fortran" isn't in the list of keywords. It does say, however,
    > that "Some implementations also reserver the words `fortran' and
    > `asm'."


    Is your point that 'fortran' wasn't a keyword, just a word that C compilers
    reserved?

    Hello?


    Cheers,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
     
    Alf P. Steinbach, May 3, 2009
    #15
  16. "Hicham Mouline" <> wrote in message
    news:49f9c4cf$0$90266$...
    > void f()
    > {
    > auto v1;
    > auto v2; // consecutive in source code
    > ....
    > }
    >
    > Are there any guarantees by c++ that the 2 auto variables are such that
    > &v2 == &v1 + sizeof(v1) ? are they contiguous?
    >
    > if not, my question becomes empirical here
    > 1. under x86-64, is this always true?
    > 2. under x86-64 msvc, is this always true?
    > 3. under x86-64 g++4.x is this always true?
    >
    > regards,

    Thanks for the various answers provided.
    The post has totally diverged :)
    I didn't use "auto" as the actual keyword, but barely meant an automatic
    variable...

    anyways, I simplified my actual question to keep the bare minimum but this
    was wrong.

    I am looking at 2-dimensional double arrays, and the problem at hand is to
    solve a small system of linear equations
    that can be written in matrix form A.x = b where A is the 2-dim array....

    There are many available implementations of multidim arrays, 2 of which are
    .. boost::multi_array<type, dim>
    .. boost::numeric::ublas::matrix templates

    and I was just curious about performance, and using c++ native arrays, such
    that I can
    pass around something which I can index as a[j] where i is the row
    index and j is the col index,
    and i would then compare at least these 3 ( native array, boost::multi_array
    and boost::.....::matrix )
    ignoring for now L1/L2 cache issues and the layouts
    0<=i<I 0<=j<J

    * using native arrays
    1 way I could do is with dynamic allocation
    double** a = new double*;
    a[0] = new double[J];
    ....
    a[I-1] = new double[J];
    and then pass around a which is a double**
    and then delete appropriately.


    Another way, preferably, on the stack, as it should be faster, with
    "in-place" new operators...
    Is this possible?


    A third way, a hack, in case the sizes I and J are known at compile time,
    double* Aptr;
    double A[I*J];
    Aptr=A+i*J; // for all 0<=i<I
    then reinterpret_cast of Aptr to be an double**
    and so calling a function would look like f(
    reinterpret_cast<double**>(Aptr) , I, J );
    and f may then be defined as
    f(double** A, size_t I, size_t J)
    {
    A[j] // would have its intended meaning
    }

    I though mistakenly that the above would require Aptr and A to be contiguous
    on the stack, but it doesn't,
    it still works even if they are not.
    Ignoring this point, is the above snippet valid c++?

    regards,
     
    Hicham Mouline, May 6, 2009
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. panbru

    Contiguous memory blocks

    panbru, Aug 5, 2003, in forum: Python
    Replies:
    0
    Views:
    362
    panbru
    Aug 5, 2003
  2. Olumide
    Replies:
    9
    Views:
    1,962
    Dan Pop
    Nov 30, 2004
  3. Gary Kuehn
    Replies:
    2
    Views:
    471
    Gary Kuehn
    Jul 19, 2005
  4. Phil Endecott
    Replies:
    9
    Views:
    483
    Abhishek Padmanabh
    Feb 21, 2008
  5. chachi
    Replies:
    2
    Views:
    417
    Aaron Brady
    Nov 14, 2008
Loading...

Share This Page