473,889 Members | 1,656 Online

Programming Puzzle

I found these questions on a web site and wish to share with all of u
out there,Can SomeOne Solve these Porgramming puzzles.
Programming Puzzles

Some companies certainly ask for these things. Specially Microsoft.
Here are my favorite puzzles. Don't send me emails asking for the
solutions.

Q1 Write a "Hello World" program in 'C' without using a semicolon.
Q2 Write a C++ program without using any loop (if, for, while etc) to
print numbers from 1 to 100 and 100 to 1;
Q3 C/C++ : Exchange two numbers without using a temporary variable.
Q4 C/C++ : Find if the given number is a power of 2.
Q5 C/C++ : Multiply x by 7 without using multiplication (*) operator.
Q6 C/C++ : Write a function in different ways that will return f(7) =
4 and f(4) = 7
Q7 Remove duplicates in array
Q8 Finding if there is any loop inside linked list.
Q9 Remove duplicates in an no key access database without using an
array
Q10 Write a program whose printed output is an exact copy of the
source. Needless to say, merely echoing the actual source file is not
allowed.
Q11 From a 'pool' of numbers (four '1's, four '2's .... four '6's),
each player selects a number and adds it to the total. Once a number
is used, it must be removed from the pool. The winner is the person
whose number makes the total equal 31 exactly.
Q12 Swap two numbers without using a third variable.
Given an array (group) of numbers write all the possible sub groups of
this group.
Q14 Convert (integer) number in binary without loops.

Q3,12 are similar , Q7 is simple & I know there answer For the Rest
Nov 14 '05
271 20435
In <cb***********@ ulysses.noc.ntu a.gr> Ioannis Vranos <iv*@guesswh.at .grad.com> writes:
Dan Pop wrote:
Even under severe space concerns there is
always space for a *temporary* variable. If there are space concerns to
the extreme, then we should write numbers in its memory directly. :-)

Imagine that the universal swap function has the following interface:

void swap(void *p, void *q, size_t size);

What are you going to do if malloc(size) fails?

That is not much universal in my C++ world, since for non-POD types such
a generic function would invoke undefined behaviour.

Your C++ world is irrelevant once you cross-post to comp.lang.c.
For POD types, I would use a char/unsigned char array of fixed size (or
VLA in your world) or a char/unsigned char in the extreme, if malloc()
family failed.

You must be a first class idiot if you *rely* on being able to use
a VLA of the same size as a failed malloc request. And you have
no recovery strategy after the attempt to allocate it fails: your program
has already invoked undefined behaviour and has, probably, crashed and
burned. So, forget about VLAs. Using a *small*, statically allocated
buffer or a single unsigned char object are, however, valid alternatives.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #151

"Dan Pop" <Da*****@cern.c h> wrote in message
news:cb******** **@sunnews.cern .ch...
In <cb***********@ ulysses.noc.ntu a.gr> Ioannis Vranos <iv*@guesswh.at .grad.com> writes:
Dan Pop wrote:
Even under severe space concerns there is
always space for a *temporary* variable. If there are space concerns to
the extreme, then we should write numbers in its memory directly. :-)
Imagine that the universal swap function has the following interface:

void swap(void *p, void *q, size_t size);

What are you going to do if malloc(size) fails?
That is not much universal in my C++ world, since for non-POD types such
a generic function would invoke undefined behaviour.

Your C++ world is irrelevant once you cross-post to comp.lang.c.

Well, why the heck are you cross-posting to C++ if C++ is irrelevant?
For POD types, I would use a char/unsigned char array of fixed size (or
VLA in your world) or a char/unsigned char in the extreme, if malloc()
family failed.
You must be a first class idiot if you *rely* on being able to use

This is the second time in a row you're resorted to insults. Care to keep
the discussion llimited to the subject?
a VLA of the same size as a failed malloc request. And you have
no recovery strategy after the attempt to allocate it fails: your program
has already invoked undefined behaviour and has, probably, crashed and
burned. So, forget about VLAs. Using a *small*, statically allocated
buffer or a single unsigned char object are, however, valid alternatives.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Nov 14 '05 #152
Dan Pop wrote:
For POD types, I would use a char/unsigned char array of fixed size (or
VLA in your world) or a char/unsigned char in the extreme, if malloc()
family failed.

You must be a first class idiot if you *rely* on being able to use
a VLA of the same size as a failed malloc request.

For accuracy, I was talking about VLA with a small fixed size (instead
of a built in array), however VLAs are a mess so I would not use it
anyway (and also C99 is not one of my favourite standards).
And you have
no recovery strategy after the attempt to allocate it fails: your program
has already invoked undefined behaviour and has, probably, crashed and
burned. So, forget about VLAs. Using a *small*, statically allocated
buffer or a single unsigned char object are, however, valid alternatives.

Yes or single char ones.

Regards,

Ioannis Vranos
Nov 14 '05 #153
Risto Lankinen wrote:

"Julie" <ju***@nospam.c om> wrote in message
news:40******** *******@nospam. com...

Please describe a situation where two variables share the same memory
location.

There is a doubly-linked-list algorithm that uses the same
memory location for both forward and backward pointers.
They are stored as XORred, and given the address of an
anchor node, the chain of nodes can be traversed at either
direction.

- Risto -

Could you please post the relevant code that sets up two variables that share
the same memory location?

Thanks
Nov 14 '05 #154
In <OQ************ ********@bgtnsc 04-news.ops.worldn et.att.net> "Howard" <al*****@hotmai l.com> writes:

"Dan Pop" <Da*****@cern.c h> wrote in message
news:cb******* ***@sunnews.cer n.ch...
In <cb***********@ ulysses.noc.ntu a.gr> Ioannis Vranos

>Dan Pop wrote:
>
>>>Even under severe space concerns there is
>>>always space for a *temporary* variable. If there are space concerns to
>>>the extreme, then we should write numbers in its memory directly. :-)
>>
>>
>> Imagine that the universal swap function has the following interface:
>>
>> void swap(void *p, void *q, size_t size);
>>
>> What are you going to do if malloc(size) fails?
>
>That is not much universal in my C++ world, since for non-POD types such
>a generic function would invoke undefined behaviour.

Your C++ world is irrelevant once you cross-post to comp.lang.c.

Well, why the heck are you cross-posting to C++ if C++ is irrelevant?

For the simple reason that C and C++ have a common subset and it is
perfectly possible to talk about swapping in the context of this common
subset.

If the OP wanted a discussion including the C++ features outside this
common subset s/he wouldn't have cross-posted to c.l.c in the first place.

Or am I missing something?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #155
In <cb***********@ ulysses.noc.ntu a.gr> Ioannis Vranos <iv*@guesswh.at .grad.com> writes:
Dan Pop wrote:
For POD types, I would use a char/unsigned char array of fixed size (or
VLA in your world) or a char/unsigned char in the extreme, if malloc()
family failed.

You must be a first class idiot if you *rely* on being able to use
a VLA of the same size as a failed malloc request.

For accuracy, I was talking about VLA with a small fixed size (instead

What is a *variable* length array with a small *fixed* size? Looks like
an oxymoron to me...
of a built in array), however VLAs are a mess so I would not use it
anyway (and also C99 is not one of my favourite standards).

VLAs are far from being a mess. It's the availability of conforming C99
implementations that renders them useless for portable programming.
And you have
no recovery strategy after the attempt to allocate it fails: your program
has already invoked undefined behaviour and has, probably, crashed and
burned. So, forget about VLAs. Using a *small*, statically allocated
buffer or a single unsigned char object are, however, valid alternatives.

Yes or single char ones.

Nope, plain char is NOT exempt from trap representations . Furthermore,
even without trap representations , plain char can have padding bits and
a -0 may become a +0 when copied via a char on one's complement and
sign-magnitude implementations :

3 If the implementation supports negative zeros, they shall be
generated only by:

- the &, |, ^, ~, <<, and >> operators with arguments that
produce such a value;

- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;

- compound assignment operators based on the above cases.

It is unspecified whether these cases actually generate a
negative zero or a normal zero, and whether a negative zero
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
becomes a normal zero when stored in an object.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^

So, when thinking in terms of accessing value representations on a
byte by byte basis, the *one and only* type suitable for the job is
unsigned char: no padding bits, no trap representations , all values
from 0 to 2 ** CHAR_BIT - 1 represented in pure binary.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #156
Julie <ju***@nospam.c om> wrote in message news:<40******* ********@nospam .com>...
Gordon Burditt wrote:
> >Not one, but *two* ways to do it have been
> >shown in this thread. Of course it will break down if those variables
> >happen to share the same memory location, which can be the case if using
> >pointers and indirecting through them.

Please describe (in code) a situation where two variables share the same memory
location.

A union?

Nope -- a union is still a single variable, with just different ways to access
it.

I wish to understand why you think a union member is not one.
Nov 14 '05 #157
Dan Pop wrote:

What is a *variable* length array with a small *fixed* size? Looks like
an oxymoron to me...

C++'s std::vector for example is of variable length, however usage in
the style:
vector<int> somearray(5);

is too common.
Nope, plain char is NOT exempt from trap representations . Furthermore,
even without trap representations , plain char can have padding bits and
a -0 may become a +0 when copied via a char on one's complement and
sign-magnitude implementations :

I do not know/have understood what "trap representations " actually are,
however in C++98 it is guaranteed to be safe to read POD types as
sequences of chars and unsigned chars:
"For any complete POD object type T, whether or not the object holds a
valid value of type T, the underlying bytes (1.7) making up the object
can be copied into an array of char or unsigned char.36) If the content
of the array of char or unsigned char is copied back into the object,
the object shall subsequently hold its original value.

[Example:

#define N sizeof(T)
char buf[N];
T obj; // obj initialized to its original value
memcpy(buf, &obj, N); // between these two calls to memcpy,
// obj might be modified
memcpy(&obj, buf, N); // at this point, each subobject of obj of
// scalar type
// holds its original value
—end example]

For any POD type T, if two pointers to T point to distinct T objects
obj1 and obj2, if the value of obj1 is copied into obj2, using the
memcpy library function, obj2 shall subsequently hold the same value as
obj1.

[Example:
T* t1p;
T* t2p;
// provided that t2p points to an initialized object ...
memcpy(t1p, t2p, sizeof(T)); // at this point, every subobject of POD
//type in *t1p contains
// the same value as the corresponding subobject in *t2p
—end example]"

Regards,

Ioannis Vranos
Nov 14 '05 #158
Da*****@cern.ch (Dan Pop) wrote in message news:<cb******* ***@sunnews.cer n.ch>...
In <2k***********@ uni-berlin.de> "Alex Fraser" <me@privacy.net > writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:cb******* ****@sunnews.ce rn.ch...
Consider, for example, 0 ^ 0, whose result (an int with all bits set)

[...]

*cough*

Indeed! A first class brain fart...

Ah! Merci beaucoup. I have been trying to understand that.
Nov 14 '05 #159
Dingo wrote:

Julie <ju***@nospam.c om> wrote in message news:<40******* ********@nospam .com>...
Gordon Burditt wrote:

>> >Not one, but *two* ways to do it have been
>> >shown in this thread. Of course it will break down if those variables
>> >happen to share the same memory location, which can be the case if using
>> >pointers and indirecting through them.
>
>Please describe (in code) a situation where two variables share the same memory
>location.

A union?

Nope -- a union is still a single variable, with just different ways to access
it.

I wish to understand why you think a union member is not one.

I'll retract my statement -- I'll agree that a union does allow for two
variables to share the same memory address.
Nov 14 '05 #160

This thread has been closed and replies have been disabled. Please start a new discussion.