end of line counting

dukemarlon
dukemarlon used Ask the Experts™
on
I'm writing a programm in C++, and I need to know how to count the number of end-of-line characters in a .dat file. I would apreciate a speedy response. Thanks!
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Commented:
You can use the getline function to read the file into a string, and then use count to get the quantity of end line characters in the string.

Example:
std::string dummystr;
std::getline(file, dummystr, file.widen('\255'));
int QtyEndLine = std::count(dummystr.begin(), dummystr.end(), '\n');

Commented:
int main(int argc, char* argv[])
{
     ifstream file;
     file.open("readme.txt");

     std::string dummystr;
     std::getline(file, dummystr, file.widen('\255'));
     int QtyEndLine = std::count(dummystr.begin(), dummystr.end(), '\n');

     
     std::cout << "Found " << QtyEndLine << " EndLine charcters." << std::endl;
     return 0;
}

Commented:
if you are reading things in character by character,
(i.e.) cin.get(char_variable)
then you should just use a loop to control getting the
characters.  Then just put in an if statement like:

if(char_variable == '\n')
{
      linecounter++;
}

just make sure you check for end of file also
OWASP: Forgery and Phishing

Learn the techniques to avoid forgery and phishing attacks and the types of attacks an application or network may face.

Intern, I think a better way to do this is to transfer the char's ASCII value into an int and then compare it to the decimal representation of the line feed character. For example:

int x = char_variable;

if( x == 13 )
{
      linecounter++;
}

Commented:
Exceter, either way yields the same results.

But your way will cause the computer more work than needed.
There is no need to turn the end of line character into an integer, other than simplicity.

I see your point though.
Why would my way make it work harder?

Commented:
>>Why would my way make it work harder?

Your method adds an extra variable, in which you have to transfer the data.
Your method also makes a comparison to a number instead of a character.
The character method is easier to follow then a number method.

So your method is more work to execute, more work to compile, and more work to maintain.

Commented:
Exceter,
Your method seems to be a loose loose situation.

How exactly do you think your method would improve the code?
Axter, it probably would not improve the code at all in this situation.

Commented:
Axter, Exceter.. similar nicks :)

I don't know which one would yield better machinecode. That is up to compiler implementation. But Exceter's way doesn't have to be more to execute. I have looked code generated by several C compilers for Motorola 68000 and Exceter code could in fact execute faster in the processor above.

For Intern's way:

if(char_variable == '\n')

the char_variable would get extended to MC68000's natural word which is 16-bits.

ext.w d0         ; extend char_variable
move.b #13,d1    ; load d1 with '\n'
ext.w d1         ; extend
cmp.w d0,d1      ; compare d0 < d1
bne.s jump

*********************

For Exceter's way:

int x = char_variable;
if( x == 13 )

The compiler might generate

ext.w d0         ; extend char_variable
move.w d0,d2     ; x = char_variable
cmpi.w d0,#13    ; x == 13
bne.s jump

*********************

I mean it could generate this way. It doesn't have to.


Commented:
>> mean it could generate this way. It doesn't have to.

It could not generate this way.
The compiler interpret '\n' and 13 as the samething.
So what it would do with a comparison to 13, it would also do with a comparison to '\n'.

Furthermore, you're missing the variable initialization routine, and variable memory allocation requirements for the extra variable 'x'.

I'm sorry, but your example doesn't come close to a real world generation of the compiled code.
If you do compile to 68000, then you should be able to fetch the code, and show the difference, instead of speculating what it might be.

Commented:
Of course I am speculating! That is the very first assumption you should make once you see my nick.

But it could generate like that as '\n' is a char and it could get compiled as a byte. Then it would get extended to 16 bits before it is compared. It was long time since I looked into disassembled C-code on MC68000, but I seem to recall that char constants was compiled as byte.

So basically, I am speculating once again. Any problems with that?

Commented:
>>But it could generate like that as '\n' is a char and
>>it could get compiled as a byte.
>>So basically, I am speculating once again. Any problems
>>with that?

I suggest that you read the C/C++ standard before making further speculations.

According to the standard an integer character constant is a sequence of one or more characters enclosed in single-quotes, as in 'x'.

So according to the standard a character constant in single-quotes is an INTEGER.

It's better to give advice by using concrete data, instead of speculation.  Especially when contridicting another expert.

Commented:
Oh I am so sorry. But what standard says and what some compiler vendors implements don't always match. I have seen some compilers treat char constants as bytes and that is what I am giving information about. Now there is no need to get upset. I was just mentioning that fact. Before you refer to C/C++ standard, look into ALL compilers generated code before you can say I am totally wrong and you are totally right. That is not doable so you are speculating as well.
what's your opinion about this?

char target[1000];
.
.
.
char *temp;
int lineCounter=0;
temp=strstr(temp,"\n");
while(temp!=NULL)
{
   lineCounter++;
   temp=strstr(temp,"\n");
}
cout<<lineCounter;

look, you can search for (char)13 and count this, but in MS-DOS (or MS-Windows) systems, (char)13 and (char)10 means end of line, not (char)13 only.

So, if you want to developing software in Windows platform i recommend you search for "\n"(this is string, not character).

Regards

Commented:
since 13 is always included in end of line, why not just check that character? To check one character should go faster than checking two?

Commented:
>>Before you refer to C/C++ standard, look into ALL
>>compilers generated code before you can say I am
>>totally wrong and you are totally right. That is not
>>doable so you are speculating as well.
I'm telling you, that there is not compiler that will treat a constant single quote character as a byte, unless the integer type is a byte size.
Until you can find such a (C/C++) compiler, you can not say I'm wrong.  (Which I know you will not find one)

Commented:
This question didn't show any activity for more than 21 days. I will ask Community Support to close it unless you finalize it yourself within 7 days.
You can always request to keep this question open. But remember, experts can only help if you provide feedback to their comments.
Unless there is objection or further activity,  I will suggest to accept

    "Axter"

comment(s) as an answer.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
========
Werner
Force accepted

** Mindphaser - Community Support Moderator **

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial