Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Blacken]

Longer than Qwertyuiops version but a different way of doing it. Also I've not compiled it so there might be typos, the concept is clear enough though.

Much better, but also not robust. The specification did not say you can just crash-and-burn if cout fails. What happens if cout fails? Do you know? (I do, but only because I looked it up. Which says something about how well encouraged bad code is when using the C++ libraries.)

And don't get me wrong--Boost makes C++ almost not suck. (I almost said "hey, that's cheating!".) But competent understanding to use Boost effectively requires a lot of knowledge of lower-level magic (and puts some pretty ugly holes in the type system, too). It does a lot for you, but you have to understand how it's doing the magic to get a lot out of it--in itself a nontrivial task.



EDIT: I can't prove this via evidence, but I have a strong hunch that object-oriented development in C++ may be pedagogically negative--that is, more acceptable for a skilled programmer who knows the "right" way to do something but can bend it to work in a subpar system--but a bad influence on the learning process. I genuinely wonder if you can actually do full separation-of-concerns very well in C++. I've never seen it done well, anyway. There are a lot of C++ misfeatures (multiple inheritance comes to mind) that encourage you to break abstraction and expose limited bits and pieces of the underlying system, instead of using a strong abstraction (which is the whole point of OO). Boost and the STL both end up showing off a lot of their underlying guts when you're working with them, and I have a hunch that, given the quality of the people working on the projects--lots of really really good people--this is due to the system being ill-suited to the task and their design compromising to make it. I don't think there are many cases where this design compromise is a good idea.

[Shades]

Since you did not ensure you were not dealing with a locked terminal or that your output was being piped somewhere unwritable, your code has failure conditions that are unchecked but very important: it's both very small, and very important, to make sure your output is actually going somewhere.

Be fair, the only way to do this (to my knowledge) is to compare the output handles with what the OS claims stdout should be, and not all OS's will tell you if the output has been redirected even then. I'm not even sure how many other languages you'd even be able to do that much.

To be honest your stretching it a little claiming qwerty's code was insecure. Also it might interest you to know that unthrown exception paths generate the same machine code output as source without exceptions. I'm not sure how you'd compare the speed of thrown exceptions other than against error checking, but error checking is both slower in thrown cases and also effects unthrown cases.

Oh and yes boost is cheating but you'll never catch me working on my own C++ stuff without boost, stlport and unittest++ (among others). If only I could get work to see things the same way ... *sigh*

Btw if you know of a reliable way to check for redirects please do enlighten me, would be useful knowledge. Likewise I don't know what happens if cout fails, I would assume an exception is thrown.

[qwertyuiopas]

...

How can you possibly argue against C/C++ like that, when most of the interpreted languages that you complement so much are based off C/C++ implementations[/a]?

Below in the spoiler is an example of more robust C code that does the same thing I asked. It is not, however, robust. See if you can spot why not.

Spoiler (click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#ifdef _MSC_VER

#ifndef _CRT_SECURE_NO_DEPRECATE
#define _CRT_SECURE_NO_DEPRECATE
#endif

#endif

int main()
{
int err = 0;
int val = 0;
char* input = NULL;

double num1 = 0.0f;
double num2 = 0.0f;
double result = 0.0f; /* yes, there will be rounding errors */

err = fputs("This application is intended to accept two integers\n" \
"as input, add them, and display the resultant addition.\n\n", stdout);
if (err == EOF) {
fputs("Error writing to stdout.\n\n", stderr);
return EXIT_FAILURE;
}


/* get num1 */
err = fputs("First number: ", stdout);
if (err == EOF) {
fputs("Error writing to stdout.\n\n", stderr);
return EXIT_FAILURE;
}
val = scanf("%lf", &num1); /* "lf" = double, as per scanf spec */
if (val != 1) {
fputs("Error receiving first number. Check your formatting.\n\n", stderr);
return EXIT_FAILURE;
}
if (val == EOF) {
fputs("Error receiving first number. EOF located.\n\n", stderr);
return EXIT_FAILURE;
}


/* get num2 */
err = fputs("Second number: ", stdout);
if (err == EOF) {
fputs("Error writing to stdout.\n\n", stderr);
return EXIT_FAILURE;
}
val = scanf("%lf", &num2); /* "lf" = double, as per scanf spec */
if (val != 1) {
fputs("Error receiving second number. Check your formatting.\n\n", stderr);
return EXIT_FAILURE;
}
if (val == EOF) {
fputs("Error receiving second number. EOF located.\n\n", stderr);
return EXIT_FAILURE;
}

result = num1 + num2;

err = fprintf(stdout, "The result is: %f. \n\n", result);
if (err < 0) {
fputs("Error writing output.\n\n", stderr);
return EXIT_FAILURE;
}

return EXIT_SUCCESS;
}


Are you sure?
First, there is redundancy in the code to get a number.
Second, putting the !=1 tests first mean that the ==EOF ones never succeed.
Third, your poor specification having results that you didn't want was *my* problem?
Fourth, there are unused bits of code there, either because you tried to do that many ways or because you copied code from a few examples.

Fixing points 1, 2, and 4 results in

Spoiler (click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int getNum(char *text, int *out)
{
    if(!out || !text)
      return 1;
    if(fputs(text, stdout) == EOF)
    {
        fputs("Error writing to stdout.\n\n", stderr);
        return 1;
    }
    int e = scanf("%lf", out);
    if(e==1)
      return 0;
    if(e==EOF)
      fputs("Unexpected end of input\n\n", stderr);
    else
      fputs("Could not understand formatting. Perhaps you didn't enter a number?\n\n", stderr);
    return 1;
}

int main()
{
    double num1 = 0.0f;
    double num2 = 0.0f;

    if(fputs("This application is intended to accept two integers\n" \
        "as input, add them, and display the resultant addition.\n\n", stdout) == EOF)
    {
        fputs("Error writing to stdout.\n\n", stderr);
        return EXIT_FAILURE;
    }

    /* get num1 */
    if (getNum("First number: ", &num1))
      return EXIT_FAILURE;

    /* get num2 */
    if (getNum("Second number: ", &num2))
      return EXIT_FAILURE;

    if (fprintf(stdout, "The result is: %f. \n\n", num1 + num2) < 0)
    {
        fputs("Error writing output.\n\n", stderr);
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

Even that is poorly written. Assuming that stderr will succeed when stdout fails is only true occasionally. It would also be better to catch the inability to write to the output once, and fail for it, and then assume that either stdout will not fail mid-program, or that it won't matter if it does if it ever does.

A program written for *users* probably doesn't need to report the inability to write to stdout every time it can't, otherwise they would complain about "error spam". Better would be to report that "one or more attempts to write output have failed" at either the end of the program or the first failure(optionally the first failure after successful output).

[Blacken]

Since you did not ensure you were not dealing with a locked terminal or that your output was being piped somewhere unwritable, your code has failure conditions that are unchecked but very important: it's both very small, and very important, to make sure your output is actually going somewhere.

Be fair, the only way to do this (to my knowledge) is to compare the output handles with what the OS claims stdout should be, and not all OS's will tell you if the output has been redirected even then. I'm not even sure how many other languages you'd even be able to do that much.

Every OS that I know of redirects output outside the scope of your program--stdout is always stdout, the shell just sends it somewhere else. But you don't care when the output's been directed. You care if it's been output.

To be honest your stretching it a little claiming qwerty's code was insecure.

I said his code was not robust, not that it was insecure. Argc/argv smashing is a definite security issue, but I wasn't claiming it'd be used. More of a little aside.

Also it might interest you to know that unthrown exception paths generate the same machine code output as source without exceptions. I'm not sure how you'd compare the speed of thrown exceptions other than against error checking, but error checking is both slower in thrown cases and also effects unthrown cases.

The source size bit is interesting--it shouldn't be for a few reasons (I mean, you're writing additional classes, which means additional compile units), but generally speaking, most compilers have always created ballooned executables with exceptions built in. This may have changed.

In terms of speed: stack unwinding is very, very slow in C++. Less so in modern languages, which can "cheat" to better know the system and ensure that the state is consistent without having to unwind every level. Like, in C#, if you aren't in a using block, there will be no destructors/disposers, so it's simpler to just jump up the stack - references are destroyed and the GC will catch up later. In C++, anything stack-based must be deconstructed correctly, and so on. (High-security code--oh, another foreign concept in C++-land--may require a traditional unwind. I'm not sure.)

Btw if you know of a reliable way to check for redirects please do enlighten me, would be useful knowledge. Likewise I don't know what happens if cout fails, I would assume an exception is thrown.

I don't know about redirects or piping, but my application doesn't have to care--just that the resultant output location can be written to. If you try to > a program to a read-only file, for example, printf will always return 0 no matter how many characters were put in. Not checking that is what I mean by "not robust," as your code is not guaranteeing that it is doing the right thing given a valid situation.

If you call ios::exceptions() - which is a bitmask of all things, eugh - it will throw an exception on iostream problems. Valid exceptions() masks are eofbit (WHY is this an exception?!), failbit, and badbit. It will then throw ifstream::failure, which is catchable.

But nobody knows this. It's an ugly, badly developed system, and you get warts like this all over. C's worse (negative return codes? zero return codes? values set into a passed-in pointer location? ERRNO?), but only a little.

How can you possibly argue against C/C++ like that, when most of the interpreted languages that you complement so much are based off C/C++ implementations[/a]?

Because it is possible to write code on which less robust code can run more safely. You are not as skilled a developer as the guys writing JRockit or the .NET CLR.

And I'm making a point of being polite, so drop the attitude right fucking now.

First, there is redundancy in the code to get a number.

Correct--I did a first-pass write and did not refactor it for code repetition. This has no effect on robustness, however.

Second, putting the !=1 tests first mean that the ==EOF ones never succeed.

EOF is being tested for stdout, because fputs will return EOF on a write that fails (which is in itself a terrible thing--according to them, EOF does not always mean "end of file"!).

You're correct about the scanf testing; it works, and catches bad conditions correctly, but does not do so well.

Third, your poor specification having results that you didn't want was *my* problem?

My specification said to take two numbers. You invented the use of arguments to take them. This is legal by what I said. So we're good so far. But your code still fucked up by accepting non-numbers. You chose to accept bad input and turn it into "legal" input--that is, you expanded the system's domain but in doing so created an unreliable range. This is not robust.

As you failed to adhere to the specification: yes, it is your problem.

Fourth, there are unused bits of code there, either because you tried to do that many ways or because you copied code from a few examples.

Correct; I hacked it together in about ten minutes for a class and pulled it out here as an example.

The code ran successfully on OS X, Linux, Windows, the XBox 360, and the PS3. The same bugs existed in all areas. Specifically, the failure to account for stderr (because I couldn't think of a good method to do it) and the fact that floating-point addition may not work correctly. The rest of it, while ugly, did address every problem conditions that the TA and I could come up with.

Even that is poorly written. Assuming that stderr will succeed when stdout fails is only true occasionally.

It's true quite often in the UNIX world. It is extremely rare for someone to redirect stderr as well as stdout, precisely because they are semantically different and contain different data.

It would also be better to catch the inability to write to the output once, and fail for it, and then assume that either stdout will not fail mid-program, or that it won't matter if it does if it ever does.

That's bizarre reasoning. A console might get locked (which would cause stderr to fail, on this you are correct) or you might run out of disk space during output with the > operator on the shell (which would not cause stderr to fail, but would cause stdout to fail). It is a case of application robustness, and you may not make unwarranted assumptions. The state of the application may change during its running life. Check it every time. You check to make sure malloc() returns an actual memory address instead of out-of-memory errors, don't you?

...don't you?

A program written for *users* probably doesn't need to report the inability to write to stdout every time it can't, otherwise they would complain about "error spam". Better would be to report that "one or more attempts to write output have failed" at either the end of the program or the first failure(optionally the first failure after successful output).

Bad reasoning. Bad, bad reasoning. You simply don't get to make that assumption. But even if we take for granted that the assumption holds...that's irrelevant, because my program knows when it is failing. Whether mine did the "right thing" with that knowledge is certainly debatable. Yours did not know something was wrong at all. Yours was not robust.

And when it comes to C/C++, almost nobody's code actually is robust. That is the point that I am making. If you can't make a robust program to add two numbers together, how can you think you can make robust code to do something important or complex? Complex system failures are probabilistically additive in the worst case. If you have a piece of code that fails 10% of the time and an independent piece of code that fails 20% of the time, the probability of one of those failures happening is 30%. If every little piece of a system has chances for failure--well, if you can't at least know when they fail and then take steps to address the problem, these little chances grow to very large ones.

Managed languages can fail. But they fail in predictable, established, conventional ways, and failure cases have been addressed by people far smarter and better-equipped than some newbie. Or even most "experts."

[qwertyuiopas]

You want a robust solution?

I could spend months writing potentially infinite numbers that accepts hex, decimal, octal, roman numeral, english, floating point, mixed, and unicode as input, adding context-sensitive, auto-converting data types, robust and completely flawless input and output, but...
People have already done that in scripts and interpreted languages.

Same argument as that Java can *never* be faster than the language it is implemented in, and thus the language it is implemented in will always have a faster solution, even if for some odd reason the fastest solution means fully implementing Java itself.


The point is, to make a fully robust and complete implementation of any program, you need to consider countless increasingly minor issues for even the simplest tasks. However, to use a script or interpreted language, you accept the fact that in exchange for better implemented fundamental functions, you have an overall slower program, and can *only* do things that *have* been implemented properly.

If some new technology or API comes out, C and C++ are usually the first to be able to interface with it, while some languages(likely python) take months to catch up, and some languages(like brainfuck) will *never* have an interface for it at all. Yes, the python version likely has quite a few additional safety checks and handles 99.98% of special cases, but someone had to write all of those, and almost certainly in C.

Now, as for checking things, improperly handling allocation failure guarentees a crash, but not caring if the output is actually getting somewhere generally is only a minor inconvenience. With networking, sending everything is important, but with a mere text output on a trivial program, handling that extra 9% of special cases that rarely occur really isn't all that important.

Being overly paranoid about checking for inappropriate values, however, does have significance, as it is protection against mistakes during future development. Best if "impossible" events are logged and blatantly shoved in the face of the developer, so that they know that something is wrong, but "function 452 reports invalid array-pointer" is far better than a generic segfault or core dump.

Oh, and I would love to see an operating system written in pure python. It would really be impressive if someoe succeded with only a generic base install, frreshly downloaded.

[Blacken]

1) The challenge was not "oh, this hacky thing is okay." The challenge I gave you was to make correct code that did what I said it should. You failed at it, and I don't think you get why you failed. Shades failed too. I failed, too. The difference is that we understand why we failed and why understanding this is important, and you choose not to. Rethink this position.

2) There are edge cases where a JVM can perform better optimization and thus provide tighter native code than an optimizing C compiler. You can scoff, but they exist.

3) You, and new programmers in general, almost certainly do not require native code performance. Claims to the otherwise are, generally, short-sighted at best and disingenuous at worse. The security, robustness, and productivity benefits of modern toolkits are inarguably superior to the stone knives and bearskins.

4) Some people do, unfortunately, still need to use C; you are not one of them, and a beginner certainly is not. Every relevant language (Python, C#, whatever) can bind to C libraries. This obviates the need to actually write C--you can rely on the development of people who are likely better at it than you are (not a guarantee, but a safe bet) and remain within safe, sane systems. Use the highest-level tool that makes sense to get the job done.

5) Checking for impossible situations and "shoving them in the developer's face"is not a panacea, especially in C/C++. Code can have actual runtime differences when compiled and even when run in different modes (debug-in-IDE, debug, checked runtime, release runtime).

6) Your cavalier disregard for robustness is incredibly unfortunate. I demonstrated that you cannot write robust code for such a trivial application. Well, no--you demonstrated it. If you cannot write robust code for trivial applications, you are unlikely to be able to write robust code where it actually matters. You might, one day, learn that leveraging the best tool for the job means you might not be quite as l33t as you want to be. Many people do learn this, when they are confronted with the unpleasant fact that they are not the hot-shit programmers they think they are. Or, as is very common, they run away and say "it's not my fault." I am hoping you are not the latter, but I suggest you start thinking to avoid this fate, instead of offering progressively lamer excuses.

[G-Flex]

qwerty: I think you missed the point of the exercise. The point was to create code that achieves something deceptively simple, but in a way that's correct for all given inputs and in any given environment. As Blacken stated, treating non-numbers as numbers is not correct in the slightest, plus everything else he mentioned.

[qwertyuiopas]

You will notice that even high-level languages will silently fail unless the programmer adds a special case, if stdout cannot be used. So, in the example you game, what I wrote would be very similar in functionality to what someone would write in python. They might use a different conversion function that gives an error on non-numeric, but it might not support hex or octal in exchange.
Also, the 0-default is best for addition, as it means "no change", as if that number were ignored. A more robust system that reads sumbers until EOF or empty line can still use that, and it would only *appear* to add actual numbers. Actually giving a fatal error, in this case, is a problem, or better: decided by an argument. That way, a user could pipe a novel through, line by line, and it will not give up on the first line without a number in it or give an error.
{new post}

See argument that adding 0 is essentially doing nothing. His solution would fail given hex or octal input. The optimal solution would read the number into a buffer(uning read functions that specify a buffer size), and then manually analyze the type of the number, and then store it in a custom format that allows infinite precision both before and after the decimal, possibly including complex and rational numbers.

[Blacken]

That argument is a programmer's argument. Programmer's aren't users. You are too busy trying to prove that you are right to spend any time thinking about what is correct. Stop being intentionally obtuse.

You are showing very well why C/C++ are horrible for new programmers, though--because you are quite clearly enmeshed in how the computer works, without the ability to escape it, when the point of writing code is to work foremost in the problem's abstraction instead of the computer's abstraction.

So thank you for bolstering my argument.



EDIT: Go look up what a domain and range are. Then go look at what the specification said--not what you think the specification said, what it said. NUMBERS. You do not get to argue and say the specification is wrong; I determined the specification, you were delivering code to me, and I said you're wrong. I said you are wrong because you did not address the function's domain, you addressed a superset of its domain, and you need to sack up and admit that you were wrong. Or you can stop posting. In either case, quit bringing up these oh-so-lame arguments that don't actually work. Bring substance related to what we're talking about, or piss off.

[G-Flex]

You will notice that even high-level languages will silently fail unless the programmer adds a special case, if stdout cannot be used.

There's a difference between something silently failing in a controlled manner and simply not handling the case at all in your code. Silently failing and undefined behavior are not the same thing. You cannot even know necessarily how a given system is going to respond to, say, your program trying to output something when the running environment can't handle it for whatever reason. This is why you actually handle the case. You don't have to give the user an error message if you don't want to, but you have to be able to say what's going to happen in a given scenario.

And from a user's perspective, the program isn't failing at all when you give it non-numeric input for the numeric function. It's simply returning nonsense. If I ask the program to add "4" and "potrzebie", and it tells me "yeah, the sum is '4'", then it's giving me the wrong results. In this case, it's more obvious to the user that the result is wrong, because the logic is very simple and staring him in the face, but in a more complex example, this would be an extremely terrible thing. A portion of a program should not fail and then pretend to the rest of the program that it's succeeding. And if it's a library doing this that other people (or even you) are using, then you have to keep special-case information in mind for that one function just so you can test it properly, because the function itself isn't. This should not be necessary, and causes problems.

They might use a different conversion function that gives an error on non-numeric

This is, as I just said, exactly the point. It should not pretend to return valid results when it is not possible to do so.

Also, the 0-default is best for addition, as it means "no change", as if that number were ignored.

This is terrible logic. The best result is to simply error out, because you're trying to do something that is mathematically undefined. In some cases it might (or might not) make sense to ignore invalid input as a practical matter, but if you want to talk actual program correctness, it's not the best at all, because it's flat-out incorrect. 3 + potrzebie is not 3. It's nothing. It's undefined, because one of the terms doesn't even make sense. Even at a practical level, even in such a simple program, it can cause problems: What if some uneducated user types in "4" and "pi" as inputs and gets 4? It's misleading, because it's wrong.


He asked you to right something robust and correct, and you did not. You wrote a program which does not provide behave correctly for all input, period.

[qwertyuiopas]

"Correct":
Would you rather that 5 + "tree" gave NaN? Or "5tree"? Or maybe a segfault, or undefined behaviour crash?

What the end-user would probably appreciate most is ignoring non-numeric(or adding 0, it DOESN'T MATTER), and then, at the end, giving a warning that at least one input was non-numeric and thus ignored.

This scales well, because with a more advanced program, where you can enter an arbitrary number of numbers, failing after the 38th precisely hand-entered number because you hit 'w' rather than 3, or spewing out thousands of lines of "not a number" when you give it an automated input that is passing along every single word it gets, not just the numbers.

Quitting or halting do not scale up to arbitrary quantities, so are only sufficient for two-input programs at most.

[Blacken]

I think you need to stop trying to pursue this argument. You clearly do not understand. Here. Let me put this unambiguously:

I gave you the specification. The specification is mine. If I tell you that you do not conform to the specification because you did not adhere to it, you do not have the option to argue. You are wrong.


If you do not sanely handle all valid inputs--and you do not, this "treat it as zero" fiction invented in your own head is in no way sane handling--you are not writing robust code. You do not have room to argue. You don't understand the topic and you don't understand the consequences of what you say. Stop it.

[G-Flex]

"Correct":
Would you rather that 5 + "tree" gave NaN? Or "5tree"? Or maybe a segfault, or undefined behaviour crash?

What the end-user would probably appreciate most is ignoring non-numeric(or adding 0, it DOESN'T MATTER), and then, at the end, giving a warning that at least one input was non-numeric and thus ignored.

This scales well, because with a more advanced program, where you can enter an arbitrary number of numbers, failing after the 38th precisely hand-entered number because you hit 'w' rather than 3, or spewing out thousands of lines of "not a number" when you give it an automated input that is passing along every single word it gets, not just the numbers.

Quitting or halting do not scale up to arbitrary quantities, so are only sufficient for two-input programs at most.

If the user definitely mistyped any of the numbers, then he cannot trust the results even if you ignore the mistyped number. Seriously. If I'm trying to type the list "3, 5, 1, 7, 9" and type "3, 5, 1, u, 9" then I obviously won't get the right answer, nor can I expect the answer to be in any way meaningful. Simply ignoring invalid input is bad for this reason: You cannot get a meaningful answer when the input is obviously flawed.

Besides, it's not about "what the end user would appreciate". Blacken asked for robust (correct) code. Code that is valid given any inputs. Yours was not. This was the point he was trying to make: That making actually-correct, strong code is difficult even for relatively simple things. We're talking about program correctness, not about convenience to the user. It isn't correct to say "potrzebie + axolotl = 0". The program is meant to add two numbers and total them. It is, strictly speaking, incorrect for the program to pretend that it is doing this even when it is not.


Also, the problem is more obvious if you're doing multiplication or division instead. I leave it to you to figure out why.

[Jookia]

Blacken, are you arguing that C/C++ is bad because of handling user input?
Every programming language has the problem of handling user input.

[Diablous]

Blacken, are you arguing that C/C++ is bad because of handling user input?
Every programming language has the problem of handling user input.

What I'm getting is that he's saying that C++ is not good for beginner's.