«

Can we have Puzzle thread here?? If any one has a interesting C++
question which helps to understand c++ better or makes interview
easier to face can post here..

On Nov 22, 6:25*am, "doublemaster...@gmail.com"
<doublemaster...@gmail.com> wrote:
> Can we have Puzzle thread here?? If any one has a interesting C++
> question which helps to understand c++ better or makes interview
> easier to face can post here..

I suspect that most of the people here know the answer to this puzzle,
but I'm continually surprised at how many professional programmers
that I meet don't:

(I've turned a basic fact about C++ into a puzzle question below... I
know the answer.

In C++ a basic rule is that the compiler destroys auto variables in
the opposite order from which they were constructed. Given this, when
a destructor is called, how does the system know in what order to
destroy the member-variables?

Daniel T. wrote:
>
> (I've turned a basic fact about C++ into a puzzle question below... I
> know the answer.
>
> In C++ a basic rule is that the compiler destroys auto variables in
> the opposite order from which they were constructed. Given this, when
> a destructor is called, how does the system know in what order to
> destroy the member-variables?
>

While the answer to the above question is indeed just a basic fact about
C++ (not really a puzzle), I still don't understand what does it have to
do with automatic variables and why you even mention them there.

--
Best regards,
Andrey Tarasevich

wrote:
> Can we have Puzzle thread here?? If any one has a interesting C++
> question which helps to understand c++ better or makes interview
> easier to face can post here..

This is not a question which really helps understanding C++ better nor
is a good job interview question (well, not unless you are applying for
a job which involves writing a compiler), but I think it's interesting
nevertheless:

C++ is very hard to parse because its syntax is not a so-called
context-free grammar. Give an example (one full sentence, ie. a full
expression ending in a semi-colon) of valid code which cannot be
unambiguously tokenized properly without knowing the environment in
which the line of code appears (ie. everything else in the same
compilation unit). In other words, it would be possible to tokenize the
sentence in at least two completely different ways, and both ways could
be valid C++ code (if in the proper environment).

(Note that tokenizing a sentence doesn't require understanding the
semantics of the expression, ie. it's not necessary to know eg. if some
type name has been declared earlier or not. Tokenizing simply means that
the sentence is divided into its constituent tokens, each token having a
well-defined type, eg. "identifier", "unary operator", "binary
operator", "opening parenthesis", etc.)

(And btw, googling is cheating. )

class Base
{
public:
Base() {}
virtual void func() { /* do something */ }
};

class Derived : public Base
{
public:
Derived() {}
virtual void func()
{
Base:func();
/* do something else */
}
};

int main()
{
Derived d;
d.func(); // Never returns!
}

For each new puzzle..pls change the subject..

On Nov 23, 10:34*am, "doublemaster...@gmail.com"
<doublemaster...@gmail.com> wrote:
> For each new puzzle..pls change the subject..

Ans:Base:func(); (only single colon) causes the infinet loop. since
single colon acts as label . hence derived func will be called

On Nov 23, 12:33*am, "doublemaster...@gmail.com"
<doublemaster...@gmail.com> wrote:
> class Base
> {
> public:
> * Base() {}
> * virtual void func() { /* do something */ }
>
> };
>
> class Derived : public Base
> {
> public:
> * Derived() {}
> * virtual void func()
> * {
> * * Base:func();
> * * /* do something else */
> * }
>
> };
>
> int main()
> {
> * Derived d;
> * d.func(); *// Never returns!
>
> }
>
>

Yes it does. It's syntactically incorrect (moreso, hard to understand)
as to why you'd have virtual function within the base class, when the
base class has the same name. The compiler (bad one) would not know
what to do since both are virtual, and both contain the same name
along with method parameters.

However, it does return. And it exists successfully.

Program execution is as follows.

Derived Constructor is called, return to last calling point : Main
Call constructed class, d. Jumps into class Derived : Name is the same
as base class
Goes into the called method within Derived.
Calls Base class
Returns to last calling point : Derived class
Returns to last calling point : Main
Exit

On Nov 22, 8:58*pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> doublemaster...@gmail.com wrote:
> > Can we have Puzzle thread here?? If any one has a
> > interesting C++ question which helps to understand c++
> > better or makes interview easier to face can post here..

> This is not a question which really helps understanding C++
> better nor is a good job interview question (well, not unless
> you are applying for a job which involves writing a compiler),
> but I think it's interesting nevertheless:

> C++ is very hard to parse because its syntax is not a
> so-called context-free grammar. Give an example (one full
> sentence, ie. a full expression ending in a semi-colon) of
> valid code which cannot be unambiguously tokenized properly
> without knowing the environment in which the line of code
> appears (ie. everything else in the same compilation unit). In
> other words, it would be possible to tokenize the sentence in
> at least two completely different ways, and both ways could be
> valid C++ code (if in the proper environment).

> (Note that tokenizing a sentence doesn't require understanding
> the semantics of the expression, ie. it's not necessary to
> know eg. if some type name has been declared earlier or not.
> Tokenizing simply means that the sentence is divided into its
> constituent tokens, each token having a well-defined type, eg.
> "identifier", "unary operator", "binary operator", "opening
> parenthesis", etc.)

The problem with that is that the question is ambiguous: what do
you mean by a token? (As for your "well-defined type", that's a
meaningless statement until you know how the compiler internals
are implemented.)

Formally, C++ defines tokens so that you can always "tokenize"
with at most one character look-ahead (is the next character
part of this token, or not), and no context. Practically,
internally, it's impossible to parse C++ if you don't separate
symbols into names of types, names of templates, and other, and
I imagine that most compilers treat these as separate tokens.
Similarly, it's probably advantageous to distinguish between the
> which closes a template and the > which is the operator less
than; with the new standard, I suspect that the simplest
implementation would also distinguish between a >> which closes
two templates (which is formally a single token which is then
remapped to two---but if you know that the context would allow
the remapping, you could do it immediately in the tokenizing
phase) and the right shift operator.

So formally, there aren't any, but internally, there could be,
and in fact, probably are. (In practice, I would be very
surprised if there were any compilers which didn't use context
to return different token types for type names, template names
and other symbols; as long as >> cannot be used to close two
templates, I expect that that's the only case in most compilers,
so presumably, that's what you were looking for.)

--
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

On Nov 23, 6:42*am, onLINES <dopeli...@gmail.com> wrote:
> On Nov 23, 12:33*am, "doublemaster...@gmail.com"
> <doublemaster...@gmail.com> wrote:
> > class Base
> > {
> > public:
> > * Base() {}
> > * virtual void func() { /* do something */ }
> > };

> > class Derived : public Base
> > {
> > public:
> > * Derived() {}
> > * virtual void func()
> > * {
> > * * Base:func();
> > * * /* do something else */
> > * }
> > };

> > int main()
> > {
> > * Derived d;
> > * d.func(); *// Never returns!
> > }

> Yes it does.

No it doesn't. It terminates with stack overflow (formally,
undefined behavior, but a core dump or the equivalent on most
general purpose machines).

> It's syntactically incorrect (moreso, hard to understand) as
> to why you'd have virtual function within the base class, when
> the base class has the same name.

I'm having problems parsing that statement. The base class has
the same name as what? But the program is definitely
syntactically correct.

> The compiler (bad one) would not know what to do since both
> are virtual, and both contain the same name along with method
> parameters.

If you're talking about the function func() (which I suppose
because that's the only thing which has two declarations), his
code is a perfectly classical example of how to implement a
polymorphic class in C++. He defines a virtual function in the
base class, and overrides it in the derived class.

> However, it does return. And it exists successfully.

Did you actually try it? (A good compiler will warn about an
unreferenced label, but the language itself doesn't require
labels to be referenced.)

> Program execution is as follows.

> Derived Constructor is called, return to last calling point :

Somewhere before the body of the constructor of Derived is
entered, the constructor of Base will have been called. But in
the end, yes, the object gets constructed, and we return in
sequence.

> Main
> Call constructed class, d.

You call a function, not a class. Next, we call Derived::func.

> Jumps into class Derived : Name is the same as base class

> Goes into the called method within Derived.
> Calls Base class

Where does it do that? His code never calls Base::func.
Derived::func calls itself recursively. (Note that for
Derived::func to call Base::func, he would have to have written
Base::func, and not Base:func.)

--
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