Quote:Original post by Anonymous Poster
Then again, your compiler may not, this has nothing to do with the language.

Argh, that should of course be "your compiler may.", too many "not"s running loose :)

Quote:Original post by Anonymous Poster

Quote:Original post by MaulingMonkey
With the C style printf/fprintf/snprintf, types must be specified manually in the format string. This means that every time you call these funcitons, you must explicitly tie it to the variable(s) type. All and all, this leads to some very brittle code, as every line that prints that variable breaks every time you change the type.

Ok, how many times do you really change the type, and when writing to file, you sometimes want to know the exact contents of the file that you produce, not "oh, let's get lucky and remember that this variable has to be of this type so that our file meets the standard we're trying to follow with it".

Which is, among other reasons, the reason read() and write() are uncovered - so you can send the exact binary you want without any formating. Further, the operator chaining mechanism does not in any way interfere with choosing the exact type you want. In fact, quite the opposite - if you realize in retrospect that you've been using the wrong type all along, it's trivial with the operator chaining mechanism to fix the problem, so I'm having a hard time understanding how that's supposed to be a counterpoint.

Quote:So that's not always good thing, sometimes you want to be sure that the output_the_file() function/method does exactly what you want and does not depend how you define your struct/class/variables/whatever.

So you'd rather depend on how you define your format strings, violating the DRY principle (Don't Repeat Yourself) by repeating the format specifier, instead of depending on a single point of modification (the variable type itself)? I certainly wouldn't.

Quote:

Quote:Your compiler may not even warn if the types mismatch, the format specifiers mismatches the number of arguments, or if you pass an object, all situations which lead to undefined behavior, the bane of programmers everywhere.

Then again, your compiler may not, this has nothing to do with the language. If your compiler is at fault, it's not the language or the functions. Let's not assume what kind of compiler each uses.

I'm doing the very opposite of assuming what kind of compiler is in use. I am quite explicitly not assuming I have a good compiler available to my target platform/OS/twinky (or get to choose to use one). To do otherwise - as you would seem to prefer - is to do the very opposite of what you later suggest - that I rely on there being a good compiler and that I get to choose the compiler! Instead of relying on my compiler warning me in a situation which by no interpretation of the standard is it required to do, I would prefer to rely on the standardized features of the language itself, well defined by the standard itself to not allow compilation of certain methods of shooting yourself in the foot. So again, I'm having a hard time seeing why you consider this a counter point.


To review:

Compiler Quality         |  printf method               |  operator chaining methodGood C++ Compiler        |  will warn if not supressed  |  will not compile if in errorBad C++ Compiler         |  will silently compile       |  will not compile if in errorNot even a C++ Compiler  |  ???                         |  might silently compile

[Edited by - MaulingMonkey on July 18, 2006 2:59:24 AM]

Quote:Original post by MaulingMonkey
Which is, among other reasons, the reason read() and write() are uncovered - so you can send the exact binary you want without any formating. Further, the operator chaining mechanism

Sometimes you want to write in ascii, so how would writing in binary then help :)

Quote:
does not in any way interfere with choosing the exact type you want. In fact, quite the opposite - if you realize in retrospect that you've been using the wrong type all along, it's trivial with the operator chaining mechanism to fix the problem, so I'm having a hard time understanding how that's supposed to be a counterpoint.

If if if and if, and some maybes, all I tried to say is that it's not a silver bullet. What you are saying, is not the only truth, it DEPENDS.

Just one example where you want exactly one type of output: think about a situation where you exchange data between two programs via files.

Some of us get to choose what compiler they use, are you saying we should still obey your principles then too?

Quote:Original post by MaulingMonkey

Quote:
Let's not assume what kind of compiler each uses.

I'm doing the very opposite of assuming what kind of compiler is in use. I am quite explicitly not assuming I have a good compiler available to my target platform/OS/twinky (or get to choose to use one). To do otherwise - as you would seem to prefer - is to do the very opposite of what you later suggest - that I rely on there being a good compiler and that I get to choose the compiler! Instead of relying on my compiler warning me in a situation which by no interpretation of the standard is it required to do, I would prefer to rely on the standardized features of the language itself, well defined by the standard itself to not allow compilation of certain methods of shooting yourself in the foot. So again, I'm having a hard time seeing why you consider this a counter point.

You can assume whatever you want, but here you are trying to put everyone else in your situation. You are not wrong, in your situation, but to generalize that to everyone else is not very good advice IMHO.

Quote:Original post by Anonymous Poster

Quote:Original post by MaulingMonkey
Which is, among other reasons, the reason read() and write() are uncovered - so you can send the exact binary you want without any formating. Further, the operator chaining mechanism

Sometimes you want to write in ascii, so how would writing in binary then help :)

Quote:
does not in any way interfere with choosing the exact type you want. In fact, quite the opposite - if you realize in retrospect that you've been using the wrong type all along, it's trivial with the operator chaining mechanism to fix the problem, so I'm having a hard time understanding how that's supposed to be a counterpoint.

If if if and if, and some maybes, all I tried to say is that it's not a silver bullet. What you are saying, is not the only truth, it DEPENDS.

Just one example where you want exactly one type of output: think about a situation where you exchange data between two programs via files.

Some of us get to choose what compiler they use, are you saying we should still obey your principles then too?

You arguments don't make any sense.

Using C++ file streams you can write in ascii mode using the stream insertion operators. C++ wins again.

Also, what is stopping you from using C++ file streams when using a file communicating between files. Nothing is.

This is all about using the right tool for the right job, and if you are programming in C++, the right tool is the C++ standard library, not the C one.

Quote:Original post by MaulingMonkey
greed. It seems I've already rated medevilenemy down the maximum amount for previous bad advice, unfortunately.

My policy is to rate people maximally as soon as they give me a reason to rate them either direction. As strange as it may sound, in my entire time here, I've never gone to rate someone positively and found I'd already rated them negatively, nor vice versa. Not once. :/

Quote:
1) RAII.
2) Operator chaining.

A beautiful summary (although the operator chaining discussion ought to have the type-safety discussion factored out and mentioned as a third point :) ).

Quote:Teh AP z0mg
Ok, how many times do you really change the type,

Much more often than one ever tends to think one does. I can tell you this from personal experience. Besides which, changing it even once is enough to highlight the clear advantage of the new approach.

Quote:and when writing to file, you sometimes want to know the exact contents of the file that you produce,

So look at the file, in a text or hex editor as appropriate.

Oh, you meant that you want full control over it? How exactly would you lose any control by using the new functionality?

Quote:not "oh, let's get lucky and remember that this variable has to be of this type so that our file meets the standard we're trying to follow with it".

Which is exactly why you would use the *new* functionality! With scanf(), you have to remember the variable type in order to put it into the format string. With cin>>, the variable type to read is inferred from the variable type in the program.

Besides which, error checking exists for input - much, much better error checking than C can provide.

Quote:So that's not always good thing, sometimes you want to be sure that the output_the_file() function/method does exactly what you want and does not depend how you define your struct/class/variables/whatever.

Uh, outputting any primitive type behaves in a consistent way. For a class type, you *define how it is outputted* (in order to be able to output it), so it must logically "do exactly what you want". Besides which, unless you have to communicate to someone else, the only thing you care about when writing out data is that you can read it back in and construct the same objects.

Seriously, try to show a non-trivial example of what you think you can do in the "old ways" that's so wonderful. I can pretty much guarantee it will be torn a new one by the "new ways".

Quote:Original post by Anonymous Poster

Quote:Original post by MaulingMonkey
Which is, among other reasons, the reason read() and write() are uncovered - so you can send the exact binary you want without any formating. Further, the operator chaining mechanism

Sometimes you want to write in ascii, so how would writing in binary then help :)

For the times that you don't want to write in ASCII, obviously. For the times you want ASCII, streams have a good number of output options that behave in a consistent manner as well. I'm trying to be general and cover all the bases here. You're then assuming specific situations and pointing out certain features won't be helpful in certain situations - something I don't disagree with, but my point (which I seem to be having a hard time getting across) is that these features are useful in certain circumstances, and not a hinderance in the situations where they go unused, and as such are on a whole benifitial. Things you want. Things that have no reason to be avoided.

Quote:

Quote:
does not in any way interfere with choosing the exact type you want. In fact, quite the opposite - if you realize in retrospect that you've been using the wrong type all along, it's trivial with the operator chaining mechanism to fix the problem, so I'm having a hard time understanding how that's supposed to be a counterpoint.

If if if and if, and some maybes, all I tried to say is that it's not a silver bullet. What you are saying, is not the only truth, it DEPENDS.

That's like saying airbags arn't always benifitial - it "DEPENDS". Sure - it depends on you putting them to use. Of course, since you won't know ahead of time that you're going to have an accident on the 3rd, one must rely on having them already installed.

Just in case you get into an accident.
Just in case you need to change the variable type.
Just in case you misread the file spec.
Just in case you get hired, and your boss needs you to work on some obscure platform with a shitty compiler for some rich client.

Since we can't see the future, airbags - like the C++ standard library - help reduce risk and the cost of the mistakes we will enevitably make.

Quote:Just one example where you want exactly one type of output: think about a situation where you exchange data between two programs via files.

The Standard C++ Library has no problem doing this.

Quote:Some of us get to choose what compiler they use, are you saying we should still obey your principles then too?

Yes, those principles being that of weighing the costs against the benifits.

The cost of using the Standard C++ Library is trivial. A few extra kilobytes. The gains overshadows this, even if we're fairly certain all the compilers we'll ever touch will warn us about malformed format specifiers (since avoiding that potential for error is not the only benifit).

Similarly, since I'm confident I have enough say about compiler selection for my own personal projects, I feel free to use [boost]. The potential benifits are huge, and the cost - the danger of my code not working on *insert obscure compiler here* is of little concern.

Quote:You can assume whatever you want, but here you are trying to put everyone else in your situation. You are not wrong, in your situation, but to generalize that to everyone else is not very good advice IMHO.

Show me the situation in which I am wrong. I covered if you had a good, bad, or non-C++ compiler. What's the situation I'm missing, where the costs outweigh the advantages, however minor those advantages might be.

Yikes... ask a simple question, get an argument. :D

Well, thanks for your solutions!

Quote:Original post by MaulingMonkey

Quote:You can assume whatever you want, but here you are trying to put everyone else in your situation. You are not wrong, in your situation, but to generalize that to everyone else is not very good advice IMHO.

Show me the situation in which I am wrong. I covered if you had a good, bad, or non-C++ compiler. What's the situation I'm missing, where the costs outweigh the advantages, however minor those advantages might be.

Why do you so desperately want me to say "you are wrong", I have not said it nor I will, because I think you know STL far better than I do. It's not what I originally argued about, even though in the second row of messages I already went in your direction: talking about STL itself.

There have been previously threads about STL usage and I remember there being persons who said they can't use it, doesn't make STL the "clear winner" in all situations, in my book anyways :)

Quote:Original post by Zahlman

Quote:Teh AP z0mg
Ok, how many times do you really change the type,

Much more often than one ever tends to think one does. I can tell you this from personal experience. Besides which, changing it even once is enough to highlight the clear advantage of the new approach.

Well, in my about 10 year experiences in industry (not gaming though, consisting mostly about communication between systems), as far as I can remember I have never had to change the type of a variable so much that I would've needed to change how to output it.

Quote:

Quote:and when writing to file, you sometimes want to know the exact contents of the file that you produce,

So look at the file, in a text or hex editor as appropriate.

Oh, you meant that you want full control over it? How exactly would you lose any control by using the new functionality?

Right, I was thinking about not having access to STL and looked too much what I was answering to, sorry about that, I was wrong. (And no, right now I can't think of any other situations that would lead to not to use STL but old C-style file IO, but that doesn't make me believe those situations do not exist.)

Quote:
Seriously, try to show a non-trivial example of what you think you can do in the "old ways" that's so wonderful. I can pretty much guarantee it will be torn a new one by the "new ways".

I'm quite sure about that too :)

Rate++ (if I wasn't too lazy to register) :)