4) Sometimes garbage? That''s what happens when you write code that relies on undefined behavior
I actually don''t fully understand this one. I am guessing that there is no guarantee as to whether a or b gets initialized first. Can someone enlighten me?
Programming test
quote:Original post by Anonymous Poster
QUOTE: I wonder. I got 40000 on both GCC 3.2 and Visual C++ 7.0
Yeah... after looking at the problem, I''m still not certain what the problem is. The only two points of consideration are the ternary operator, and the type sizes (as someone else mentioned).
But the type sizes are easily ruled out. First of all, the type signature of the inline Max call returns int, not a short, so that coincides with the %d. Also, when variables are passed to functions in a .../vararg construct (like printf), they are promoted up... chars, shorts, and ints are promoted to longs, and floats are promoted to doubles.
I would guess it''s the ternary operator. I think that parentheses are needed around the comparison. But, I think they''re only needed for C, not C++
It''s 16 bit overflow (if it was 8, it''d return 64) - the words are unsigned, yet the max comparison is done using a signed int. The overflow makes the 40000 negative for the comparison, so it returns 0. It will compile unless warnings are treated as errors. Try it with max(short, short) and typedef unsigned short Word;
Standard only guarantees sizeof(char)==1, sizeof(short) <= sizeof(int) <= sizeof(long)
quote:Original post by sQuid
4) Sometimes garbage? That's what happens when you write code that relies on undefined behavior
I actually don't fully understand this one. I am guessing that there is no guarantee as to whether a or b gets initialized first. Can someone enlighten me?
You are correct, the order of initialization of extern's is not guaranteed across translation units. However, we would expect the same results using the same compiler, with the same file compilation order.
[edited by - Magmai Kai Holmlor on August 19, 2003 1:11:51 AM]
@Magmai... :
>>Standard only guarantees sizeof(char)==1, sizeof(short) <=
>>sizeof(int) <= sizeof(long)
isn''t the last part wrong ?
sizeof(int) <= sizeof(long) - an integer is always as broad as the machine''s widest registers you are working on, but a long is always 32bit''s; on IA32 a sizeof(int) is 4 but on IA64 a sizeof(int) is 8.
or am i wrong ??
DJSnow
-----
this post is manually created and therefore legally valid without a signature
>>Standard only guarantees sizeof(char)==1, sizeof(short) <=
>>sizeof(int) <= sizeof(long)
isn''t the last part wrong ?
sizeof(int) <= sizeof(long) - an integer is always as broad as the machine''s widest registers you are working on, but a long is always 32bit''s; on IA32 a sizeof(int) is 4 but on IA64 a sizeof(int) is 8.
or am i wrong ??
DJSnow
-----
this post is manually created and therefore legally valid without a signature
quote:Original post by ApochPiQ
Func1 is not the problem. Put Func1 by itself in a loop and run it; you''ll get 0, 1, 2, 3 ... etc. Not a very clear way of incrementing a variable, but it works.
The real problem is that in Func2() the static variable is initialized to Func1(). Of course, when the initialization happens, Func2::n becomes 0. Then it is static, so it stays at 0. Func2() never modifies Func2::n, and Func1() is never called again, so Func2::n remains 0. Whenever Func2() is called, it returns Func2::n + 1, or 1.
For railing on Chuk so much, it sure took you guys a long time to get the right answer
i don''t get it.
if func1() == 1 and it''s assigned to static int n in func2() then why doesn''t it initialize to 1? shouldn''t it print 2 all the time?
It returns the value of n1 (before ++) when the return is called. n2 gets the value of n before the ++. After n2''s initialisation, n1 increments after this initialisation, and then func1() is never called again.
My way of passing this test: "Holy shit, if you guys code like this, I don''t want to work here."
My way of passing this test: "Holy shit, if you guys code like this, I don''t want to work here."
I think you could possibly spend enough time arguing about the crappy design of the code, the horrid implementation, and argue about the sheer lack of standard in this code that you would never have to answer the questions themselves. So even if you don''t know, I bet you could get by this test 
quote:Original post by DJSnow
@Magmai... :
>>Standard only guarantees sizeof(char)==1, sizeof(short) <=
>>sizeof(int) <= sizeof(long)
isn''t the last part wrong ?
sizeof(int) <= sizeof(long) - an integer is always as broad as the machine''s widest registers you are working on, but a long is always 32bit''s; on IA32 a sizeof(int) is 4 but on IA64 a sizeof(int) is 8.
or am i wrong ??
You''re at least as right as I am
The actual guarantees are overly complicated - int is at least 16bits, long is at least 32bits, long long is required to have at least 64bits, and char is sizeof==1 and at least 8bits. The required ranges allow for sign-magnitude machines, so the required range for an int is -32767 to 32767 (not -32768 as an x86 junkie might expect). It''s possible to have a standard 64bit implementation in which the sizeof(long) be greater than, less than, or equal to the sizeof(int).
By convention, int is the ''natural'' size that the processor can work with most efficently, int is at least as big as a short, and long is at least as big as an int.
Magmai most of your post are sane and I hold you in very high regard but you just contradicted yourself.
now first you say that:
//possible
sizeof(int) > sizeof(long)
and then you state that:
sizeof(long) >= sizeof(int)
could you please explain the math?
quote:
... sizeof(long) be greater than, less than, or equal to the sizeof(int).
quote:
... int is at least as big as a short, and long is at least as big as an int.
now first you say that:
//possible
sizeof(int) > sizeof(long)
and then you state that:
sizeof(long) >= sizeof(int)
could you please explain the math?
quote:Original post by DigitalDelusion
Magmai most of your post are sane and I hold you in very high regard but you just contradicted yourself.
You discarded the qualifiers "possible" and "convention". It''s *possible* to implement a long so that sizeof(long) is either less than, equal to, or greater than sizeof(int). However by *convention* it''s usually sizeof(long) >= sizeof(int)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
