I am learning C++ and was writing a simple program when I noticed that declaring a stack caused cout to not output to the terminal. Here is my program:
#include <iostream>
#include <stack>
int main ()
{
std::stack<int> myStack;
std::cout<<"Hello World!"<<std::endl;
return 0;
}
This problem only occurs in the Visual Studio Code editor. If I use an online C++ compiler, there are no issues and I see "Hello World!" as output. If I remove the declaration of the stack, the output is also normal, even in VS Code. However, when the declaration is present, I see no output when I compile and run my code in VS Code. I have no idea why this would be the case, and other STL containers (I've tested vector, array, and set) do not cause a similar issue, although the problem still occurs when queue is used.
Any help resolving this issue, or any insight as to why it occurs in the first place, would be greatly appreciated.
p.s. This is my first time asking a question, so I apologize if it is poorly written.
Related
I'm using the g++ compiler and used the https://code.visualstudio.com/docs/languages/cpp guide to install everything. Never had any sort of problem.
I can initialise a vector from the standard library, but as soon as I attempt to initialise it with values, or add to it, or print its size after adding to it, I get a blank line in the console. There is no compilation error and i've tried compiling with the -std flag as 'c++11' and 'c++17'. The odd thing is that even if I put a cout statement before I add to the array, then it won't even output anything - it's like it just halts the whole program.
I am using vscode, and I've read of vaguely similar issues but none of the problems are identical and none of the solutions have worked. My code is below:
Imports:
#include <iostream>
#include <limits>
#include <vector>
#include <string>
Main function:
int main()
{
std::cout << "BEFORE";
std::vector<int> data;
std::cout << data.size(); // Sometimes outputs 0 if the vector is not modified but prints nothing if it is(even after the statement)
data.push_back(20);
std::cout << data.size();
std::cout << "AFTER";
}
Output:
UPDATE: Flushing the buffer and updating mingw haven't changed anything.
Thanks to #n. 1.8e9-where's-my-share m. I was able to find an answer. The problem was to do with Vscode not being able to display the vector. I ran the compiled .exe using the mingw64 console (outside of vsc, not the internal one) and it produced the correct output.
I have been coding for quite a few years now, but have only just recently started getting into C++.
I have already made quite a few programs in it, but have recently started running into some odd behaviour. The cases are simple enough that I expect this to be an error with my environment, and not the language itself, but I have run into a dead end.
Consider this simple program:
#include <iostream>
using namespace std;
int main() {
cout << "Test" << endl;
return 0;
}
If I compile that and run it, I get, as expected, "Test", in my console.
Now, if I add a vector to it:
#include <iostream>
#include <vector>
using namespace std;
int main() {
cout << "Test" << endl;
vector<double> whatever;
return 0;
}
For some reason, I do not get any output from that.
I have tried initalizing the vector as an empty vector aswell as with predefined values.
I tried adding a for loop running from 0 to 2^32 to see if the program failed entirely, or if it is just the output. This is where things got even weirder.
At first, I placed the loop before defining the vector; that caused the cout to suddenly work again (i.e. "Test" was printed in the console), aswell as stalling the program as expected. I then moved the for loop to after the vector definition, and then it broke entirely; I received no output, and the program exited almost instantly without error.
The issues persist when I remove the using namespace std; and prefix my cout and vector with std::
I use the g++ v6.3 compiler from MinGW. I am running Windows 10.
I am aware that this problem is probably extremely hard to reproduce, but I'll try my luck here before throwing my computer out the window.
Thanks in advance.
Edit: I fixed the issue by using Cygwin instead of MinGW. I will leave the question open in case someone has encountered a similar issue and has a fix that doesn't involve abandoning MinGW
I am running Linux and ran the code, and it ran successfully.
So this must be a compiler issue.
Maybe try using a different compiler like Cygwin / Microsoft Windows SDK.
Recently I'm working on my toy final c++ project, which will read content from a file at the begining and then process it.
Here's the simplified code.
#include <iostream>
#include <fstream>
//using namespace std;
struct command{
int a;
};
command read[1];
int main() {
std::ifstream fin;
fin.open("123.txt");
if (!fin){
std::cout << "failed" << std::endl;
return 0;
}
char c;
fin >> c;
std::cout << c;
return 0;
}
It works fine with Visual Studio 2019. However, when I'm trying to use devc++ 5.11 TDM-GCC 4.9.2, a strange bug happens. I get a segmentation fault on line fin>>c;, with return code 3221225477.
With great effort, the easiest way to make this code works is changing the identifier read to names like reading or whatever. Besides, moving the line command read[1]; into main function also helps.
My questions are:
Is it a behavior related to the compiler? MSVC is fine but GCC 4.9.2 is a little bit old or ...?
Does the identifier read conflict with something in my code? Why does it not a compile error but a segmentation fault?
Why does moving the declaration of read into main function help?
Update:Thanks for tips and I removed using namespace std. I think it has something to do with ifstream, because just std::cout<<"hello world"; works.
-Wall -Wextra provides no warnings.
GCC compiler is stricter than other compiler.
According to tadman's describe, we can guess there's read symbol in namespace std.
So you put it out of main,it's a conflict, you put in the main, it become a local symbol.
There is very likely a collision happening between your read and another in the global namespace. Not all compilers handle this situation the same way, but you can always avoid it if you are careful.
Visual Studio's Intellisense (or whatever alternative you prefer) can help you identify what symbol your read is colliding with. To do that, scope or comment out your code, then start typing "read". If there's another read in your scope, you'll likely see it and be able to get information about it.
This is one of the reasons I don't like using namespace std;. It pollutes your global namespace with a bunch of stuff and increases your chance of collision with a standard library identifier.
I can't get my following c++ program compiled in Visual Studio 2010. I already have a working build of the same code so I know the code is correct. But I have no idea with what or how it was compiled.
So I would appreciate if someone could just copy the code and try to compile it in VS 2010.
Code:
http://codepad.org/4VtrVBdK
new:
Ok, I did editing according to the comments below. Now the only problems that seem to have remained are related to calls to the overloaded functions. So how to go about it?
so I know the code is correct
What you "know" is false. The code is wrong in many ways. Here is but one example:
for(unsigned int i=0;i<GPNO;i++) //SORTING ACCORDING TO FITNESS
for(unsigned int j=i+1;j<GPNO;j++)
if((gp[i]->fitness)>(gp[j]->fitness))
{
gp[i]->mycopy(tmp);
gp[j]->mycopy(gp[i]);
tmp->mycopy(gp[j]);
}
for(i=1;i<=no;i++)
{
gp[i]->mycopy(gp[GPNO-i]);
}
In the second for loop, i is undeclared. I suspect the original compiler was VC6, which allowed this.
Another problem is the way you're calling pow. You call it with macros (which are patently evil for this purpose), for instance:
pf[i].frq+=(unsigned int)pow(2,2*PF-1);
And the compiler doesn't know which version of pow you had in mind. Case in point for macros being evil for this purpose. Do this:
pf[i].frq+=(unsigned int)pow(2.0,2*PF-1);
Or better yet, get rid of the macros.
Another example of your code being wrong:
#include "stdlib.h"
#include "conio.h"
#include "math.h"
None of these includes are part of the Standard. If you can get them to compile, its only because your compiler was anticipating your mistake. But it's still a mistake.
Looks like you're missing using namespace std;
This works fine:
std::vector<int> v;
v.push_back(123);
but this throws a std::length_error:
std::vector<uint32_t> v;// or vector<unsigned __int32>
v.push_back(123);
It seems to be triggered by resizing, because
std::vector<uint32_t> v;
v.reserve(2);
triggers a debug assertion "iterator not dereferencable".
This occurs on Visual Studio 2008, but the same code works fine on Mac and Linux. Can anyone suggest a way to narrow down the search for an explanation?
UPDATE:
The rat's nest of static and dynamically linked dependencies in this project made it too time-consuming to find the offending library. I gave up and rebuilt every dependency from source. I lost two days of my life and still don't know exactly where the problem was, but the app runs! Thanks for your help.
This
#include <iostream>
#include <vector>
int main()
{
std::vector<unsigned __int32> v;
v.reserve(2);
std::cout << v.capacity() << '\n';
return 0;
}
runs without any hiccups for me in VS 2008. It prints 2.
What does this do for you? If it works, too, then my first few guesses are:
You invoked undefined behavior somewhere before. By the time execution gets to the code you showed, all bets are off.
This is across DLL boundaries and you linked together DLLs/EXE built with different settings.
The way to find out about this is to distill it down to the smallest possible test case exhibiting the behavior. (That shouldn't contain more than 50LoC, ideally, it's 10.) If you don't find the problem while doing so, append the example to your question.
Since the sample code is working, your sample must be wrong :-)
Try to get closer to the problem by making your sample more like the real code in small steps. At some point it should stop working and then you can identify the culprit.
Can you check if your implementation has two or more typedefs of uint32_t? Especially under different namespaces? (I know the chances are pretty slim, but it might be worth it - in the quest for platform compatibility, different libraries try to map a specific memory size to a type, and one of them might have slipped up).
VC++ 2008 does not provide an ISO C99 header, so you must have provided the definion somehow; perhaps the definition is flawed.