Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ Puzzle

Reply
Thread Tools

C++ Puzzle

 
 
James Kanze
Guest
Posts: n/a
 
      11-24-2008
On Nov 24, 9:09*pm, Jeff Schwab <(E-Mail Removed)> wrote:
> Sherm Pendley wrote:
> > Juha Nieminen <(E-Mail Removed)> writes:


> >> red floyd wrote:
> >>> extern "C" int printf(...);
> >>> int main()
> >>> {
> >>> * * printf("hello world\n");
> >>> }
> >> * Compiles and works at least with gcc, so it's good enough for me.


> > Agreed, except that I'd suggest this:


> > * * printf("%s", "hello world\n");


> puts("hello world");


> > Abusing the format string is not dangerous in this
> > particular example, but if it's a learning exercise it
> > should encourage good habits.


> This whole example would make a lousy learning exercise,
> anyway. *In particular, :rintf isn't guaranteed to exist
> (even though it sometimes "works").


That's a good point; it's only guaranteed to "exist" if you
include <stdio.h>, and it could be an inline function forwarding
to std:rintf (or some other function in the implementation's
namespace) there, and it isn't specified whether it is extern
"C" or not. Except that perhaps the Red wasn't trying to access
the printf in C++'s <stdio.h>, but the one in C; that one is
guaranteed to exist by the C standard.

> I don't know whether it's technically UB to open namespace std
> just wide enough to declare printf, but it probably ought to
> raise an eyebrow or two.


And that one too could be inline, forwarding to something else.
In which case, you run afoul of the requirement that if a
function is declared inline, it be declared inline in every
translation unit which uses it.

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Sherm Pendley
Guest
Posts: n/a
 
      11-24-2008
Jeff Schwab <(E-Mail Removed)> writes:

> Sherm Pendley wrote:
>
>> Abusing the format string is not dangerous in this particular example,
>> but if it's a learning exercise it should encourage good habits.

>
> This whole example would make a lousy learning exercise, anyway.


Yes, the whole thing seems rather contrived - of what practical use is
learning to output a string in C++ without #include <iostream> anyway?

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      11-24-2008
Sherm Pendley wrote:
> Yes, the whole thing seems rather contrived - of what practical use is
> learning to output a string in C++ without #include <iostream> anyway?


Nobody required for these puzzles to be actually useful.
 
Reply With Quote
 
Sherm Pendley
Guest
Posts: n/a
 
      11-25-2008
Juha Nieminen <(E-Mail Removed)> writes:

> Sherm Pendley wrote:
>> Yes, the whole thing seems rather contrived - of what practical use is
>> learning to output a string in C++ without #include <iostream> anyway?

>
> Nobody required for these puzzles to be actually useful.


Is that like a meta puzzle then, trying to figure out the real-world
relevance of the puzzle?

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      11-25-2008
Andrey Tarasevich wrote:
> Daniel T. wrote:
>>
>> I thought of it because several of our recent hires thought the member-
>> variables were destroyed in the opposite order in which they were
>> initialized in the constructor.
>>

>
> The funny part, of course, is that this is an _the_ _correct_ _answer_.
> Member subobjects are always constructed in the order of their
> declaration. And member subobjects are always destructed in the reverse
> order of their declaration. So yes, they are destroyed in the reverse
> order of their initialization.
>
> On top of that, as I said before, this all has absolutely noting to do
> with automatic variables...
>


Gotta love it when interviewers try to get too damn clever for their own
good. Such a detail shouldn't even really matter in production code
anyway. It's a trivia question.
 
Reply With Quote
 
Bill Davy
Guest
Posts: n/a
 
      11-25-2008

"Noah Roberts" <(E-Mail Removed)> wrote in message
news:ggh9uj$vei$(E-Mail Removed)...
> Andrey Tarasevich wrote:
>> Daniel T. wrote:
>>>
>>> I thought of it because several of our recent hires thought the member-
>>> variables were destroyed in the opposite order in which they were
>>> initialized in the constructor.
>>>

>>
>> The funny part, of course, is that this is an _the_ _correct_ _answer_.
>> Member subobjects are always constructed in the order of their
>> declaration. And member subobjects are always destructed in the reverse
>> order of their declaration. So yes, they are destroyed in the reverse
>> order of their initialization.
>>
>> On top of that, as I said before, this all has absolutely noting to do
>> with automatic variables...
>>

>
> Gotta love it when interviewers try to get too damn clever for their own
> good. Such a detail shouldn't even really matter in production code
> anyway. It's a trivia question.


I'm not sure it is trivia. People read the following and may be mislead:

Class::Class(void):
A(0), B(A+1)
{
}

PC-lint warns if variables are not initialised or are not initialised in the
order of declaration.


 
Reply With Quote
 
Triple-DES
Guest
Posts: n/a
 
      11-26-2008
On 25 Nov, 18:14, "Bill Davy" <(E-Mail Removed)> wrote:
> "Noah Roberts" <(E-Mail Removed)> wrote in message
> > Gotta love it when interviewers try to get too damn clever for their own
> > good. *Such a detail shouldn't even really matter in production code
> > anyway. *It's a trivia question.

>
> I'm not sure it is trivia. *People read the following and may be mislead:
>
> Class::Class(void):
> * * A(0), B(A+1)
> {
>
> }


or, for that matter:

Class::Class() :
B(A+1), A(0)
{
}

assuming
struct Class
{
Class();
private:
int A;
int B;
};

>
> PC-lint warns if variables are not initialised or are not initialised in the
> order of declaration.


So does gcc. Unfortunately, it also warns for classes.
 
Reply With Quote
 
Alan Woodland
Guest
Posts: n/a
 
      12-01-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) 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..


What does this output?

#include <iostream>
#include <string>

int main() {
const std::string msg = "Hello puzzled world!";
const std::string::size_type l = msg.length();
for (int i=0; i<l { // Is this what it seems ????/
std::cout << i++[msg.c_str()] << std::endl;
}

return 0;
}

Note: My compiler actually by default disables the thing that makes this
behave unexpectedly, and merely emits a warning that it is ignoring it.
Not sure if that's non-conforming behaviour or not?

Alan
 
Reply With Quote
 
Alan Woodland
Guest
Posts: n/a
 
      12-01-2008
Pete Becker wrote:
>> #include <iostream>
>> #include <string>
>>
>> int main() {
>> const std::string msg = "Hello puzzled world!";
>> const std::string::size_type l = msg.length();
>> for (int i=0; i<l { // Is this what it seems ????/
>> std::cout << i++[msg.c_str()] << std::endl;
>> }
>>
>> return 0;
>> }
>>
>> Note: My compiler actually by default disables the thing that makes this
>> behave unexpectedly, and merely emits a warning that it is ignoring it.
>> Not sure if that's non-conforming behaviour or not?
>>

>
> The meaning of a[b] is defined as *(a+b). If the latter is valid, a
> compiler that complains about the former is enforcing style guidelines,
> not language requirements.


The a[b] wasn't what my compiler was complaining about here, it was a
distraction from the real problem!

When I tried it with g++ -trigraphs (and on another much older compiler
which doesn't disable trigraphs by default) it results in an infinite
loop! The comment on the line where the for-loop starts includes the
sequence ??/ which is actually a trigraph representation of \, meaning
the next line is a continuation of the previous one, and thus part of
the comment still, so there is nothing in the loop body!

Alan
 
Reply With Quote
 
Triple-DES
Guest
Posts: n/a
 
      12-02-2008
On 1 Des, 14:01, Alan Woodland <(E-Mail Removed)> wrote:

> The a[b] wasn't what my compiler was complaining about here, it was a
> distraction from the real problem!
>
> When I tried it with g++ -trigraphs (and on another much older compiler
> which doesn't disable trigraphs by default) it results in an infinite
> loop! The comment on the line where the for-loop starts includes the
> sequence ??/ which is actually a trigraph representation of \, meaning
> the next line is a continuation of the previous one, and thus part of
> the comment still, so there is nothing in the loop body!


Nice red herring
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the extra bar along top in v1.5 with puzzle image? Can we get rid of? S.Rodgers Firefox 9 12-14-2005 11:15 AM
Home networking puzzle?!? =?Utf-8?B?Qm9ya28=?= Wireless Networking 3 01-25-2005 06:49 AM
A NS puzzle:) Brad Snow Firefox 6 09-03-2004 04:54 AM
A puzzle to puzzle you sk A+ Certification 1 07-17-2004 05:19 PM
PUZZLE Getting DropDownList Index of Matching Value Earl Teigrob ASP .Net 3 08-06-2003 09:41 PM



Advertisments