I have the following code:
#include <iostream>
using namespace std;
Sum (int a, int b)
{
int x = a - b;
//cout << x << " \n";
return x;
}
int main()
{
int s1 = Sum(3, 6);
cout << s1;
return 0;
}
System info:
Win 7 Sp1 x64 Ultimate/Professional or Win 8.1 x64
Code Blocks 16.01 MinGW
Debugger name and version: GNU gdb (GDB) 7.6.1
compiler: GNU GCC Compiler
This code compiles with no problems, but this IS the problem, there should be errors.
1) Function Sum, has no return value, on http://cpp.sh/ it doesn't let me compile because of this.
2) Variable's s1 value is -3 whether I write "return x" or not.
It somehow passes the value of x everytime BUT if I uncomment the cout statement above the "return x" everything starts to work out as expected, what the hell :) --> s1 will have a random value when no return statement is in place (because it was not initialized prior to being used for the function call) and -3 when the return is there.
I've tried this on 3 separate computers and they all exhibit the same behaviour. So I don't think the machine is the problem.
I also tried using a different compiler but I don't know if I configured them correctly and they don't have a debugger right ? I tried Borland c++ and Digital Mars. Borland has a new version 10.1 instead of the 5.5 that codeblocks supports and I couldn't make the new one work.
I don't even know if this is a compiler or program issue ?
I'm trying to learn C++ and this is very annoying. Our teacher is using the same software in class but on Linux and it works perfectly.
Off topic: Is there a way to insert code with line numbers here ? First post here so i'm still new at this :).
Thank you !
Go to "Project" -> "Build Options" -> "Compiler Settings" tab -> "Compiler Flags"
And disable -fpermissive
-fpermissive Downgrade some diagnostics about nonconformant code from errors to warnings. Thus, using -fpermissive will allow some
nonconforming code to compile.
Or disable it using pragma on the top of your code:
#pragma GCC diagnostic ignored "-fpermissive"
Also you could try to add the flag "-pedantic" in "Compiler Flags" tab
BTW:
If you try online:
#pragma GCC diagnostic error "-fpermissive"
using namespace std;
Sum (int a, int b)
{
int x = a - b;
//cout << x << " \n";
return x;
}
int main()
{
int s1 = Sum(3, 6);
cout << s1;
return 0;
}
You got exactly same behavior you described!
As Rama said, you might have enabled -fpermissive in your codeblock.
Go to "Project" -> "Build Options" -> "Compiler Settings" tab -> "Other options" and delete -fpermissive.
Related
I have tried working with the command line arguments in a small C++ program on Amiga 1200 (Workbench 3.1.4).
I have compiled with the use of bebbo’s cross-compiler g++ (m68k-amigaos-g++) (see https://github.com/bebbo/amiga-gcc) a simple CLI app that just outputs the arguments. While it works fine when compiled with 'normal' g++ in Windows, it failed in AmigaShell in Amiga Forever emulator and Amiga 1200 machine as well.
I have found on some forums that the preprocessor symbol __stdargs should be used, which as I understand instructs the compiler to handle the generated assembler as if the function was called with the parameters passed on stack and not with the use of registers. Is that correct understanding?
Is the normal that Amiga (and g++) by default use registers and it needs to be overridden for AmigaShell? I added that to __stdargs to the main() function. Anyway, that did not help.
Next, I have read, again on some forum, that -mcrt parameter has to be used when compiler output is linked. I have struggled to find the purpose do the parameter. It seems it specifies which standard C library (similar to glibc) to be linked? According the Google the following possible variants of the parameter (-mcrt=nix13, -mcrt=nix20, and mcrt=clib2) (see e.g. https://github.com/adtools/libnix).
The only one that works fine was nix20 (nix13 did not link and clib2 linked, but the program did not work on Amiga. Why in a first-place we need the standard C library?
I have used this with -mcrt: m68k-amigaos-g++ args.o -mcrt=nix20 -o args and it finally worked:
Can anybody describe to me as a newbie a bit more background details of all this?
Here is my test program:
#include <iostream>
using std::cout;
#if defined (__AMIGA__)
#define MAIN_FNC __stdargs
#else
#define MAIN_FNC
#endif
MAIN_FNC int main( int argc, char *argv[] )
{
cout << "Arguments count:" << argc << " \n";
for ( int i = 0; i < argc; i ++ )
cout << i << ". [" << argv[i] << "]\n";
return 0;
}
You don't need any MAIN_FNC, remove it. Also don't need to play with -mcrt=xxx. Just link with -noixemul option.
m68k-amigaos-g++ args.o -noixemul -o args
By default ixemul.library is used/linked (in short and very simply the ixemul.library emulate some unix behavior, see here). That cause your problem.
More info about -noixemul related to gcc & AmigaOS here:
GCC and ixemul.library
Using MinGW here to compile this C++ program:
int function(int n1, int n2){
n1=10;
n2=20;
return;
}
int main()
{
int a=89;
int b=16;
function(a, b);
return 0;
}
Why is the debugger showing the parameter values as if no new value had been assigned to them?
At the debugging point I would expect n1 to be 10 and n2 to be 20. So is this a misconception I have?
Edit: Adding requested info. I used Qt Creator as an IDE (v. 2.7.2) but this is a plain C++ project (no Qt involved). Compiler is MinGW 4.8 32 bits. Debugger is GDB.
I am trying to follow a tutorial I found online. I am using Ubuntu 17, compiling from the command line.
#include <stdio.h>
#include <iostream>
__global__ void add(int a, int b, int *c)
{
*c = a + b;
}
int main()
{
int a,b,c;
int *d_c;
int size = sizeof(int);
a = 2;
b = 7;
cudaMalloc((void **)&d_c,size;
add<<<1,1>>>(a,b,d_c);
cudaMemcpy(&c,d_c,size,cudaMemcpyHostToDevice);
std::cout << a << " + " << b << " = " << c << std::endl;
cudaFree(d_c);
return 0;
}
When I compile with nvcc I get the following error:
nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
I ignored the warning and ran a.out as usual, and I get the output:
2 + 7 = 1
Last time I did maths, this is incorrect. I am not sure if I am doing this incorrectly, or if the tutorial I am following is too old, or if it has something to do with the warning? Any help or leads will do. I will also mention, that I was not able to compile with nvcc until I installed gcc-5. I believe I have linked them together correctly by using these instructions I found here.
I have also looked at this solution here as well. However, I did not find the answer particularly helpful so I would appreciate some insight if this is compiling correctly, why this is not printing out correctly to my terminal.
Any help would be much appreciated.
Your call to cudaMemcpy() is incorrect. You should copy the result from the device (GPU) memory to host (CPU) memory, not other way around. The correct kind flag to use is cudaMemcpyDeviceToHost :
cudaMemcpy(&c, d_c, size, cudaMemcpyDeviceToHost);
In order to simplify the debugging in the future, think about implementing proper CUDA API error checking as well as systematically running your programs with cuda-memcheck, cuda-gdb, valgrind and clang sanitizers.
This is something I have noticed and I do not have the answer to it and it bothers me.
Let's say we have two simple functions.
void foo()
{
std::cout << "Rainbows are cute!" << std::endl;
return;
}
int main()
{
foo();
return 0;
}
Now these two functions are all part of the same cpp file.
If I compile this cpp file on gcc the file will cout "Rainbows are cute!"
but if I were to do it on Xcode or Visual Studio, the cout statement will not display. I mention VS and Xcode because these are two common compilers, used by many.
My question is why does this happen? What is going on in the compilers were one will display the cout statement in the void functions and the others will not?
The printouts will display in VS and Xcode as well. The difference is in how you run this. When you execute your program from Visual Studio, console window briefly pops up, displays the message, and promptly disappears.
To prevent this from happening, you can set breakpoint on return 0 line, and run in debug mode. When the breakpoint is hit, switch to the console window to see the message:
I have a program that I'd like to debug by setting a breakpoint in a non-default constructor, but the breakpoint I set is never hit. Below is an example program where this problem comes up. There is no problem hitting breakpoints set in the main function, but any breakpoints set in the Domain.cpp file are ignored:
Main.cpp:
#include <iostream>
#include "Domain.h"
int main()
{
Domain y;
std::cout << y.x << std::endl; // <- No problem setting breakpoint here
return 0;
}
Domain.cpp:
#include "Domain.h"
Domain::Domain()
{
x = 4; // <- A breakpoint here is skipped
}
Domain.h:
#ifndef DOMAIN_H_
#define DOMAIN_H_
class Domain
{
public:
int x;
public:
Domain();
};
#endif /* DOMAIN_H_ */
However, the problem does not exist if I put everything into a single file:
Main2.cpp:
#include <iostream>
int main()
{
class Domain
{
public:
int x;
Domain()
{
x = 4; // <- No problem setting breakpoint here now!
};
};
Domain y;
std::cout << y.x << std::endl;
return 0;
}
Why is this the case? How can I change this so that I'm able to set breakpoints when I use multiple files?
I can confirm that the breakpoints aren't working both when I run the debugger manually in a terminal and when I run it through Eclipse CDT, where I get the same error discussed in this question which was apparently never answered:
Why does Eclipse CDT ignore breakpoints?
I am using:
Eclipse Kepler
Mac OSX 10.8.4
gdb 6.3.5 (Apple version)
gcc 4.2.1 with -O0 and -g3 flags
Please be patient with me. I'm still learning the ropes.
You are likely hitting this GDB bug.
This bug has long been fixed, but your version of GDB is very old (and Apple is unlikely to update it).
This is a very interesting anomaly that I would like to explore further, but I suspect it's related to Eclipse's default GCC settings. Many super basic functions like these get optimized out when they hit the compiler. (one time I tried to track a simple for loop, but the viable was removed entirely on GCC's highest optimization settings)