The current scope of the advanced C++ exam. What do you think?
-
I think the scope of the exam is fine as it is. STL (from my point of view) is an extension to C++ and can be used as it is standard, but it's not an integral part of C++. Same to Boost, it is good, I also use it, but it's not part of raw C++. And even not of Qt. So for this exam, both should not be considered.
-
[quote author="Tobias Hunger" date="1290588895"]IrQX: I put your page into the "snippets" category. Feel free to change that if you like (the Category is just a tag in the page which can be edited like the rest of the text).[/quote]
Thanks. I've lost a lot of time searched how to move topic.
-
The keyword volatile should be known and the new operator overloading --
this should be interesting to those who think C++ cannot be used in embedded programming. As I learned when programming a game with min-max-trees: calling new does not automatically mean "digging the heap".And - how could I forget about this! - exception handling should be included.
-
[quote author="Denis Kormalev" date="1290689759"] Wolf P., operator new overloading is a really specific thing and I'm not
sure it should be included.
Exceptions are not a common practice in current Qt library design, so no
sure they should be in this exam (exam is about Qt all in all, not about
generic C++)[/quote]Exception handling is an integral part of the C++ standard for decades,
although often misunderstood or misused.
Imagine you are about to use existing excellent C++ sources in your Qt
project that make use of exceptions, should you avoid it? In this it
will be better to know how to catch them the right way and transform them. -
Wolf P., as for me it is somewhere close to boost. Of course good developer should know how to work with both of them, but not sure it is good part of Qt exam.
-
[quote author="Gerolf Reinwardt" date="1290695575"]And I'm not pretty sure, if overloading new is really relevant for most Qt projects...[/quote]
It's questionable if it is relevant to most C++ projects at all :-) Knowing that something is possible, does not necessarily mean that a relevant bunch of programmers do need it regularly.
-
Last one is something that I can't imagine how to put it into exam format.
-
[quote author="IrQX" date="1290934467"][...] Last one is redundant.[/quote] redundant? In what sense?
I would say you can check it with multiple choice tests. Unexperienced developers tend to look only on their class instead of checking its usability. For instance, in the development of an API they often prefer to add additional parameters to existing methods instead of adding new methods.
I think good API design can be tested in an exam. -
[quote author="Wolf P." date="1290946037"][quote author="IrQX" date="1290934467"][...] Last one is redundant.[/quote] redundant? In what sense?
I would say you can check it with multiple choice tests. Unexperienced developers tend to look only on their class instead of checking its usability. For instance, in the development of an API they often prefer to add additional parameters to existing methods instead of adding new methods.
I think good API design can be tested in an exam.[/quote]Any suggestions, how it can be implemeted in exam? I means example qustions for it.
There are no method, that allows estimate quality of design. How you can say that "this design is bad" and "this design is good"? It will be only yours humble opition, no more.
That is formal mathimatics problem, which is impossible to prove, yet. Anyway, "good API design" shouldn't be included in "advaced c++ exam". Designing good API is modeling problem. Basics of "API designing in C++" - virtual functions is already included in cirriculum block.P.S. I'm suspecting, that I made some errors in text. I appologize for it. English isn't my native language. Have a good day.
-
Today, I took this exam. I must told to you next thing.
I answer on question for 32-34 minutes. Next I wrote comments for about 15-20 minutes. Then test-system said, that time is over. 33 + 17 = 50 minutes, no 60!. When I took Qt Essentails exam this problem also was present. And in first exam was no extra-time for non-english people.As for me, exams was almost easy, and that time more then enough. But this issue not seems to be good. So, I guess, is this problem of testing center, or something other?
-
Creating an API isn't really a c++ specific skill, is it?
Whether an API is good or bad is somewhat measurable, but hard to do in a test. The coding style part is subject to taste and unfortunately contributes greatly to whether APIs look nice or not (I really dislike the boost API mostly because of the naming conventions...).
-
I think (after reading the replies here) that involving the API thing in a C++ test discussion wasn't such a good idea. Maybe I'd better collect some thougts on this topic first... (the wiki could probably be the right place for an early sketch?)
[quote author="Franzk" date="1291152081"]Creating an API isn't really a c++ specific skill, is it? [/quote]
Since APIs depend on language and the framework(s) being used, their properties should be evaluated with respect to the Qt/C++ case, in my opinion.I'm not sure if it can be tested at all. But if I see that people are tought classes, inheritance, encapsulation and so on, it seems clear to me that most of them will actually create interfaces, other developers have to code to. Why remain in a (sort of) hello-world loop(++) - I think it's no secret that hello-world programming does not enable anybody to do anything useful for real-world tasks.
-
[quote author="Franzk" date="1291152081"]Creating an API isn't really a c++ specific skill, is it?
Whether an API is good or bad is somewhat measurable, but hard to do in a test. The coding style part is subject to taste and unfortunately contributes greatly to whether APIs look nice or not (I really dislike the boost API mostly because of the naming conventions...).[/quote]
+1. There are no ideal API. Who will justify? For example, if think, some API is good, somebody else think not. It is like different coding rules in different companies.