Thread: Easier Ways of Writing an Average Calculation Program?

How is it much harder? All you have to do is template the size.

Originally Posted by Elysia

Who says it must be done in a unit test?

It should.

Originally Posted by Elysia

I have seen compilers (*cough* gcc *cough*) that just silently accepts out-of-bounds access in a vector and C arrays.

For std::vector, the fault would lie with the standard library implementation, not the compiler. For a C-style array, it is not always possible to determine at compile time if there will be an out of bounds access. This would be an advantage of using std::array, assuming that the standard library implementation does perform such a check if NDEBUG is not defined.

Originally Posted by Elysia

what institutions actually teach newbies what out-of-bounds access is and its dangers?

The university that I attended

Originally Posted by Elysia

I think it's just better to teach them to use at() all the time even if not teaching them exceptions. At least it will prevent buffer overruns even if the program will crash and burn and everything will go horribly wrong. But at least I don't have to worry about a hacker taking over the computer.

Unfortunately, "crash and burn" could be as deadly in a real world program as "a hacker taking over the computer". In the end, there is no substitute for correctness.

Originally Posted by Elysia

How is it much harder? All you have to do is template the size.

Easy, except that it is infeasible to be teaching how to write function templates at an early stage: information overload.

Originally Posted by jimblumberg

So now your throwing in another advanced topic to force down your idea of an ideal C++.

Jim

And finding out the size, passing along the size and checking you meet the size isn't?

Originally Posted by laserlight

It should.

OK, yes, I agree with that, but maybe I should perhaps add that in addition to a unit test. Doing a unit test is always a good idea, but you can add checks outside them, too. And that might be a good idea, too.

For std::vector, the fault would lie with the standard library implementation, not the compiler. For a C-style array, it is not always possible to determine at compile time if there will be an out of bounds access. This would be an advantage of using std::array, assuming that the standard library implementation does perform such a check if NDEBUG is not defined.

Ahh yes, you are right. I should not lumped compiler and standard library together :/

The university that I attended

All of the materials I studied programming with cover this error. I think you are underestimating the quality of education you can easily receive.

Unfortunately not mine, where they even cut C++ (which was just a half-assed C with some extras) out in favour of Erlang.
Oh yeah, and pretty much everything else is just plain. And badly written too, with tons of globals variables and other crap.
And to think it is generally considered one of the best universities in the world...
It just goes to show how much C++ is unloved and security is just not covered.

Unfortunately, "crash and burn" could be as deadly in a real world program as "a hacker taking over the computer". In the end, there is no substitute for correctness.

Absolutely (I can imagine what happens if a safety critical system crashes and burns). But as far as for beginners go, at least when they are in the university, it is better to crash and burn than let the computers be taken over by a hacker, I think.

Originally Posted by whiteflags

I guess it doesn't... but it is much better to experience planned testing than to just crash out of a debug build. My personal experience with the IDE catching errors isn't so great. There was a point in time that exceptions didn't help me at all because the IDE didn't open the call stack window so I could read it after the debugger caught something. So in spite of what happened my sensory input only experienced so much. In fact I ended up building unit tests to understand where errors were occurring anyways.

I agree.
The only problem is that with an ecosystem that's so wide, anything can happen. If we are bound by fear that something might work 100% with something and absolutely fail with something else, we would never be able to recommend anything.
With modern software tools for the PC, at the very least (except maybe Eclipse; I hate that IDE), I think catching exceptions might work fairly well.
But unit tests are great... if your tools support them.

Isn't the bigger problem here that the person doesn't necessarily know what a stack trace is or how to read it? This is why schools teach things in units.

It is a problem. But it's also a problem with a newbie scratching their head because they made a mistake earlier, overwriting a variable through out-of-bounds access. Schools aren't likely to teach you these kinds of errors. Students generally have to learn these errors and their likely cause by themselves.

Well, just call them old like you usually do. I know, being correct is hard work. But you make it harder by not accepting criticism.

Old it is, then. I will try to take care to call them old from now on.

And finding out the size, passing along the size and checking you meet the size isn't?

No this is a basic skill that even a beginning programmer should be able to do with little problem. In my opinion using a template could be considered a beginning topic, but creating your own template is a much more advanced topic.

Jim

Originally Posted by whiteflags

I don't believe you, and my experience directly contradict you. That's not going to persuade me, unfortunately.

Considering that in my experience, programmers just sit there, scratching their head, then tries to rearrange some lines of code to see if it works, I don't find it surprising that a buffer overrun could completely screw them over.

Argument: To use std::array properly, one must first know exceptions.
Counter-argument: No. One can still use it as a plain C array with the added possibility for easier debug checks with compilers because it is easier to have debug checks for std::array than for C arrays.

I'm still not persuaded. I mean, that's good, but you wouldn't avoid such distinguishing features to begin with... using C arrays before the exceptions unit, or using C++ std::arrays and ignoring the throwing parts of it before the exceptions unit, is not worth looking down on and criticizing.

Argument: To use at() properly, one must first know exceptions.
Counter-argument: Yes. But exceptions are a part of the core language. Therefore, it is very important that one knows it. They are ubiquitous these days, in both C++ and other languages such as C#, Java, etc. Shying away from using because of exceptions is not ideal.

Maybe but not teaching exceptions is shying away from it...

Argument: When using at() without proper knowledge of exceptions, frustration will surface.
Counter-argument: You are bound to encounter them sooner or later when learning C++ anyway, and probably sooner than later. It's not worth putting off.

Formal education is all about controlled environments though. You're advocating trial by fire.

Argument: Exceptions can be difficult to teach properly.
Counter-argument: You don't need to teach all of it. Learning how to handle existing exceptions, or at least learning what they are, is easier than teaching everything at once. But even a little knowledge, if taught properly, is better than nothing at all.

You're anticipating this argument but actually I wouldn't make it. The education just needs to happen in an orderly fashion and I'm not so attached to any idea that I want to disrupt anyone's lessons. This is why I don't freak out when somebody has to use a feature, or a feature is selected that I don't like. I'm often afraid I don't know the complete picture to advocate too much.

Considering that in my experience, programmers just sit there, scratching their head, then tries to rearrange some lines of code to see if it works, I don't find it surprising that a buffer overrun could completely screw them over.

Poor guy! He's probably considering changing majors.

I disagree, exceptions while part of the language are not part of the "core language".

O_o

Sorry, but you don't get to disagree.

[Edit]
To avoid the argument, you don't get to disagree because it isn't something that welcomes opinion. You are free to avoid them, but exceptions are in the standard. They are a core feature. You not using them or wishing to use them doesn't change that.

It would be similar to saying multiple inheritance isn't a core feature for similar reasons, and only here a lot of people don't use that and don't wish to use it. Multiple inheritance remains though a core feature, perhaps even a distinguishing feature considering how many derivatives specifically avoid it.
[/Edit]

Exceptions are central to the standard library. That's a statement of fact. There exist alternatives to the standard library, but you don't have the option of completely disabling exceptions in the standard library. (Yes, some compilers allow you to disable exceptions; feel free to grab such a compiler and include and then use facilities from the standard library.)

You can't allocate and further construct an instance of any class at run-time without some form of `new'. That too is a fact. You can choose to use a "nothrow" version of `new' or the "placement" version of `new'. This part is anecdotal of course, but in my experience C++ programmers are far more prone to misuse the "nothrow" and "placement" forms of `new'. (To avoid the possible discussion: you can not call a constructor for a dynamically allowed object without some form of `new' in standard C++. Period. A few compilers allow it if you exploit the way they implement methods, but that is a terrible waste of time.) The default and recommended form of `new' is as an operator that will throw an exception.

Exceptions are central to error handling in what is easily the best library available for C++ that isn't the standard library. Again, this is a fact. (Well, you may argue that "Boost" isn't so great; you'd just be wrong.) "Boost" makes prolific use of exceptions. True, you do not have to use "Boost" or any other library, but the prevalence of exceptions in good C++ libraries makes it impossible to honestly say that they aren't a core feature even if they weren't a core feature.

The existence of exceptions changes the very nature of designing interfaces for C++. This, once more, is a fact. If you aren't aware of how exceptions, and also techniques build on exceptions such as "RAII", work you are destined to design an interface that prevents your code from behaving responsibly in the face of a thrown exception. Without understanding such facilities, you can't write a robust constructor/destructor for basically anything that isn't trivial, and that is the easiest part to get right thanks to being able to offload such mechanisms to members of the class. (In other words, if all you members behave themselves you may not even need to write a destructor and still the class will behave responsibly.)

In fact, it is my opinion that the way exceptions "mingle" with everything else to the point it is difficult to write good code without knowing a bit about them is one of few real and obvious flaws of C++.

So yeah, it is a core facility, and absolutely every C++ programmer needs to spend time getting to know them.

Now, none of this says anything about using dumb arrays, `std::array', or `std::vector', nor am I saying exceptions should be taught out of the gate. I'd personally recommend using `std::vector' here. I imagine that grumpy would also recommend `std::vector' here; it is just that, as he says, it is simpler to show the concept required using a dumb array.

Like many of the other features they are available if you choose to use them, but nothing says you must use them. There are still many companies and "standards" that do not allow exceptions to be used, for example the JSF standard doesn't allow exceptions.

The existence of such standards has no bearing on exceptions being a core feature. The `new' operator is crucial to the language yet many such standards exist that forbid dynamic allocation. In a similar way, mathematics with `float', `double', and `long double' is another primary feature with standards that specifically forbid their use.

Strangely enough, if you are following such a standard, you don't actually get to ignore exceptions. You have to write specific code, make specific interface design decision, and avoid a lot of common C++ idioms (The lack of "RAII" would be the most obvious thing I think.). If you don't do these things, which all specifically narrow C++ to be much more like C, you will fail to follow the standard. You will not follow the standard by simply not knowing about exceptions.

You are right though, you don't have to use them.

Also in my opinion exceptions can also be easily misused and, again in my opinion, this can lead to problems similar to the use of goto.

Anyone using exceptions for flow control in C++ is either doing it wrong or the use, as with `goto', is such an extreme border case that discussing it isn't worthwhile.

[Edit]
And please, seriously, I don't want to discuss `goto' again, nor do I want to discuss again using exceptions for flow control.

There are some extreme exceptions (hah.), but is just plain simpler to stick with a good rule of thumb you can throw (^_^) at newbies: `goto' and exceptions as flow control in C++ are evil!
[/Edit]

Which is completely irrelevant; everything can be misused to the detriment of all involved.

Take me for example, I think C++ programmers should avoid dumb arrays and dumb pointers.

*gasp*

Using containers, "RAII" style resources, and such other facilities makes it a lot easier to get code right.

For all of his "OMG! C++11" and "Let's babysit all the programmers.", Elysia isn't wrong about that.

That just doesn't make the use right in all cases.

Soma

Originally Posted by Elysia

This isn't about, oh it may have some advantages, but you're unlikely to see them until later. This is about teaching them to use modern constructs and omitting to teach them old constructs which are deprecated in favour of modern ones (I use deprecated, but obviously they are necessary in certain situations and projects, but that's not something a beginner necessarily needs to know).

We've had this discussion before. My observation is you tend to advocate features of C++-11 regardless of whether they are demonstrably better for a job at hand. That is chasing the "latest and greatest" regardless of whether it is better or worse.

In this particular case, C++11's array is more about providing a container interface to a sequence of related values (aka a C array). Even the C++ standards committee members have never claimed that C++11's std::array deprecates C's array. The fact that you do say that, does not make it the view of the C++ standardisation committee.

Originally Posted by Elysia

Do you think they will ever learn about std::array unless specifically told about it here? I don't.

I did not object to your mentioning C++11's array. I even noted in a reply to you it is a valid alternative.

I did object to your characterising C's array as "mine" because I correctly interpreted (given some of your subsequent comments) you were intending that to belittle the information I gave.

Technically, the information I gave is as correct as yours - in fact, more so, because you used a term llike deprecate (which has a specific meaning in all C++ standards, including C++11).

The difference is that you insist of advocating C++-11 features, and belittling anyone who mentions anything else. Given that, in this thread, you turned that belittling behaviour on me, personally, I feel entitled to be resentful.

Originally Posted by Elysia

If you simply replace C arrays with std::array, everything will work as before, so I don't think it's necessarily "harder" to teach them to use it. Granted, using some features may require a little more explanation, but if you don't use them, then what is the harm?

Which is it? They're not necessarily harder to teach, or it requires a little more explanation? Those two things are, if you think about it, in conflict - the effort needed to explain something correlates with difficulty of learning. The harder something is to learn, the harder it is to teach.

It is already clear from discussion in this thread - including your contribution to it - that C++-11 std::array requires more explanation.

Originally Posted by Elysia

You are by all means entitled to an opinion, but exceptions are really a core part of the language. Some/many new C++11 things tend to throw exceptions if things fail. Heck, even operator new throws an exception if it fails.

I agree with you that exceptions are a part of the core language. That does not mean they should be dumped on a beginner as early as possible.

Partial template specialisation is also a core part of the language. And it is not something that anyone in their right mind would expect beginners to learn - there are too many other things that need to be learned before they can even grasp the concept, let alone apply it.

Originally Posted by Elysia

If you don't want to explain exceptions, then that's fine. You don't have to. But you shouldn't bark at people who introduce std::array and are prepared to explain exceptions too, if newbies are unfamiliar with them.

All you contributed was a passing comment that array::at() throws an exception. You certainly did not make any effort to help a user understand the meaning of that.

I have certainly explained exceptions to new members before - and put more effort into such explanations than I believe you have.

Originally Posted by Elysia

You don't need to make them experts. You only need to teach the basic nature of what exceptions are and possibly how to handle them when thrown from a standard library function.

And so the list of things needing explaining goes on.

Do you also want to explain the intricacies of templates? After all, std::array is a templated type.

Originally Posted by Elysia

We are never going to move forward is we keep looking backwards.

You will stop moving forward pretty quickly if you're never willing to look back and make use of useful things from the past.

Originally Posted by Elysia

Newbies are the fresh source of programmers who will work in the programming field of tomorrow. We must teach them the modern practices so that they don't look back and create legacy code. We do not do them a favour by omitting new and modern containers and practices.

That is a purely academic viewpoint that does not work in the real world of professionals, or even of amateurs.

New programmers will do jobs that involve maintenance of old code. They will learn that sometimes an older code construct is more suitable for a task at hand, than a feature introduced in the latest standard.

You are doing new programmers no favours if you force them to only look at new features. Not everyone will work in an academic ivory tower.

Originally Posted by Elysia

How is C arrays more fundamental than a C++ array? Please do tell.

A "C array", and operations on it, can be mapped directly into machine instructions that manipulate memory and registers. Can't get much more fundamental than that.

"Fundamental" does not mean better, any more than it means worse.

Originally Posted by Elysia

Perhaps you should elaobrate on your "fundamental" view, too. I think it would be fundamental for a programming language to catch my errors, such as accessing out-of-bounds elements. Clearly, C arrays cannot even offer this possibility.

You have a novel interpretation of "fundamental". It is not fundamental for a programming language to catch your errors. It is fundamental for a programming language to be able to express solutions to problems. A fundamental property of any solution to a problem is that it may be correct or incorrect.

Originally Posted by grumpy

A "C array", and operations on it, can be mapped directly into machine instructions that manipulate memory and registers. Can't get much more fundamental than that.

So can std::array, I believe, since it is pretty much a thin wrapper over built-in (or C-style, if you prefer) arrays. Speaking of which, this declares a C++ array named x:

Code:

int x[10];

It happens to be the same code that we might use to declare an array in C, but nonetheless since this is C++, it is a C++ array.