somefile.cpp:1216:12: error: no match for 'operator>>' (operand types are 'std::basic_istream<char>::__istream_type {aka std::basic_istream<char>}' and '<unresolved overloaded="" function="" type="">')
ifs >> n >> std::endl;</unresolved></char></char>
ifs is std::ifstream.
used to work in 4.x 5.x dropped it maybe, 6.0 and up definitely gone.
throws lots of errors.
test rig compile: g++ -static -o ifstream-std-endl.exe ifstream-std-endl.cpp
gcc (i686-posix-sjlj-rev0, Built by MinGW-W64 project) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
the .txt file is a text file with some numbers in it for sample
Dude, did you read the response to https://sourceforge.net/p/mingw-w64/bugs/663/ ??? NO, it wasn't there in 4.x (in fact to placate you, I just tried under 4.9.3 and it doesn't compile). There is not and never has been an extraction manipulator std::endl for std::istream. (If you don't know what "extraction manipulator" means, what are you doing programming C++?!?!?) If you have ever run across code like this, it was compiled using a compiler that supports it as a non-standard extension. (Note: MSVC 2008+ doesn't have this extension). This is the same bug (663) you reported 5 days ago (BIG HINT: ifstream is derived from istream, and if you knew C++ you would know THAT as well).. Regardless, this would be something to report against the standard C++ library group of the compiler.
It took me about a minute to figure out you don't know what you are doing, and at first I thought it was because you were learning. That's fine, we all were at that stage at one point, and gcc and the toolset is an insanely complicated piece of software (anybody else here remember the pains of the unification of egcs and gcc 2 ????). BUT, part of the learning process is also learning where the appropriate place to ask for help is.You have shown a lack of grasp of how to even run the toolset (your invalid command line argument bug report), minunderstandings and flat out incorrect code (your not understanding how overloaded insertion operator bug report), and the inability to create a decent bug report, which ANY programmer or QA person knows how to do, especially when making a report to a third party (specifically your bug report about not being able to say what's wrong but look for exponent sign changes..WTF). In addition, you have failed to grasp the difference between the build toolset (gcc/binutils) and the runtime for windows (this project), and which place to make your bug reports or queries for help. I know I have at least on one occasion told you that parser error reports BELONG TO THE GCC FOLKS, THEY MAKE THE COMPILER PROPER (parser, lexer, instruction scheduler, etc). Sure, several of us in this project have had a hand in helping make those tools for the windows target, but that is not actually this project.
I have actually been giving you the benifit of the doubt here, but it has become obvious that you are not listening. You obviously don't understand the toolset you are using and you obviously don't know the language that you are programming in. I am usually against banning someone because generally, they will take the direction (go to a help group, report bugs against the correct tools, etc), but for the reasons given in response to your report in https://sourceforge.net/p/mingw-w64/bugs/659/ I am now in the camp that is in favor of that ban. As a side note, I've been doing this a looooong time. To be honest, if I were your boss and you were working on "commercial code" as you say in several of your reports, I would at the VERY least assign you to a project that did not in any way involve programming, if not flat out terminate your employment. It would have taken me about a day to make this decision. None of this is meant to be a slight against you as a person, I'm sure you're a really nice guy...it's just an observation based on your public reports here about your skills at whatever it is you do.
maybe I was thinking of DJGPP... more like 4.9.0 and it did. it's a was, not a now. and because it used to be, and was taken away, it should be back, because this provides formatting if input!
NOW, JUST STOP.
1) DJGPP is NOT this project so its behavior is irrelevant.
2) This is not standard C++, and never has been. Therefore the expectation for a non standard syntax to compile is wrong
3) SYNTAX ERROR MESSAGES ARE GCC ISSUES, POST YOUR BUG FOR THOSE THERE.
4) STANDARD C++ LIBRARY BUGS BELONG TO GCC NOT HERE.
5) FINALLY, It was not in 4.9.0; 4.8.1 didn't have it: