i am using the Borland c++ 3.1 compiler. I want to work with exceptions, i've written the following code:
void main (void) {
int a = 0;
int b = 1;
int c;
try {
throw 1;
}
catch(int a) {
b = a;
}
}
The compiler returns a syntax error. what's wrong?
Most compilers will issue an error stating that your main function must return an int.
The main function must return int in a C++ program. It's unsafe to return void from a main function and many modern compilers won't compile. Aside from that everything looks compilable
Related
Consider this code:
#include <cstdio>
int get_value() { asm("movl $254, %eax"); }
int main() { printf("%d\n", get_value()); }
Now if one compiles this code with g++ main.cpp, one gets a compiler warning (but the code still compiles):
main.cpp: In function ‘int get_value()’:
main.cpp:3:43: warning: no return statement in function returning non-void [-Wreturn-type]
3 | int get_value() { asm("movl $254, %eax"); }
|
As this answer says that if a compiler generates a binary with the above code, all bets are off. (no return statement from a function with return type int)
Indeed, when one compiles this code with optimization turned on g++ -O3 main.cpp, this program immediately segfaults.
So my question is how can one return from inline assembly within a c++ function that is conformant with C++, and one doesn't get this warning, and the code works fine.
I believe what you have to do is declare a dummy variable, and use the gcc extended syntax to output that variable, and then you can return that variable. The optimiser should strip both assignents out.
It is sort-of explained in https://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s5, and might look like this:
#include <cstdio>
int get_value() {
int b;
asm("movl $254, %0;"
: "=r"(b)
);
return b;
}
int main() {
printf("%d\n", get_value());
}
I used CLion as an IDE, it reports an error in IDE as
field z must be initialized
It can compile and run. But if I change const int z{3}; to const int z=3;, no error will be reported in IDE. My question is whether it is indeed an error of my codes or it is just a bug in the IDE? Any difference between these two initialization approaches? Did your IDE report this error?
#include <iostream>
using namespace std;
class Test
{
private:
const int x = 3;
int y;
const int z{3};
public:
Test(int);
int gety(){
return y;
}
};
Test::Test(int a){
y=x+4;
}
int main()
{
Test test(5);
std::cout << test.gety() << std::endl;
return 0;
}
whether it is indeed an error of my codes
There is no error in the code, it is OK.
or it is just a bug in the IDE?
It is a bug in whatever generates the error message. The IDE is high on my list of suspects but it could be another tool whose message the IDE relays.
Any difference between these two initialization approaches?
In this context (default member initializer) both syntaxes are semantically equivalent. There is no difference.
I wrote a program in C and I want to use C++ library in this code, I though that I will be able to compile the C in g++ since C++ built in top of C. However, I couldn't do that and the main error was because in one part of the code I wrote a function to read data from input file, before the main function. That worked well in C compiler but not in Cpp compiler.
Below is some of the error messages I got, so I'd like to get general comments and points to take into consideration when use c and cpp interchangeably
error : ‘get_inputs’ was not declared in this scope
error: use of parameter outside function body before ‘]’ token
Following program compiles in C with a warning such as: 'bar' undefined; assuming extern returning int
void foo()
{
bar(5);
}
int bar(int x)
{
return x*2;
}
If you want this to compile in C++ you must declare bar before you use it:
int bar(int x); // forward declaration
void foo()
{
bar(5);
}
int bar(int x)
{
return x*2;
}
Even in C it's good practice to use forward declarations and to enable all compiler warnings otherwise the error in following program will slip through:
void foo()
{
bar(); // calling bar without argument....
}
int bar(int x)
{
return x*2; // ... will result in an undefined value for x here
}
On stack overflow I ran into a question What is ":-!!" in C code?
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
out of curiosity I want to know how can I use these kind of macros ?
int main()
{
BUILD_BUG_ON_ZERO(0);
return 0;
}
In the above code it gives an error that type name is not allowed.
EDIT :
the code compiles on linux using gcc but fails on visual studio
Read the best answer carefully:
The macro is somewhat misnamed; it should be something more like
BUILD_BUG_OR_ZERO, rather than ...ON_ZERO
So it fails to compile when the parameter is nonzero:
int main()
{
BUILD_BUG_ON_ZERO(1);
return 0;
}
http://ideone.com/TI97r3
As for a practical usage:
int main()
{
BUILD_BUG_ON_ZERO(sizeof(int) != 4); // we need int to be 4 bytes, stop compilation otherwise
return 0;
}
As for C++: this is a C construct that does not compile in C++ at all.
In C++11 you can use a static_assert instead.
Solved: I upgraded from mingw 4.6.2 to 4.7.0 and it works perfectly, guess it was just a bug
I started to do some research on how terminate a multithreaded application properly and I found those 2 post(first, second) about how to use QueueUserAPC to signal other threads to terminate.
I thought I should give it a try, and the application keeps crashing when I throw the exception from the APCProc.
Code:
#include <stdio.h>
#include <windows.h>
class ExitException
{
public:
char *desc;
DWORD exit_code;
ExitException(char *desc,int exit_code): desc(desc), exit_code(exit_code)
{}
};
//I use this class to check if objects are deconstructed upon termination
class Test
{
public:
char *s;
Test(char *s): s(s)
{
printf("%s ctor\n",s);
}
~Test()
{
printf("%s dctor\n",s);
}
};
DWORD CALLBACK ThreadProc(void *useless)
{
try
{
Test t("thread_test");
SleepEx(INFINITE,true);
return 0;
}
catch (ExitException &e)
{
printf("Thread exits\n%s %lu",e.desc,e.exit_code);
return e.exit_code;
}
}
void CALLBACK exit_apc_proc(ULONG_PTR param)
{
puts("In APCProc");
ExitException e("Application exit signal!",1);
throw e;
return;
}
int main()
{
HANDLE thread=CreateThread(NULL,0,ThreadProc,NULL,0,NULL);
Sleep(1000);
QueueUserAPC(exit_apc_proc,thread,0);
WaitForSingleObject(thread,INFINITE);
puts("main: bye");
return 0;
}
My question is why does this happen?
I use mingw for compilation and my OS is 64bit.
Can this be the reason?I read that you shouldn't call QueueApcProc from a 32bit app for a thread which runs in a 64bit process or vice versa, but this shouldn't be the case.
EDIT: I compiled this with visual studio's c++ compiler 2010 and it worked flawlessly, it is possible that this is a bug in gcc/mingw?
I can reproduce the same thing with VS2005. The problem is that the compiler optimizes the catch away. Why? Because according to the C++ standard it's undefined what happens if an extern "C" function exits with an exception. So the compiler assumes that SleepEx (which is extern "C") does not ever throw. After inlining of Test::Test and Test::~Test it sees that the printf doesn't throw either, and consequently if something in this block exits via an exception
Test t("thread_test");
SleepEx(INFINITE,true);
return 0;
the behavior is undefined!
In MSVC the code doesn't work with the /EHsc switch in Release build, but works with /EHa or /EHs, which tell it to assume that C function may throw. Perhaps GCC has a similar flag.