Thread: C++ tests.

and last I checked, most real tests are meant to be done without the help of a search bar.

Well, there are 'open book' tests, though the definition of 'open' and 'book' is usually defined by the person administering the test.

I personally haven't had an open book test since 8th grade. That's just my experience, though.

Not that syntax research isn't somewhat of a necessary skill in programming, it's just one that I haven't seen programming teachers emphasize.

About half our tests in university are open-book. Of course, the book is so big that looking up all answers (or even most) takes longer than you have. And of course these tests require you to actually apply the gathered knowledge.

I believe they are valid evaluation tools depending on the context in which they are applied.

I can see a standardized test being useful as a first filter for a job application, for instance. Or even a school test to evaluate specific knowledge that is more centered on language features (unfortunately the aim of many teachers) than programming techniques.

Of course, the so-called "Test your knowledge of C++" type of tests, are ludicrous. Not only because standardized tests cannot be seen as generic all-encompassing tools, but also because, as pointed out in the very beginning of this thread, most test authors don't really know how to create a standardized test.

My point about search engines etc. earlier was that you don't score well because you don't really "know" the material in the sense of having it completely memorized. And in the real world that is just fine, as long as you know how to find the answer in a reasonable amount of time.

Originally Posted by IfYouSaySo

My point about search engines etc. earlier was that you don't score well because you don't really "know" the material in the sense of having it completely memorized. And in the real world that is just fine, as long as you know how to find the answer in a reasonable amount of time.

Mmm... that's true, somewhat. It really depends on the case. I'm sure in the case Bubba as well as others are speaking of, then it's a situation where it's highly acceptable to look up the info. In other cases, it might be something a programmer should either figure out logically or so basic that they should have memorized it.

I know that there was another programming teacher freshman year of college that gave open book tests for the Object Oriented C++ course. He would allow people to look at notes for syntax as simple as how to delete a dynamically allocated array. Something a C++ programmer would know off the top of their head. If he asked something like name all of the methods in ios_base, then I can clearly understand allowing them to look it up.

Originally Posted by valis

I find many of such standardized tests to be quite stupid. Just because person A knew the precedence and distributive properties of logical operators doesn't mean he is a better programmer than person B, because person B probably didn't focus on memorizing bull........ you can use () to sort out; instead B spent that time figuring out why & 1 is faster than % 2. One could even argue using parentheses is better than not, because those programming which don't have such properties memorized will know what the code is doing right away.

Those tests aren't stupid. You think they are programming tests, but they aren't. Their purpose is testing your knowledge of a language, not whether you know how to program. So, before you bash these tests you must ask yourself: what is their purpose?

So far, I've had 2 programming courses. One was open-book, the other wasn't. I gotta say, the book (or a hastily scrawled parameter list on a corner of a napkin) *seriously* helps with the language aspect of any test. I know, to varying degrees, how to use most aspects of C++, and where/how to use them properly. However, for example, there's *no* way to remember function names and parameter order (and related named constants) for every function in the C++ library without either photographic memory or many years' experience (so far, 4-5 hasn't been enough). While I can usually remember what a function does, and what it requires, I can't always remember whether the FILE* is the first parameter, the source string comes before the destination, the result is returned through an argument, the return is 0 for success or error, etc.

Originally Posted by valis

however, syntax is trivial so I find it a silly thing to test people on.

Syntax is trivial in some languages, but if you ask me, C++ syntax can be very hard.

Originally Posted by valis

however, syntax is trivial

C++ syntax is fundamental. As it is with any programming language. A programming language is only understood at the core by the understanding of its semantics and its syntax.

However, as Sang-drax said, the syntax on some languages is indeed trivial. Their language features imply an higher level of programming which in turn almost forces the language implementators to define a near natural-language syntax. Which they happily do.

This is not the case in C or C++. The syntax is rude and even offensive to someone migrating from an higher-level programming language. It is imperative one understands it. I believe there is no better example on the importance of the language syntax when one thinks of pointers. There is no seasoned C/C++ programmer that can't convince me he mastered the syntax so well, that he can now write complex address and dereference operations on objects without ever having to come back from a failed build. And lets not even get started on function pointers...

In fact, pointers syntax can be so confusing that this language feature is one of the few that offers an higher abstraction operator to contend with more complex operations. The -> operator. Correct me if I'm wrong, but in C++ there's only one other language feature that comes close to an higher level abstraction to deal with the complexity of the syntax. The typedef keyword. Many other programming languages offer a lot more than this.

But maybe more insidious is, exactly because C++ syntax shares very little aspects of a natural-language programming style, the fact that perfectly valid and apparently logical and correct syntaxes can lead to disaster. It is imperative the syntax is understood.

Originally Posted by idem

RegardlessOnce you know one simple imperitive language (C or pascal for instance), learning another is very easy, same thing with most other approaches (oop, functional, etc.). Also the core ideas across them all (recursion, loops, memory, etc.) is still the same.

And yet again I have to disagree
But this is an already long post. Maybe some other time

There is no seasoned C/C++ programmer that can't convince me he mastered the syntax so well, that he can now write complex address and dereference operations on objects without ever having to come back from a failed build.

There is the possibility of typographical errors, though those would be easily corrected after a failed compilation. Actually, I think one reason why C++ has references is because too many levels of indirection can cause even seasoned programmers to make mistakes from time to time.

>>There is the possibility of typographical errors, though those would be easily corrected after a failed compilation.
Ah, yes. Another reason why I tend to do better in real life than on written tests You can't for example do this:

Code:

if(a < b)
{
}

and then fill in the body of the code after. Terrible, because my handwriting tends to distort from neat lines into slanted and oddly offset abstractions, and then I have trouble lining up my braces, which then leads to problems with triple-closing code blocks etc.. and, of course, sometimes it means I forget to close my braces, since I'm used to closing them immediately and filling the body in later.