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?
Check this out -- https://cppquiz.org
(My own results on the handful of questions I tried
were less than stellar.)
Check this out -- https://cppquiz.org
(My own results on the handful of questions I tried
were less than stellar.)
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.
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.
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.
Check this out -- https://cppquiz.org
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 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.
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).
Check this out -- https://cppquiz.org
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.
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.
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).
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
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.
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.
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.
On 10.02.2025 16:56, Muffley@PillowHQ.org wrote:
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.
OTOH, the `>>` misparse was indeed a nuisance in the past.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 57:26:18 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,450 |
| Posted today: | 1 |