Comments on: A question of memory layout http://efesx.com/2010/01/20/a-question-of-memory-layout/ Technical & low level Mon, 30 Apr 2012 17:39:06 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Vivek Ragunathan http://efesx.com/2010/01/20/a-question-of-memory-layout/#comment-169 Vivek Ragunathan Wed, 17 Feb 2010 12:35:04 +0000 http://cplusplus.co.il/?p=813#comment-169 It is perceivable that the different versions of the classes above will result in different output. But isn't A* not the proper way of accessing in all cases? C++ does not have an inherent array type, and we assume A* to be an array. Secondly, related to the intent of your post which is object layout, the user should be aware of what he is accessing. Nice post! It is perceivable that the different versions of the classes above will result in different output. But isn’t A* not the proper way of accessing in all cases?

C++ does not have an inherent array type, and we assume A* to be an array. Secondly, related to the intent of your post which is object layout, the user should be aware of what he is accessing.

Nice post!

]]> By: rmn http://efesx.com/2010/01/20/a-question-of-memory-layout/#comment-168 rmn Fri, 22 Jan 2010 16:14:39 +0000 http://cplusplus.co.il/?p=813#comment-168 Good suggestion! I'll add this to my TODO list :) Thanks for the input. Good suggestion! I’ll add this to my TODO list :)

Thanks for the input.

]]> By: Ofek http://efesx.com/2010/01/20/a-question-of-memory-layout/#comment-167 Ofek Thu, 21 Jan 2010 15:13:26 +0000 http://cplusplus.co.il/?p=813#comment-167 Roman, you could devise an even nastier 'gotcha' with virtual inheritance... You can fiddle with the size of the virtual *base* table, as well as the virtual *function* table - as both precede the data members in the object memory layout. Roman, you could devise an even nastier ‘gotcha’ with virtual inheritance… You can fiddle with the size of the virtual *base* table, as well as the virtual *function* table – as both precede the data members in the object memory layout.

]]> By: Nadav http://efesx.com/2010/01/20/a-question-of-memory-layout/#comment-166 Nadav Thu, 21 Jan 2010 13:49:15 +0000 http://cplusplus.co.il/?p=813#comment-166 Ofek, you bring a really good point. I looked at the compiled code and I was surprised to see the memory layout. After taking into account the fact that class "A" may not be modified, it does make sense. My mistake was that is a single virtual function is declared in the path, the entire path DOWNWARDS is declared virtual and not upwards, as we can see from this example. rmn, I really enjoyed this one! Ofek, you bring a really good point. I looked at the compiled code and I was surprised to see the memory layout. After taking into account the fact that class “A” may not be modified, it does make sense. My mistake was that is a single virtual function is declared in the path, the entire path DOWNWARDS is declared virtual and not upwards, as we can see from this example.

rmn, I really enjoyed this one!

]]> By: Ofek http://efesx.com/2010/01/20/a-question-of-memory-layout/#comment-165 Ofek Thu, 21 Jan 2010 07:06:29 +0000 http://cplusplus.co.il/?p=813#comment-165 Nadav - I don't know what the standard has to say about this, but i do think such a compiler/linker design would be infeasible. A and B can be declared in different files - and in fact in different lib's altogether. When the compiler is faced with an 'A*' argument, it has only A's type declaration to consult, and *not* its children. Nadav – I don’t know what the standard has to say about this, but i do think such a compiler/linker design would be infeasible. A and B can be declared in different files – and in fact in different lib’s altogether. When the compiler is faced with an ‘A*’ argument, it has only A’s type declaration to consult, and *not* its children.

]]> By: Nadav http://efesx.com/2010/01/20/a-question-of-memory-layout/#comment-164 Nadav Wed, 20 Jan 2010 21:20:43 +0000 http://cplusplus.co.il/?p=813#comment-164 Hi RMN! I am surprised that the second and the third definitions have a different output. To my understanding, once a single virtual function is declared in the path, the entire path becomes virtual, which means that the second example should be the same as the third. Nadav Hi RMN!

I am surprised that the second and the third definitions have a different output. To my understanding, once a single virtual function is declared in the path, the entire path becomes virtual, which means that the second example should be the same as the third.

Nadav

]]>