C++ Gurus, UNIX vs. Windows ascii problem perhaps?

This is a discussion on C++ Gurus, UNIX vs. Windows ascii problem perhaps? within the C++ Programming forums, part of the General Programming Boards category; Okay, I'm supposed to have their program run right on both the Unix platform and Windows platform. Now, it runs ...

  1. #1
    Registered User
    Join Date
    Mar 2003
    Posts
    4

    C++ Gurus, UNIX vs. Windows ascii problem perhaps?

    Okay, I'm supposed to have their program run right on both the Unix platform and Windows platform. Now, it runs fine on both, but the output is wrong on Unix. Now, I'm guessing that maybe the ASCII values are different from OS, and that's possibly my problem. Can anyone verify this?

    Here's the output that I get from Windows:
    Search string: the
    The string to search for is the
    The string size is 3
    Line Number
    ------------
    1 1
    2 0
    3 1
    4 0
    5 1
    6 0
    7 1
    8 0
    9 1
    10 0
    11 0
    12 0
    13 1
    14 0
    15 2
    16 0
    17 0
    And here's the output I get from Unix:
    Search string: the
    The string to search for is the
    The string size is 4
    Line Number
    ------------
    1 0
    2 0
    3 0
    4 0
    5 0
    6 0
    7 0
    8 0
    9 0
    10 0
    11 0
    12 0
    13 0
    14 0
    15 0
    16 0
    17 0
    And here's my code:
    Code:
    #include <iostream.h>
    #include <fstream.h>
    
    const int  LINESIZE = 45;
    
    int  TextEqual (char target[], char lineInput[], int stringNum, int stringSize);
    void ConvertLower(char target[], int size);
    
    int main()
    {
    	char	 userInput[LINESIZE];
    	char	 lineInput[LINESIZE];
    	ifstream inFile;
    	int		 lineCounter = 1;		// holds count of what line it's on
    	int		 stringNum = 0;			// holds count of string finds per line
    	int		 stringSize = 0;
    
    	inFile.open("EULA.txt");
    
    	// get string to search for and convert to lower case
    	// get number of characters in string
    	cout << "Search string: ";
    	cin >> userInput;	
    	ConvertLower(userInput, 45);
    	for (int counter = 0; counter < LINESIZE; counter++)
    		if ((userInput[counter] >= 97) && (userInput[counter] <= 122))
    			stringSize++;
    
    	cout << "The string to search for is " << userInput << endl;
    	cout << "The string size is " << stringSize << endl;
    
    	// print out heading
    	cout << "Line\tNumber" << endl;
    	cout << "------------" << endl;
    
    	while (inFile.peek() != EOF)
    	{
    		// get new line of data
    		inFile.getline(lineInput, 50, '\n');
    		ConvertLower(lineInput, 45);
    		
    		// prints line number and number of string finds		
    		
    		stringNum = TextEqual(userInput, lineInput, stringNum, stringSize);
    		cout << lineCounter << '\t' << stringNum << endl;
    
    
    		// increase the line position and set the number
    		// of string finds to 0
    		stringNum = 0;
    		lineCounter++;
    	}
    	
    	inFile.close();
    
    	return 0;
    }
    
    int TextEqual(char target[], char lineInput[], int stringNum, int stringSize)
    {
    	int numCorrect = 0;
    
    	for (int position = 0; position < LINESIZE; position++)
    	{	
    		if (lineInput[position] == target[numCorrect])
    			numCorrect++;
    		else
    			numCorrect = 0;
    
    		if (numCorrect == stringSize)
    		{	
    			numCorrect = 0;
    			stringNum++;
    		}	
    	}
    
    	return stringNum;
    }
    
    void ConvertLower(char target[], int size)
    {
    	for (int spot = 0; spot < size; spot++)
    		if ((target[spot] >= 65) && (target[spot] <= 90))
    			target[spot] = target[spot] + 32;
    }
    It's a very easy program, I'm just not sure about the differences from Unix to Windows, and vice versa. My problem is that Unix is saying the string is of length 4, but Windows says the string is of length 3. I used my own little for loop to determine how many characters are in the string based on their respective ASCII values. The TextEqual function relies on the size of the user inputted string. Any help?

    Thanks,
    -Steve

  2. #2
    Registered User xds4lx's Avatar
    Join Date
    Nov 2001
    Posts
    630
    Its the way the text file is stored under Unix that is the problem, try opening the text file in vi and you will see a ^M at the end of the lines its because the text is stored different. If you uploaded the text file using ftp make sure you set it to transer in ASCII mode and not binary mode.
    "only two things are infinite, the universe and human stupidity, and im not sure about the former." - albert einstein

  3. #3
    Registered User
    Join Date
    Mar 2003
    Posts
    4
    Originally posted by xds4lx
    Its the way the text file is stored under Unix that is the problem, try opening the text file in vi and you will see a ^M at the end of the lines its because the text is stored different. If you uploaded the text file using ftp make sure you set it to transer in ASCII mode and not binary mode.
    Hey mate, thanks for the help. I'm going to give this a try when I get off of work.

    Thanks!
    -Steve

  4. #4
    End Of Line Hammer's Avatar
    Join Date
    Apr 2002
    Posts
    6,231
    To expand:

    Unix uses bytes of value 0x0a to denote the end of a line. This is a line feed character.

    Windows uses bytes 0x0d 0x0a to denote end of line, this is carriage return / line feed. They have to be next to each other, in that order.

    If you create a file on one system, then transfer it to the other system using a binary mode FTP, the EOL markers are not converted and you start having trouble recognising them on the second system. When you use ASCII mode transfer, the EOLs are converted from the native format to that of the receiving system.
    When all else fails, read the instructions.
    If you're posting code, use code tags: [code] /* insert code here */ [/code]

  5. #5
    Registered User
    Join Date
    Mar 2003
    Posts
    4
    Originally posted by Hammer
    To expand:

    Unix uses bytes of value 0x0a to denote the end of a line. This is a line feed character.

    Windows uses bytes 0x0d 0x0a to denote end of line, this is carriage return / line feed. They have to be next to each other, in that order.

    If you create a file on one system, then transfer it to the other system using a binary mode FTP, the EOL markers are not converted and you start having trouble recognising them on the second system. When you use ASCII mode transfer, the EOLs are converted from the native format to that of the receiving system.
    Good stuff to know.

    BTW, the problem I'm having is with the input from the user not from the file itself. The method that I used to upload the file already uses ASCII mode transfer.

    The problem is that Unix is saying the is stored as 4 characters, and Windows is saying it's three. Three is the right amount. Any idea why its saying there is one extra than what it is supposed to? This is for a string thats inputted from the user, not from the input file.

    -Steve

  6. #6
    Registered User
    Join Date
    Oct 2001
    Posts
    2,934
    Try this (lines which were changed are commented).
    Code:
    #include <iostream.h>
    #include <fstream.h>
    
    const int  LINESIZE = 45;
    
    int  TextEqual (char target[], char lineInput[], int stringNum, int stringSize);
    void ConvertLower(char target[], int size);
    
    int main()
    {
    	char	 userInput[LINESIZE];
    	char	 lineInput[LINESIZE];
    	ifstream inFile;
    	int		 lineCounter = 1;		// holds count of what line it's on
    	int		 stringNum = 0;			// holds count of string finds per line
    	int		 stringSize = 0;
    
    	inFile.open("EULA.txt");
    
    	// get string to search for and convert to lower case
    	// get number of characters in string
    	cout << "Search string: ";
    	cin >> userInput;	
    	ConvertLower(userInput, 45);
    	//for (int counter = 0; counter < LINESIZE; counter++)
    	for (int counter = 0; userInput[counter]; counter++)
    		if ((userInput[counter] >= 97) && (userInput[counter] <= 122))
    			stringSize++;
    
    	cout << "The string to search for is " << userInput << endl;
    	cout << "The string size is " << stringSize << endl;
    
    	// print out heading
    	cout << "Line\tNumber" << endl;
    	cout << "------------" << endl;
    
    	while (inFile.peek() != EOF)
    	{
    		// get new line of data
    		//inFile.getline(lineInput, 50, '\n');
    		inFile.getline(lineInput, 45, '\n');
    		ConvertLower(lineInput, 45);
    		
    		// prints line number and number of string finds		
    		
    		stringNum = TextEqual(userInput, lineInput, stringNum, stringSize);
    		cout << lineCounter << '\t' << stringNum << endl;
    
    
    		// increase the line position and set the number
    		// of string finds to 0
    		stringNum = 0;
    		lineCounter++;
    	}
    	
    	inFile.close();
    
    	return 0;
    }
    
    int TextEqual(char target[], char lineInput[], int stringNum, int stringSize)
    {
    	int numCorrect = 0;
    
    	//for (int position = 0; position < LINESIZE; position++)
    	for (int position = 0; lineInput[position]; position++)
    	{
    		if (lineInput[position] == target[numCorrect])
    			numCorrect++;
    		else
    			numCorrect = 0;
    
    		if (numCorrect == stringSize)
    		{	
    			numCorrect = 0;
    			stringNum++;
    		}	
    	}
    
    	return stringNum;
    }
    
    void ConvertLower(char target[], int size)
    {
    	//for (int spot = 0; spot < size; spot++)
    	for (int spot = 0; target[spot]; spot++)
    		if ((target[spot] >= 65) && (target[spot] <= 90))
    			target[spot] = target[spot] + 32;
    }
    You can also use the function strlen() to get the length of a char array. To use include <cstring>

  7. #7
    Registered User
    Join Date
    Mar 2003
    Posts
    4
    The strlen() function worked great! I couldn't remember which header file had a function that returned the length of an array.

    -Steve

    P.S. The edits to the program you made allowed the length to process correctly, however, there are now issues with the number of lines. I'll work that out. But right now, my program works fine on both Unix and Windows. Thanks for the cstring suggestion 'bro.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Strange windows STL crashing problem
    By kdmiller in forum C++ Programming
    Replies: 5
    Last Post: 06-23-2010, 02:25 PM
  2. Codec Bitrates?
    By gvector1 in forum C# Programming
    Replies: 2
    Last Post: 06-16-2003, 08:39 AM
  3. FlashWindowEx not declared?
    By Aidman in forum Windows Programming
    Replies: 3
    Last Post: 05-17-2003, 02:58 AM
  4. SDI Menu problem - Windows MSVC 6.0
    By Brown Drake in forum C++ Programming
    Replies: 0
    Last Post: 10-13-2001, 06:04 AM
  5. Problem with Borland 5.5 Compiling Windows Programs
    By Unregistered in forum C++ Programming
    Replies: 3
    Last Post: 08-28-2001, 09:04 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21