«

[Japo]

Originally Posted by Data

Don't bother with pointing out all C-isms and other things

Don't worry about that, first I'm not fluent at programming since I use it so little, second C is what I grew up with and although I pushed myself to learn ++, I have used C++ not at all instead of little so it's not natural in me. (And actually see no comparative advantage for small one-person projects. It may be nice to use + instead of strcat() though. LOL And C isn't certainly obsolete nor redundant, I'm not the only one to think so, whereas C++ could very well be and sure is a messy language.)

Good job, I don't think there's much more ellegant code to accomplish the same.

The only thing I can think of is why you bother to declare the namespace once and again, instead of declaring once "using namespace std" at the start of the code. And why you declare main's arguments that you aren't using instead of declaring it (void)--or () which is the same. But maybe you have reasons. And sorry if I have just pointed what you know yourself after you warned me not to.

Very well done. And I bet the problem has the compiler to blame, it's up to it to make portable code portable as promised.

[Data]

Thank you for kind remarks.

I use using namespace std; quite often, but as I published the code I made a bit more robust for copy and paste work by including the correct namespace.

I tend to forget the possibility to omit the arguments of main.
Returning a value is good practice, especially if the utility can be used in shell scripts.

My Cism were (as far as I'm concerned)

templine = "";

instead of

templine.clear()

and

templine != ""

instead of

!templine.empty()

But the Cism are actually smaller and for me at least as intuitive as the C++ things. (long live the operator overloading )

[Japo]

Originally Posted by Data

But the Cism are actually smaller and for me at least as intuitive as the C++ things.

True, maybe people who have learnt to program oriented to objects from the start don't get how all those abstractions are both added power and added burden. You have to learn the object libraries. And in some cases a more low-level code is not more clumsy nor illegible and sometimes the contrary. That's why I think of objects as a tool rather than a philosophy for the whole of all projects; and they don't really show their full power but as an interface between different programmers. Using object orientation as a way to make learning programming easier just creates bad programmers in general.

Usually you can't be sure if you can really get away with "C-isms" and the like. Something may not be in the standard and yet your compiler may support it and others won't. (It's not the case and your code is robust.) And you're not supposed to know, because information hiding is a sought effect of object orientation.

As a matter of fact using an overloaded assignment operator with a string is not a C-ism at all... Actually the robust C code to clear a string or check if it's not empty is very brief and immediately recognizable:

*templine = '\0';

while ( *templine != '\0' );

(Actually I could write just 0 instead of '\0', couldn't I? Hm better safe than sorry.) Of course templine would here be a C string (pointer to char), not a string object. I can't do this stuff with objects and I'm not supposed to, their innards are "private".

But I'm rambling...

[Playbahnosh]

Originally Posted by Japofran

Usually you can't be sure if you can really get away with "C-isms" and the like. Something may not be in the standard and yet your compiler may support it and others won't.

Oh boy, don't get me started on that one.
I have to take C and C++ classes here on the university, and it is a constant pain in the aß, as to which compiler to use. For many years, the uni used Microsoft's Visual Studio for C programming, but the license expired, and they didn't renew it. They started using Eclipse because it's free, but the course's codes, books and learning material were optimized for Visual Studio, and a great many things, what worked in VS, didn't work in Eclipse and vice versa. Just think about it, you make a project for class in C or C++, you run it and works fine, you bring it in for class and it won't work there. Who's to blame for that? Ususally us, students.:notrust:

[Data]

Originally Posted by Japofran

As a matter of fact using an overloaded assignment operator with a string is not a C-ism at all... Actually the robust C code to clear a string or check if it's not empty is very brief and immediately recognizable:

*templine = '\0';

while ( *templine != '\0' );

(Actually I could write just 0 instead of '\0', couldn't I? Hm better safe than sorry.) Of course templine would here be a C string (pointer to char), not a string object. I can't do this stuff with objects and I'm not supposed to, their innards are "private".

You are totally right about the fact that using the overloaded operators is very C++ like and not C like, however for a starting programmer (for those I posted this very simple piece of code), it can be confusing and might lead to bad practices with other objects.
Maybe i should use string.append instead of the += as well.... but it doesn't make the code look more beautiful in my opinion. In my code not intended for newbies you will find lot's of classes in which I overloaded the operators in order to keep their usage intuitive. (So you don't need to learn an interface before you can use it)


You could use 0 instead of '\0' I always use 0., but this comes mainly from the fact that
in C++ NULL and 0 are the same, so I can stick with one type of 0 for everything.

I could ramble on about objects and stuff and as well, but that has fairly little to do with the solved problem.

Thank you for your discussion so far. I really appreciate it.

[Playbahnosh]

I gotta get a C book... I feel left out...

[Data]

sorry play.

[Japo]

Originally Posted by Playbahnosh

I gotta get a C book... I feel left out...

Sorry. I guess there's no point in splitting this topic in two now that one of them would be solved... :P

There are dozens of free tutorials, even whole books (tutorials are better to start).

This kind of code isn't difficult so you should get the hang of it after a while. The only special thing here is that instead of taking the trouble to call specific functions to handle files, Data took advantage of the fact that C/C++ handles files and input/output devices in the same way, as "streams". However once opened files would have been interfaced with the same kind of code. The "<" in the command line call told the OS to use one file as standard input stream, instead of the keyboard by default, and the ">" to use another file as standard output stream, instead of the console. So if you for example used the former but not the latter, you should get the intended result, but printed on the screen instead of saved to a file.

Other than that, this code is a good example for beginners wanting to start to learn input/output.

BTW Data, there was another reason to use string.empty() and .clear() instead of == and =, the same reason why they exist at all, since you've shown that you wouldn't need the former if you used the latter instead. Not that the code would be more robust, but that it would be more efficient. I know that's not an issue here, but it's good not to let that get out of sight as a good practice, so that it will come naturally when it be important. I haven't looked inside the string object source code, but I'd bet the implementations of .empty() and .clear() are similar to what I typed, and will likely be inline functions; whereas the overloaded == and = will call functions devised to operate with whole strings so they will include a loop (even when it doesn't iterate more than once).

[Data]

Japofran,
Yes you are right. empty and clear operations are most likely to be more efficient.