Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121438 > unrolled thread

How good is your C++ knowledge?

Back to article view | Back to comp.lang.c++

Contents

  How good is your C++ knowledge? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 09:31 -0800
    Re: How good is your C++ knowledge? David Brown <david.brown@hesbynett.no> - 2025-01-14 20:25 +0100
      Re: How good is your C++ knowledge? Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-14 15:11 -0500
    Re: How good is your C++ knowledge? Phillip <nntp@fulltermprivacy.com> - 2025-01-14 15:57 -0500
    Re: How good is your C++ knowledge? Lynn McGuire <lynnmcguire5@gmail.com> - 2025-01-15 00:13 -0600
      Re: How good is your C++ knowledge? Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-15 17:51 +0200
        Re: How good is your C++ knowledge? Muttley@DastardlyHQ.org - 2025-01-15 16:37 +0000
      Re: How good is your C++ knowledge? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-18 07:55 -0800
      Re: How good is your C++ knowledge? Vir Campestris <vir.campestris@invalid.invalid> - 2025-01-22 11:23 +0000
        Re: How good is your C++ knowledge? Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-22 16:30 +0200
    Re: How good is your C++ knowledge? Rosario19 <Ros@invalid.invalid> - 2025-01-20 13:17 +0100
      Re: How good is your C++ knowledge? Muttley@DastardlyHQ.org - 2025-01-20 16:12 +0000
    Re: How good is your C++ knowledge? Andrey Tarasevich <noone@noone.net> - 2025-02-08 21:22 -0800
      Re: How good is your C++ knowledge? James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-02-09 16:17 -0500
        Re: How good is your C++ knowledge? Muffley@PillowHQ.org - 2025-02-10 08:26 +0000
          Re: How good is your C++ knowledge? David Brown <david.brown@hesbynett.no> - 2025-02-10 10:46 +0100
            Re: How good is your C++ knowledge? Muffley@PillowHQ.org - 2025-02-10 10:00 +0000
              Re: How good is your C++ knowledge? Paavo Helde <eesnimi@osa.pri.ee> - 2025-02-10 15:52 +0200
                Re: How good is your C++ knowledge? Muffley@PillowHQ.org - 2025-02-10 14:56 +0000
                  Re: How good is your C++ knowledge? Paavo Helde <eesnimi@osa.pri.ee> - 2025-02-10 17:18 +0200
                    Re: How good is your C++ knowledge? Muffley@PillowHQ.org - 2025-02-10 15:53 +0000

Page 1 of 2  [1] 2  Next page →

#121438 — How good is your C++ knowledge?

Check this out -- https://cppquiz.org

(My own results on the handful of questions I tried
were less than stellar.)

[toc] | [next] | [standalone]

#121442

On 14/01/2025 18:31, Tim Rentsch wrote:
> Check this out -- https://cppquiz.org
> 
> (My own results on the handful of questions I tried
> were less than stellar.)

177 questions?  That's a /lot/ of questions to wade through.  Could you 
tell us at least if you think some of the questions are interesting, 
rather than either quite basic or quite unrealistic?

[toc] | [prev] | [next] | [standalone]

#121443

David Brown wrote this post while blinking in Morse code:

> On 14/01/2025 18:31, Tim Rentsch wrote:
>> Check this out -- https://cppquiz.org
>> 
>> (My own results on the handful of questions I tried
>> were less than stellar.)
>
> 177 questions?  That's a /lot/ of questions to wade through.  Could you 
> tell us at least if you think some of the questions are interesting, 
> rather than either quite basic or quite unrealistic?

The very first one was some printf() calls that would cause a compilation
error.  The answer box was a tiny thing, making one things that there would be
/some/ output.

That one seemed like a C question, really.

-- 
Contains no artificial colors or ingredients.

[toc] | [prev] | [next] | [standalone]

#121444

On 1/14/25 12:31 PM, Tim Rentsch wrote:
> Check this out -- https://cppquiz.org
> 
> (My own results on the handful of questions I tried
> were less than stellar.)

Believe it or not I've seen a lot of businesses that use this web site 
(or others like it) as part of their interview process. So it's a pretty 
big deal sometimes.

-- 
Phillip
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

[toc] | [prev] | [next] | [standalone]

#121445

On 1/14/2025 11:31 AM, Tim Rentsch wrote:
> Check this out -- https://cppquiz.org
> 
> (My own results on the handful of questions I tried
> were less than stellar.)

I got the first question on the first try.  I got the second question on 
the third try.  I bounced on the third question.

These are not trivial questions.  There are serious logic questions in 
there.

Lynn

[toc] | [prev] | [next] | [standalone]

#121446

On 15.01.2025 08:13, Lynn McGuire wrote:
> On 1/14/2025 11:31 AM, Tim Rentsch wrote:
>> Check this out -- https://cppquiz.org
>>
>> (My own results on the handful of questions I tried
>> were less than stellar.)
> 
> I got the first question on the first try.  I got the second question on 
> the third try.  I bounced on the third question.
> 
> These are not trivial questions.  There are serious logic questions in 
> there.

Indeed. Almost each question has some gotcha included.

Not sure how much this would help for interviewing newcomers, 
willingness to learn and ability to get things done would be far more 
important than knowledge of obscure C++ gotchas.

[toc] | [prev] | [next] | [standalone]

#121447

On Wed, 15 Jan 2025 17:51:00 +0200
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>On 15.01.2025 08:13, Lynn McGuire wrote:
>> On 1/14/2025 11:31 AM, Tim Rentsch wrote:
>>> Check this out -- https://cppquiz.org
>>>
>>> (My own results on the handful of questions I tried
>>> were less than stellar.)
>> 
>> I got the first question on the first try.  I got the second question on 
>> the third try.  I bounced on the third question.
>> 
>> These are not trivial questions.  There are serious logic questions in 
>> there.
>
>Indeed. Almost each question has some gotcha included.
>
>Not sure how much this would help for interviewing newcomers, 
>willingness to learn and ability to get things done would be far more 
>important than knowledge of obscure C++ gotchas.

Unfortunately "spot whats wrong with this code" or "what will this code do"
have long been staples of interviews, at least here in the UK almost
invariably involving IME convoluted multiple inheritence. Its a lot easier
for lazy interviewers to just go through a checklist of answers than
ask someone to write some code and have to figure out what they did. Unless
you solely want to hire people to bug fix wierd edge cases then its far more 
useful IMO to see how they problem solve and what sort of code they write.

[toc] | [prev] | [next] | [standalone]

#121452

Lynn McGuire <lynnmcguire5@gmail.com> writes:

> On 1/14/2025 11:31 AM, Tim Rentsch wrote:
>
>> Check this out -- https://cppquiz.org
>>
>> (My own results on the handful of questions I tried
>> were less than stellar.)
>
> I got the first question on the first try.  I got the second question
> on the third try.  I bounced on the third question.
>
> These are not trivial questions.  There are serious logic questions in
> there.

The level of difficulty covers a big range.  I don't know that any
of the questions are completely trivial;  they all seem to have at
least some little twist to them.  But some are completely out of the
park, as far as my own C++ knowledge goes.  On the plus side, I did
learn some things in trying some of the mid-range questions.

[toc] | [prev] | [next] | [standalone]

#121460

On 15/01/2025 06:13, Lynn McGuire wrote:
> 
> I got the first question on the first try.  I got the second question on 
> the third try.  I bounced on the third question.
> 
> These are not trivial questions.  There are serious logic questions in 
> there.

The second question I got was to compare typeid(x)==typeid(y). I worked 
out whether they matched correctly. But it wrote the answer using stream 
IO to cout, and I assumed that when you write a bool it would write true 
or false. I gave up in the end, and asked for the answer. Which was 
either 0 or 1 (I won't say which in case someone else wants to do the 
question).

So all my knowledge of the language and the way classes work was as 
nothing given that I almost never use stream IO for anything other than 
play programs. (OTOH I'm retired now, and only write play programs...)

I suspect a real person scoring it would have realised my error!

Andy

[toc] | [prev] | [next] | [standalone]

#121461

On 22.01.2025 13:23, Vir Campestris wrote:
> On 15/01/2025 06:13, Lynn McGuire wrote:
>>
>> I got the first question on the first try.  I got the second question 
>> on the third try.  I bounced on the third question.
>>
>> These are not trivial questions.  There are serious logic questions in 
>> there.
> 
> The second question I got was to compare typeid(x)==typeid(y). I worked 
> out whether they matched correctly. But it wrote the answer using stream 
> IO to cout, and I assumed that when you write a bool it would write true 
> or false. I gave up in the end, and asked for the answer. Which was 
> either 0 or 1 (I won't say which in case someone else wants to do the 
> question).

Right. It appears this behavior can be modified via the std::boolalpha 
and std::noboolalpha manipulators.

And the printed names can be changed from 'true' and 'false' to 
something else by defining a custom locale and overriding do_truename() 
and do_falsename() virtual functions.

Considering that C++ is meant for creating programs for all people, not 
just English speakers, and thus the names can be redefined, outputting 
'0' and '1' by default actually makes some sense.

Anyway, I guess this all this just proves there is no lack of material 
for adding yet more obscure C++ questions to that quiz ;-)

[toc] | [prev] | [next] | [standalone]

#121458

On Tue, 14 Jan 2025 09:31:45 -0800, Tim Rentsch wrote:

>Check this out -- https://cppquiz.org
>

one big subset of C++: the art for make difficult what is always been
easy 

[toc] | [prev] | [next] | [standalone]

#121459

On Mon, 20 Jan 2025 13:17:19 +0100
Rosario19 <Ros@invalid.invalid> wibbled:
>On Tue, 14 Jan 2025 09:31:45 -0800, Tim Rentsch wrote:
>
>>Check this out -- https://cppquiz.org
>>
>
>one big subset of C++: the art for make difficult what is always been
>easy 

I hate these types of tests. They don't prove anything other than if you
give enough plausible answers you can confuse people. The kind of tests where
people are asked to write some code to do a specific task is a far better
measure of someones capability that spotting stupid syntax errors that would
be caught during compilation anyway and semantic errors that would be evident
on the first run.

[toc] | [prev] | [next] | [standalone]

#121533

On Tue 1/14/2025 9:31 AM, Tim Rentsch wrote:
> Check this out -- https://cppquiz.org

I came across a rather interesting question.

Remember back in the day we had that issue with a pair of `>>` being 
interpreted as a single token? So, when closing multiple levels of 
nested triangular brackets we had to separate them by spaces `> >`. 
Eventually this issue has been resolved at grammatical level, and there 
was no need to be concerned about it anymore.

In modern C++ (apparently, since C++11) we now have another issue of 
somewhat similar structure: a pair of consecutive `[` brackets. In 
"classic" C++ we had no contexts in which consecutive `[` brackets would 
legally appear. But now have at least two such contexts: one is using a 
lambda to access an array element

   int a[10]{};
   int x = a[[]{ return 0; }()];

Another is attributes (which grammatically begin with two `[`). Two 
consecutive `[` are required to begin an attribute, meaning that the 
above code sample is ill-formed.

What came as a bit of surprise to me is that inserting an extra space 
between the `[` apparently does not resolve the situation. I.e. this variant

   int x = a[  []{ return 0; }()  ];

is still ill-formed.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#121543

On 2/9/25 00:22, Andrey Tarasevich wrote:
...
> Remember back in the day we had that issue with a pair of `>>` being 
> interpreted as a single token? So, when closing multiple levels of 
> nested triangular brackets we had to separate them by spaces `> >`. 
> Eventually this issue has been resolved at grammatical level, and there 
> was no need to be concerned about it anymore.

They didn't correct that by changing the grammar. They simply added a
rule that
"When parsing a template-argument-list, ... the first non-nested >> is
treated as two consecutive but distinct > tokens, the first of which is
taken as the end of the template-argument-list and completes the
template-id." (13.3p4).

...
> Another is attributes (which grammatically begin with two `[`). Two 
> consecutive `[` are required to begin an attribute, meaning that the 
> above code sample is ill-formed.
> 
> What came as a bit of surprise to me is that inserting an extra space 
> between the `[` apparently does not resolve the situation. I.e. this variant
> 
>    int x = a[  []{ return 0; }()  ];
> 
> is still ill-formed.

That's because, as you your self mention, the attribute syntax
"grammatically begin with two '['". Since those are two separate tokens,
(unlike ">>", which is a single token) they can be separated by an
arbitrarily long string of white-space characters which get removed
during translation phase 7.

[toc] | [prev] | [next] | [standalone]

#121552

On Sun, 9 Feb 2025 16:17:13 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
>On 2/9/25 00:22, Andrey Tarasevich wrote:
>....
>> Remember back in the day we had that issue with a pair of `>>` being 
>> interpreted as a single token? So, when closing multiple levels of 
>> nested triangular brackets we had to separate them by spaces `> >`. 
>> Eventually this issue has been resolved at grammatical level, and there 
>> was no need to be concerned about it anymore.
>
>They didn't correct that by changing the grammar. They simply added a
>rule that
>"When parsing a template-argument-list, ... the first non-nested >> is
>treated as two consecutive but distinct > tokens, the first of which is
>taken as the end of the template-argument-list and completes the
>template-id." (13.3p4).

Which is another nice example of how the C++ syntax was never really thought
through properly but is just one hack on top of another.

[toc] | [prev] | [next] | [standalone]

#121556

On 10/02/2025 09:26, Muffley@PillowHQ.org wrote:
> On Sun, 9 Feb 2025 16:17:13 -0500
> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
>> On 2/9/25 00:22, Andrey Tarasevich wrote:
>> ....
>>> Remember back in the day we had that issue with a pair of `>>` being
>>> interpreted as a single token? So, when closing multiple levels of
>>> nested triangular brackets we had to separate them by spaces `> >`.
>>> Eventually this issue has been resolved at grammatical level, and there
>>> was no need to be concerned about it anymore.
>>
>> They didn't correct that by changing the grammar. They simply added a
>> rule that
>> "When parsing a template-argument-list, ... the first non-nested >> is
>> treated as two consecutive but distinct > tokens, the first of which is
>> taken as the end of the template-argument-list and completes the
>> template-id." (13.3p4).
> 
> Which is another nice example of how the C++ syntax was never really thought
> through properly but is just one hack on top of another.
> 

It /was/ thought through properly when C++ was new.  But the language 
has had a great deal of new features since it first started seeing 
real-world usage, and all new features have to fit compatibility with 
existing code.  That applies to all languages that see significant 
development over time.

Of course if you wanted to make a /new/ language with most of the 
features C++ currently has, you'd have a grammar that differed 
significantly from C++ and which did not suffer from these kinds of 
issues.  That's what projects like "Cpp2" are hoping to achieve.  (And 
if they catch on, they'll suffer from the same problem a few decades 
down the line.)

[toc] | [prev] | [next] | [standalone]

#121557

On Mon, 10 Feb 2025 10:46:17 +0100
David Brown <david.brown@hesbynett.no> wibbled:
>On 10/02/2025 09:26, Muffley@PillowHQ.org wrote:
>> On Sun, 9 Feb 2025 16:17:13 -0500
>> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
>>> On 2/9/25 00:22, Andrey Tarasevich wrote:
>>> ....
>>>> Remember back in the day we had that issue with a pair of `>>` being
>>>> interpreted as a single token? So, when closing multiple levels of
>>>> nested triangular brackets we had to separate them by spaces `> >`.
>>>> Eventually this issue has been resolved at grammatical level, and there
>>>> was no need to be concerned about it anymore.
>>>
>>> They didn't correct that by changing the grammar. They simply added a
>>> rule that
>>> "When parsing a template-argument-list, ... the first non-nested >> is
>>> treated as two consecutive but distinct > tokens, the first of which is
>>> taken as the end of the template-argument-list and completes the
>>> template-id." (13.3p4).
>> 
>> Which is another nice example of how the C++ syntax was never really thought
>> through properly but is just one hack on top of another.
>> 
>
>It /was/ thought through properly when C++ was new.  But the language 

I'm not aware of what was in the language when it was still C-with-classes,
but operator overloading AFAIK is, if not an original feature then certainly
a very old one, and the postfix syntax is a fugly hack.

[toc] | [prev] | [next] | [standalone]

#121562

On 10.02.2025 12:00, Muffley@PillowHQ.org wrote:
> On Mon, 10 Feb 2025 10:46:17 +0100
> David Brown <david.brown@hesbynett.no> wibbled:
>> On 10/02/2025 09:26, Muffley@PillowHQ.org wrote:
>>> On Sun, 9 Feb 2025 16:17:13 -0500
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
>>>> On 2/9/25 00:22, Andrey Tarasevich wrote:
>>>> ....
>>>>> Remember back in the day we had that issue with a pair of `>>` being
>>>>> interpreted as a single token? So, when closing multiple levels of
>>>>> nested triangular brackets we had to separate them by spaces `> >`.
>>>>> Eventually this issue has been resolved at grammatical level, and there
>>>>> was no need to be concerned about it anymore.
>>>>
>>>> They didn't correct that by changing the grammar. They simply added a
>>>> rule that
>>>> "When parsing a template-argument-list, ... the first non-nested >> is
>>>> treated as two consecutive but distinct > tokens, the first of which is
>>>> taken as the end of the template-argument-list and completes the
>>>> template-id." (13.3p4).
>>>
>>> Which is another nice example of how the C++ syntax was never really thought
>>> through properly but is just one hack on top of another.
>>>
>>
>> It /was/ thought through properly when C++ was new.  But the language
> 
> I'm not aware of what was in the language when it was still C-with-classes,
> but operator overloading AFAIK is, if not an original feature then certainly
> a very old one, and the postfix syntax is a fugly hack.

Operator overloading predates C++ and is already present in C. In C, the 
expression `x >> 1` works both for unsigned int, unsigned long, and 
unsigned long long, and produces different opcodes and different result 
types for them. That's clear overloading.

Parsing of characters `>>` is done by the C or C++ lexer. The C lexer 
needs to look ahead (though one character only) for deciding how to 
interpret the first '>'. The C++ lexer needs to look backwards for 
deciding how to interpret the second '>'. Not so different IMO.

[toc] | [prev] | [next] | [standalone]

#121563

On Mon, 10 Feb 2025 15:52:28 +0200
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>On 10.02.2025 12:00, Muffley@PillowHQ.org wrote:
>> I'm not aware of what was in the language when it was still C-with-classes,
>> but operator overloading AFAIK is, if not an original feature then certainly
>> a very old one, and the postfix syntax is a fugly hack.
>
>Operator overloading predates C++ and is already present in C. In C, the 
>expression `x >> 1` works both for unsigned int, unsigned long, and 
>unsigned long long, and produces different opcodes and different result 
>types for them. That's clear overloading.

Don't be willfully dumb, you know what I mean. Eg:

myclass &operator++ (int)
{
:
}

The 'int' is a ridiculous hack to signify postfix. There are far neater ways
it could have been done, eg a post_operator keyword or something similar.

[toc] | [prev] | [next] | [standalone]

#121565

On 10.02.2025 16:56, Muffley@PillowHQ.org wrote:
> On Mon, 10 Feb 2025 15:52:28 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>> On 10.02.2025 12:00, Muffley@PillowHQ.org wrote:
>>> I'm not aware of what was in the language when it was still C-with-classes,
>>> but operator overloading AFAIK is, if not an original feature then certainly
>>> a very old one, and the postfix syntax is a fugly hack.
>>
>> Operator overloading predates C++ and is already present in C. In C, the
>> expression `x >> 1` works both for unsigned int, unsigned long, and
>> unsigned long long, and produces different opcodes and different result
>> types for them. That's clear overloading.
> 
> Don't be willfully dumb, you know what I mean. Eg:
> 
> myclass &operator++ (int)
> {
> :
> }
> 
> The 'int' is a ridiculous hack to signify postfix. There are far neater ways
> it could have been done, eg a post_operator keyword or something similar.

I see. I was indeed wondering what you mean by 'postfix', but the 
current thread is all about <<...>> and [[...]], so I was confused.

I rarely write my own iterator classes, so the weird syntax of postfix 
increment does not bother me so much. I have never used a lambda for 
indexing an array, so the '[[' issue has not bothered me either.

OTOH, the `>>` misparse was indeed a nuisance in the past.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web