meaning of problem statements (Stroustrup, 5.9)

[arnuld]

i don't understand the meaning of these 2 problems statements:

2.) What on your system, are the restrictions on pointer types char*,
int* and void* ?
e.g may an "int*" have an odd value ?

caveat: an "int" can have any value odd or even, whatever, "int*" will
only point to it.

8.) Run some tests to see if your compiler generates equivalent code
for iteration using pointers and iteration using indexing. If
different degrees of optimizations are requested , see if and how that
affects the quality of the generated code.

caveat: how can i test the difference, i can't read the binary code

[Anand Hariharan]

arnuld wrote:

i don't understand the meaning of these 2 problems statements:

2.) What on your system, are the restrictions on pointer types char*,
int* and void* ?
e.g may an "int*" have an odd value ?

caveat: an "int" can have any value odd or even, whatever, "int*" will
only point to it.

8.) Run some tests to see if your compiler generates equivalent code
for iteration using pointers and iteration using indexing. If
different degrees of optimizations are requested , see if and how that
affects the quality of the generated code.

caveat: how can i test the difference, i can't read the binary code

Not sure what you meant by "caveat", but I'd suggest you ignore such
"low-level" questions.

--
ROT-13 the email address to reply.

[Jim Langston]

"arnuld" <ge*********@gmail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

>i don't understand the meaning of these 2 problems statements:

2.) What on your system, are the restrictions on pointer types char*,
int* and void* ?
e.g may an "int*" have an odd value ?

caveat: an "int" can have any value odd or even, whatever, "int*" will
only point to it.

8.) Run some tests to see if your compiler generates equivalent code
for iteration using pointers and iteration using indexing. If
different degrees of optimizations are requested , see if and how that
affects the quality of the generated code.

caveat: how can i test the difference, i can't read the binary code

It's asking about alignment. Some computers require that certain types
(such as ints) reside on certain boundaries. Some machines will work if
they are missaligned, just slower.

For example, on my Windows XP box, the compiler will align 4 byte intergers
every 4 bytes. So the memory address has to be divisible by 4. The
compiler will never purposely place an int starting on an odd memory
address. So that this structure. This can be seen most obvoiusly in
structures.

struct Foo
{
char MyChar; // 1 byte
int MyInt; // 4 bytes
};

int main
{
std::cout << sizeof Foo << "\n";
}

What would you expect the output of this program to be? That is, what would
you think the size of a structure containing one character and one 4 byte
interger to be? If you run it I don't think you'll get the answer you first
thought.

Asnwer the rest of the questions (char, void, etc..) for your own excercise.

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-04-01 20:09, arnuld wrote:

i don't understand the meaning of these 2 problems statements:

8.) Run some tests to see if your compiler generates equivalent code
for iteration using pointers and iteration using indexing. If
different degrees of optimizations are requested , see if and how that
affects the quality of the generated code.

caveat: how can i test the difference, i can't read the binary code

The easiest way is probably to make the program loop the test so many
times that any difference in speed becomes noticeable.

#include <iostream>
#include <ctime>

int main()
{
int arr[100];
std::cout << std::time(0) << "\n";

for (int loop = 0; loop < 10000000; ++loop)
for (int i = 0; i < 100; ++i)
++arr[i];

std::cout << std::time(0) << "\n";
return 0;
}
Test different values for the condition in the outer loop until you get
something that takes some time to run. You'll probably don't want to use
too large arrays to loop over since caching effects can then come into play.

As Anand Hariharan said, there's really not much to be learned from
doing these low-level exercises since they won't tell you much about how
things will work in real applications, there's just too many factors
affecting the outcome, cache is only one.

--
Erik Wikström