Dev-C++ has problem taking char array input
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
Hi
I have just written this code in Dev-C++ and seem to have issue with getting StudentNames if they are more than one word, for example, 'Irtaza Ali', 'Tom Hanks', 'Lahore City'.
I know that 'cin' works fine but it only accepts one word.
//////////////////////
// Code Starts here //
//////////////////////
include<conio.h>
include<iostream>
include<fstream>
include<stdio.h>
define avg(x,y,z) (x+y+z)/3
using namespace std;
void display();
struct student{
int stdid;
char stdname[20];
float average_score;
};
int main()
{
std:ofstream file;
student students[5];
float subj1,subj2,subj3;
file.open("student.txt");
for(int i=0;i<=1;i++)
{
cout<<"\n Enter student id :";
cin>>students[i].stdid;
cout<<"\n Enter student name :";
gets(students[i].stdname);
cout<<"\n Enter subject1 marks :";
cin>>subj1;
cout<<"\n Enter subject2 marks :";
cin>>subj2;
cout<<"\n Enter subject3 marks :";
cin>>subj3;
students[i].average_score=avg(subj1,subj2,subj3);
file<<endl<<students[i].stdid<<"\t"<<students[i].stdname<<"\t"<<students[i].average_score;
cout<<"\n Record saved";
}
file.close();
display();
getch();
return 0;
}
void display(void)
{
ifstream file;
file.open("student.txt");
cout<<"\n The data saved is ";
cout<<"\nStId StName Average";
char bup[80];
while(!file.eof())
{
file.getline(bup,80);
cout<<endl<<bup;
}
file.close();
}
////////////////////
// Code Ends here //
////////////////////
now tell us why this should be a problem of dev-c++?
This is because cin stops extracting characters from the input stream whenever it encounters a whitespace character (space, tab, newline, carriage return, etc).
So trying to enter “My Name" will only extract "My" since the next character is a space character.
If you want to get a whole line consider using getline().
Alternatively, break up data entry into first name, last name. As well, the space allocated for student name (20 char) is pretty small and you will corrupt memory should you enter a name longer than 19 characters.
The 'stand-alone' getline() function is defined for string (whereas istream::getline() is only defined for char*. Using getline() and the string class will overcome both the problem you are seeing and the potential buffer overrun.
Note that the is not an issue with Dev-C++ (or the compiler or library); it is the defined behaviour of the ISO C++ istream::operator>>() function.
When your code behaves in a way you do not expect, it is always more likely to be an issue with your code than the compiler or library. Get yourself a good reference.
Clifford
This code runs fine in other C++ IDEs. Please note this code was part of an assignment which required StudentName to be of char[20] and allow multiple words in it.
There are a lot of workarounds to use string or fetch char by char, but it doesnt make sense when a piece of code can run in one IDE and not in the other.
getline() is not an option for me as I have to get char[20] input, but surely is a solution.
Just let me know if Dev-C++ supports using gets() then how can it be used for multiple words.
<<When your code behaves in a way you do not expect, it is always more likely to be an issue with your code than the compiler or library. Get yourself a good reference. >>
True, but when that same piece of code behaves fine in one IDE and not in the other, what do you expect is the first reaction?
The first reaction is that Dev-C++ has a serious bug.
Either you are mistaken, or whatever compiler you have previously used was incorrect (it has nothing to do with any 'IDE', and IDE is not the same thing as the compiler or even the library - and it is teh library that is at issue here.
See http://www.cplusplus.com/ref/iostream/istream/operatorgtgt.html for details of the istream extraction operator (>>) - (note cin is a global object of type istream). It clearly states for char* types - "...Extraction ends when the next element is either a valid whitespace or a null character..."
Of course gets() is available, it is a standard ISO function - surely just trying it would have been quicker than asking? However DO NOT use it! There are three reasons for this:
1) Mixing stdio with iostream access to the same resource is not wise (or necessary).
2) gets() is intrinsically unsafe, fgets() on stdin is preferred if you must.
3) istream::getline() is equivilent to fgets(), and should be used instead when using istream objects. Note this is std::istream::getline() which is defined for char*, and not std::getline() which is defined for string.
The line:
gets(students[i].stdname);
Should read:
cin.getline( students[i].stdname, 20 );
Althought the "20" would better be replaced with a const:
const streamsize max_stdname_len = 20 ;
Then use max_stdname_len for both the array declaration and the istream::getline() call. You could also use sizeof( students[i].stdname ) or sizeof( student::stdname ), but both of these would fail if you ever changed student::stdname to a pointer rather than an array.
The point is that istream::getline() is 'safe' so long as you ensure that the buffer length parameter is always correct, wheras std::getline() is safe regardless because string types can automatically resize.
Clifford
> This code runs fine in other C++ IDEs.
bu*, an IDE doesn't compile or run a program itself, either this is really compiler-specific or you have a serious problem in your code. In any way, it is certainly not IDE dependent.
However, it IS possible, that some earlier versions of gcc show such problems
that's a very good point, anybody who follows the GCC DEVEL mailing lists, knows that the people who find actual errors in gcc (the compiler) are incredibly clever folks who often know the whole C++ ISO standard, and have often years of experience in software development, as well as C++ in particular.
That is, even as an accomplished programmer you are relatively unlikely to find (new) bugs in gcc.
Or, in my case, that could be worded as the probablility that Wayne did something wrong over the probability that the compiler fouled it up is a number that, while not quite infinite, is within a short drive of it.
Wayne (core dumps while you wait)
I think the subject line is confusing everyone here with the compiler have a 'major bug'. Please know that not all problems are 'major bugs'.
The problem here was to use gets() in the Dev-C++ just like its used in other IDEs (or compilers).
I would agree for the following statement as a solution,
cin.getline( students[i].stdname, 20 );
but unfortunately it doesnt work.
I believe rather than focusing whether this is a compiler issue or not (which is not the topic here) its better to focus on the solution that could run on Dev-C++ with an input being taken for a char array.
If you have found that it does not work, it is because your code is incorrect. You are not helping yourself by not posting the code modified code, or by insisting that other compilers work with this code without specifying which.
In the original question it was not clear at all that you wanted to make gets() working. You only mentioned a problem with cin. You posted code which used gets(), but I assumed that was just your ill-advided workaround.
I suggest that you re-post the full code implemented with istream::getline() (because that workd be the preferred approach given the nature of teh rest of the code), then lets go from there.
Think about it - you cannot make cin work and you cannot make gets() work. Have you ever considered 'is it me?' rather than blaming the compiler. Did you really try this exact code in this mysterious 'other compiler' which you continue to errornously keep referring to as an IDE.
You have simply stated that the solutions offered do not work without describing the nature of thier failure - this ia not helping to get you an answer. However, looking at your original code again, I see a flaw unrelated to the string input method (although gets() is a really bad choice nonetheless): The non-string formatted inputs (student ID, and subject marks), only consume the buffered data appropriate to their data type. This leaves any 'junk' data in the buffer - this includes the 'newline' character that inevitably exists because you have to press 'ENTER' to commit the input. This 'newline' character will form input for the next istream operation - terminating the call before any additional data is entered. This problem can be solved using istream::sync().
Try this, I tested it, it works:
//////////////////////
// Code Starts here //
//////////////////////
include <iostream>
include <fstream>
using namespace std;
define avg(x,y,z) (x+y+z)/3
void display();
struct student
{
int stdid;
static const int max_student_name_len = 20 ;
char stdname[max_student_name_len];
float average_score;
};
int main()
{
ofstream file;
student students[5] ;
float subj1, subj2, subj3 ;
}
void display(void)
{
ifstream file ;
file.open( "student.txt" ) ; cout << "\n The data saved is " ; cout << "\nStId StName Average" ; char bup[80]; while(!file.eof()) { file.getline( bup, 80 ) ; cout << endl << bup ; } file.close();}
////////////////////
// Code Ends here //
////////////////////
Clifford
How does it not work?
You can also do
char student[20];
gets(student);
If you follow the thread, you will see that not only was that exactly what he had done in the first instance (in the code), but I later expliained why it was a really bad idea.
Clifford
NO, you are missing the point: nothing's gonna "run on Dev-C++".
To the original poster:
It really, REALLY helps when solving a problem like this to NOT say something like "it doesn't work", and instead, ALWAYS post back
(1) The EXACT code that you tried to compile. Copy and paste. NEVER retype into the post.
(2) Your full compile log. NEVER excerpt the errors - if you have a ton of errors, post from the beginning of the log through the first 5 or so errors.
(3) Any further information - such as any run-time errors.
When you post this information, then those helping you can see exactly what you compiled, and exactly how it was compiled. This provides something to go on, whereas "it didn't work" really doesn't.
(Note also - NEVER say something like "I compiled exactly what you gave me - copy and paste it back out of Dev-C++)
Wayne
"True, but when that same piece of code behaves fine in one IDE and not in the other, what do you expect is the first reaction?"
Generally, code that compiles and run correctly on one or more compilers/IDEs/computers, but not on others is, in my experience, buggy. Not the compiler/IDE - my code.
It is NOT true that code that compiles and runs successfully on one or more setups is "correct". I can not tell you how many times I have written code with subtle memory bugs that would compile and run fine for a while, then stop working when I added a line of code having nothing to do with the error.
In short - in 30 years of writing code with bugs in it (some sub-moronic ones too) - I have learned to avoid the fallacy of the logical premise of "My code worked on X and Y, but not on Z, so there must be something wrong with Z"
Wayne
p.s. Note that the compiler that Dev uses, GCC, is an industry standard compiler, used very heavily in the community. The idea that a user would pop in and find a "major bug" in it - well that should not pass the "sanity" test.
slocombe your code works fine with cin.getline. But the reason why it didn't work for me the first time was the syntax 'cin.sync()'
I have tested it with and without the cin.sync() statement and it only works fine when the cin.sync() statement is executed before taking an input.
I dont understand why you guys seem to point every issue towards the compiler. I used to program using Borland C++ and MS Visual C++ before I moved to Dev-C++. By far I have found it the most easy-to-use tool.
As drwayne, I didnt have any compile errors and neither did I mention that in the post. I only had said that Dev-C++ has problem taking char input (and not the compiler)... since I didnt know why the code was working fine in Borland C++, MS Visual C++, and my all time favorite Turbo C++... I couldnt figure out what was wrong with the code.
My first guess was the header files conflicting with each other as mentioned by "Mixing stdio with iostream access to the same resource is not wise (or necessary)." But that did not provide any change to the result.
For your 3 pointers
1) EXACT code was posted not retyped.
2) No Errors; just didnt function right... maybe I should have not missed out the word 'code' and had the subject line to read ' CODE in Dev-C++ has problem taking char array input'..... does that sound better. Now please dont take it as the code used to develop Dev-C++ but the code written by me.
3) With and without the cin.sync() my output looks like this
///////////////////////////////
// OUTPUT without cin.sync() //
///////////////////////////////
Enter student id:1
Enter student name:
Enter subject1 marks:84
Enter subject2 marks:85
Enter subject3 marks:56
Record saved
Enter student id:2
Enter student name:
Enter subject1 marks:84
Enter subject2 marks:85
Enter subject3 marks:56
Record saved
////////////////////////////
// OUTPUT with cin.sync() //
////////////////////////////
Enter student id:1
Enter student name:First Test1
Enter subject1 marks:84
Enter subject2 marks:85
Enter subject3 marks:56
Record saved
Enter student id:2
Enter student name:Second Test2
Enter subject1 marks:84
Enter subject2 marks:85
Enter subject3 marks:56
Record saved
/////////////////////////////////////////
The output came from the same code posted by slocombe's code where one was without cin.sync() and the other was with it (as is posted).
Apparently now the "gets(student[i].stdName];" also works when I run the cin.sync() statement before it.
Now what is the primary function of cin.sync(). Is it something like DoEvents for Visual Basic (im just guessing here.)
Anyways a lot of thanks for the posted code.
>> But the reason why it didn't work for me the first time was the syntax 'cin.sync()'
Of course, that's exactly what I said was the solution - why do you sound surprised?
>> I don't understand why you guys seem to point every issue towards the compiler.
I am not sure what you mean; but the compiler is what translates your source into machine executable code. The IDE is little more than a text editor that knows how to invoke the compiler. It only passes to the compiler the source you specify, garbage-in-garbage-out. In the end your code would be more robust is you enetered everything with istream::getline(), since you could then validate the input before converting it to the appropriate type (using an istringstream object for example). When using istream::getline(), the istream::sync() call is unnecessary because istream::getline() consumes the '\n'. The cin.sync() call I placed after the cin.getline() is somewhat redundant.
All the compilers you mentioned predate the ISO standardisation of the language and the library (especially TC++!), but nonetheless I am surprised, if it worked, it was at best non-portable.
You still seem somewhat confused between what exactly the difference between teh compiler an teh IDE is. It is true that most commercial compilers come with an IDE, but that are still distince entities.
stdio and iostream opened on the console are 'synchronised' by default, so operations can be mixed, but this behaviour can be modified, so code that relies on this may not be easily portable. See http://www.cplusplus.com/ref/iostream/ios_base/sync_with_stdio.html for details. But just as a matter of style it is poor, it exhibits a failure of understanding of iostream.
Clifford
"As drwayne, I didnt have any compile errors and neither did I mention that in the post."
Postiong the compile log does MUCH more that give us error messages. It enables us to see EXACTLY how the compiler was invoked. This is important both for subtle compiler issues (like the infamous -mwindows with a console application issue), as well as duplicating what you are doing, an absolute key to remote debugging.
By the way, the reason I put those disclaimers about not retyping etc, is that I have seen countless times where people do that. Keep in mind that a given thread, while it currently applies to you, will be read by others in the future, so it is important to include information like that.
Wayne