Printable View
Would the same C/C++ compile and run on every compiler??? I mean code NOT meant for creating a GUI, because it is obvious that a code for Borland C 5.02 would not work in GTk+.
I just mean basic C/C++ functions.
I wrote a small program in Turbo C which contained the function gotoxy(); I tried the code in MS visual C++, and it didn't interpret gotoxy(); clrscr(); and others, why is this happening I thought C would be C everywhere???
Thanks
I use M$ visual studios c++, and though I don't have the answer to your question I know I had to relearn the c++ I gleaned from generic tutorials.
I may be wrong but i think different compilers use different libraries ie clrscr()
But as i said, im no programmer so i may be wrong!
Cheers
The reason for this is simple. Standard C/C++ will compile almost anywhere, even accross platforms. However, Borland C++ uses a header called <conio.h> for special functions like gotoxy(x,y) and clrscr(). Unless you have the libraries to compile that code, the code is obviously not going to compile. So, the reason your code didn't compile on MS VC++ is the same reason that GTK+ code won't compile on Borland C++.
Cheers,
cgkanchi
i usually use gcc compilers, and i find that if i have to compile the same code using visual c++ i get problems, especially in the math and random libraries.
I've posted this before...
http://www.mozilla.org/hacking/portable-cpp.html
Quote:
C++ portability rules.
1. Don't use C++ templates.
2. (*) Don't use static constructors.
3. Don't use exceptions.
4. Don't use Run-time Type Information.
5. Don't use namespace facility.
6. main() must be in a C++ file.
7. Use the common denominator between members of a C/C++ compiler family.
8. Don't put C++ comments in C code.
9. Don't put carriage returns in XP code.
10. Put a new line at end-of-file.
11. Don't put extra top-level semi-colons in code.
12. C++ filename extension is .cpp.
13. Don't mix varargs and inlines.
14. Don't use initializer lists with objects.
15. Always have a default constructor.
16. Don't put constructors in header files.
17. Be careful with inner-classes.
18. Be careful of variable declarations that require construction or initialization.
19. Make header files compatible with C and C++.
20. Be careful of the scoping of variables declared inside for() statements.
21. Declare local initialized aggregates as static.
22. Expect complex inlines to be non-portable.
23. Don't use return statements that have an inline function in the return expression.
24. Be careful with the include depth of files and file size.
25. Use virtual declaration on all subclass virtual member functions.
26. Always declare a copy constructor and assignment operator.
27. Be careful of overloaded methods with like signatures.
28. Type scalar constants to avoid unexpected ambiguities.
29. Always use PRBool or XP_Bool for boolean variables in XP code.
30. Use macros for C++ style casts.
31. Don't use mutable.
32. Use nsCOMPtr in XPCOM code.
33. Don't use reserved words as identifiers.
Stuff that is good to do for C or C++.
1. Always use the nspr types for intrinsic types.
2. Do not wrap include statements with an #ifdef.
3. #include statements should include only simple filenames.
4. Macs complain about assignments in boolean expressions.
5. Every source file must have a unique name.
6. Use #if 0 rather than comments to temporarily kill blocks of code.
7. Turn on warnings for your compiler, and then write warning free code.
Yes, provided:Quote:
Would the same C/C++ compile and run on every compiler???
1. You didn't use any compiler-specific stuff
2. You didn't use features not available on some compilers
3. You didn't use or trip over any bugs in any of the compilers.
These things will hold for nearly all reasonably sane C, and most C++ code.
Aha, here is your problem. You are using a *library* which the other compiler doesn't know about. This is where your problems start.Quote:
I just mean basic C/C++ functions.
I wrote a small program in Turbo C which contained the function gotoxy(); I tried the code in MS visual C++, and it didn't interpret gotoxy() ...
Conio is not a library that is in any way standard; some dos compilers support it in some fashion, but it's *not* part of C or C++ - you won't find any mentions of it in K&R's book, nor Stroustrup's
Bear in mind that few libraries are entirely consistent between implementations, for instance stdio is just about the only one which can be relied on in any way (and even that has a few funnies)
Try to obtain an alternative library that has the same functionality that is supported on all the compilers you want to be able to support. Failing that, write your own compatibility layer which calls the appropriate libraries (as an intermediate layer)
ansii has developed standard C library functions that will work with all ansii compliant compilers. The nature of the C language is portable, however as mentioned compiler spasific functions will pose a problem when trying to port to other compilers. In general though usualy you can swap a few ansii standard functions in place of the non ansii function to acheive the same or simular results, this is called porting. You shopuld always try to use ansii standards and refrain yourself from useing compiler spasific functions.
If You use ANSI C; you'll never have any trouble... I recommend to use it as much as possible; to be able to compile everywhere... What's more; if you make a good ANSI C prog you'll not only be able to compile it in any windows compiler but you may as well compile it in any other platform's compiler (linux for e.i)...
Hope i helped you...
ampm2003
There are some standards like ANSI, POSIX and as long as your compiler supports them and you write your program according to the standard, it should work.