I created a structure as:
typedef struct {
float real, img;
} cmplx;
and created a function as:
void input(cmplx *a){
scanf("%f + %f i", &a->real, &a->img); }
and called the function from main as:
cmplx a;
input(&a);
The execution stops when the scanf is reached. If floats are replaced by ints, the problem is solved. What is this behaviour? Is there a way I can use float for my problem?
The program was compiled on Turbo C, in MS-WINDOWS XP
It is hard to answer without knowing the error message that your program's execution stops with, but from your comment "is there any code i can write to tell compiler to link floating point library",
I suspect it may be this issue:
"Floating point formats not linked" is a Borland run-time error (Borland
C or C++, Turbo C or C++). Borland's compilers try to be smart and not
link in the floating- point (f-p) library unless you need it. Alas, they
all get the decision wrong. One common case is where you don't call any
f-p functions, but you have %f or other f-p formats in scanf() or
printf() calls. The cure is to call an f-p function, or at least force
one to be present in the link.
To do that, define this function somewhere in a source file but don't
call it:
static void forcefloat(float *p)
{
float f = *p;
forcefloat(&f);
}
It doesn't have to be in the module with the main program, as long as
it's in a module that will be included in the link.
If you have Borland C++ 3.0, the README file documents a slightly less
ugly work-around. Insert these statements in your program:
extern unsigned _floatconvert;
#pragma extref _floatconvert
Using this workaround, or a more modern compiler, will probably fix your issue.
Problem is with using years old C compiler like TurboC, as it works fine for me (I am Using DevC++)
check this discussion for similar issue
Related
I'm newbie in C language... Just want to ask how to enable linking floating point library in TurboC?
From the comp.os.msdos.programmer FAQ:
"Floating point formats not linked" is
a Borland run-time error (Borland C or
C++, Turbo C or C++). Borland's
compilers try to be smart and not link
in the floating- point (f-p) library
unless you need it. Alas, they all get
the decision wrong. One common case is
where you don't call any f-p
functions, but you have %f or other
f-p formats in scanf() or printf()
calls. The cure is to call an f-p
function, or at least force one to be
present in the link.
To do that, define this function
somewhere in a source file but don't
call it:
static void forcefloat(float *p)
{
float f = *p;
forcefloat(&f);
}
It doesn't have to be in the module
with the main program, as long as it's
in a module that will be included in
the link.
I am using visual studio 2017 .
First I wrote the following code :
void main()
{
printf("abcdefgh %d hjhjh %d", 5, 6);
getch();
}
It ran perfectly fine .
But after that I modified the code to the following :
void main()
{
char abc[100];
strcpy_S(abc, "premraj");
printf("%s", abc);
printf("abcdefgh %d hjhjh %d", 5, 6);
getch();
}
But now I am getting an error with getch stating that "'getch' undefined, assuming extern returning int"
But this new code has been built on the existing code which recognized getch perfectly , how can it not recognize getch the second time ?
I checked out the following question :
getch() is working without conio.h - how is that possible?
which also carried a similar problem but here with modifications only I got this error .
There is an informative answer there by user named "Fatal Error" but still I would like to know about this intriguing phenomenon that is coming in after modifications . What can be the reason behind this ?
P.S : The following was my header file declarations for the first time :
#include <stdio.h>
and the following for the second time :
#include <stdio.h>
#include <string.h>
Once upon a time, if you called a function which the compiler had never heard of, like this:
#include <stdio.h>
int main()
{
int x = foo();
printf("%d\n", foo);
}
Anyway, if you did that, the compiler quietly assumed that foo() was a function returning int. That is, the compiler behaved just as if you had typed
extern int foo();
somewhere before you called foo.
But in, I think, C99, the language was changed. It was no longer legal to call a function you had not explicitly declared. Because there was lots and lots of code out there that was written under the previous set of rules, most compilers did not immediately begin rejecting the old-style code. Some continued to quietly assume that unrecognized functions returned int. Others -- like yours -- began noisily assuming that unrecognized functions returned int, emitting warnings along the lines of "'foo' undefined, assuming extern returning int".
It sounds like your question is that some time ago, your code containing calls to getch() was accepted without warning, but today, you're getting the warning "'getch' undefined, assuming extern returning int". What changed?
One possibility is that your code changed slightly. If your code used to contain the line
#include <conio.h>
somewhere, that file would have contained a declaration along the lines of
extern int getch();
and this would have goven the compiler the declaration that it needed, and you would not have gotten the warning. But if today your code does not contain that #include line, that explain why the warning started cropping up.
It's also possible that your compiler has changed somehow. It's possible you're using a new version of the compiler, that's more fussy, that has gone from quietly assuming, to normally assuming. Or, it's possible that your compiler options have changed. Many compilers can be configured to accept different variants of the language, corresponding to the different versions of the language standards that have been released over the years. For example, if some time ago your compiler was compiling for language standard "C89", but today, it's doing "C99" or "C11", that would explain why it's now being noisy with this warning.
The change in the compiler could be a change in the defaults as configured by a system administrator, or a change in the way you're invoking the compiler, or a change in your project's Makefile, or a change in the language settings in your IDE, or something like that.
A few more points:
getch is not a Standard C function; it's specific to Windows. Your program would be more portable, in general, if you didn't use it. Are you sure you need it? (I know what it's for; what I don't know if there's some other way of keeping your program's output window on the screen after if exits.)
You should get in the habit of declaring main() as int, not void. (void will work well enough, but it's not correct, and if nothing else, you'll get lots of negative comments about it.)
I think there's something wrong with your call to strcpy_S, too,
I need to losslessly represent a double precision float in a string, and so I am using
sprintf(buf, "%la", x);
This works fine on my system, but when built on MinGW under Windows, gives a warning:
unknown conversion type character 'a' in format
I coded up a workaround for this case, but have trouble detecting when I should use the workaround -- I tried #if __STDC_VERSION__ >= 199901L, but it seems Gcc/MinGW defines that even if it doesn't support %a. Is there another macro I could check?
This doesn't answer the question "How to detect if printf will support %a?" in the general case, but you can modify your compiler installation so that %a is supported.
First of all , use mingw-w64. This is an up-to-date fork of MinGW. The original version of MinGW is not well maintained and does not fix bugs such as you are experiencing (preferring to blame Microsoft or something).
Using mingw-w64 4.9.2 in Windows 10, the following code works for me:
#include <stdio.h>
int main()
{
double x = 3.14;
printf("%a\n", x);
}
producing 0x1.91eb85p+1 which is correct. This is still deferring to the Microsoft runtime.
Your question mentions %la, however %a and %la are both the same and can be used to print either a float or a double argument.
If you want to print a long double, then the Microsoft runtime does not support that; gcc and MS use different sizes of long double. You have to use mingw-w64's own printf implementation:
#define __USE_MINGW_ANSI_STDIO 1
#include <stdio.h>
int main()
{
long double x = 3.14;
printf("%La\n", x);
}
which outputs 0xc.8f5c28f5c28f8p-2. This is actually the same number as 0x1.91eb85p+1 with more precision and a different placement of the binary point, it is also correct.
As jxh already suspected, MingW uses the MSVCRT LibC from Windows. The C99 support is not complete, especially some of the options of printf(3) like a are missing.
I generated a hash function with gperf couple of days ago. What I saw for the hash function was alien to me. It was something like this (I don't remember the exact syntax) :
unsigned int
hash(str, size)
register char* str;
register unsigned int size;
{
//Definition
}
Now, when I tried to compile with a C++ compiler (g++) it threw errors at me for not having str and size declared. But this compiled on the C compiler (gcc). So, questions:
I thought C++ was a superset of C. If its so, this should compile with a C++ compiler as well right?
How does the C compiler understand the definition? str and size are undeclared when they first appear.
What is the purpose of declaring str and size after function signature but before function body rather than following the normal approach of doing it in either of the two places?
How do I get this function to compile on g++ so I can use it in my C++ code? Or should I try generating C++ code from gperf? Is that possible?
1. C++ is not a superset, although this is not standard C either.
2/3. This is a K&R function declaration. See What are the major differences between ANSI C and K&R C?
.
4. gperf does in fact have an option, -L, to specify the language. You can just use -L C++ to use C++.
The Old C syntax for the declaration of a function's formal arguments is still supported by some compilers.
For example
int func (x)
int x
{
}
is old style (K&R style) syntax for defining a function.
I thought C++ was a superset of C. If its so, this should compile with a C++ compiler as well right?
Nopes! C++ is not a superset of C. This style(syntax) of function declaration/definition was once a part of C but has never been a part of C++. So it shouldn't compile with a C++ compiler.
This appears to be "old-school" C code. Declaring the types of the parameters outside of the parentheses but before the open curl-brace of the code block is a relic of the early days of C programming (I'm not sure why but I guess it has something to do with variable management on the stack and/or compiler design).
To answer your questions:
Calling C++ a "superset" of C is somewhat a misnomer. While they share basic syntax features, and you can even make all sorts of C library calls from C++, they have striking differences with respect to type safety, warnings vs. errors (C is more permissible), and compiler/preprocessor options.
Most contemporary C compilers understand legacy code (such as this appears to be). The C compiler holds the function parameter names sort of like "placeholders" until their type can be declared immediately following the function header name.
No real "purpose" other than again, this appears to be ancient code, and the style back in the day was like this. The "normal" approach is IMO the better, more intuitive way.
My suggestion:
unsigned int hash(register char *str, register unsigned int size)
{
// Definition
}
A word of advice: Consider abandoning the register keyword - this was used in old C programs as a way of specifying that the variable would be stored in a memory register (for speed/efficiency), but nowadays compilers are better at optimizing away this need. I believe that modern compilers ignore it. Also, you cannot use the & (address of) operator in C/C++ on a register variable.
I am a Theoretical Physics research student, working in Cosmology. In course of my research I have use to rather huge library of Fortran codes and I used C for my programming needs.
I have been able to link the two programs in numerous test files and they work brilliantly. But for them I have been using the object files to link them all. But when I tried to run the real deal through C, include reference to the Fortran header files. They seem to integrate and call each other fine but the format of the Fortran header file is incomptible with the C compiler, so when it jumps to the header file it start throwing errors that it cannot understand the syntax.
For example, the Fortran header file defines double variables with real*8 so when C reads them it throws errors. The same happens with comments in the file as well.
So, I want to ask is there any way through which I can go about this problem? i.e. make the fortran format header file readible through C.
I looked over the internet and found confusing answers, and I do not know which one to follow. Any help in this matter will be appreciated :)
Sorry but you are very confusing. What is a Fortran header file ? For instance, you cannot read a Fortran include file using a C compiler ! The two languages are too different. In addition a Fortran include file is almost never an header file comparable to the C's one.
I don't know the kind of compiler you are using. But if you have chosen a recent GCC version (Gnu Compiler Collection), then the Fortran compiler included inside is able to take into account the ISO_C_BINDING feature which makes easier the coupling Fortran-C.
Example :
MODULE my_fortran
USE iso_c_binding
IMPLICIT NONE
CONTAINS
SUBROUTINE my_subroutine(a,b) BIND(C,name="my_sub")
INTEGER(c_int),INTENT(in),VALUE :: a
REAL(C_DOUBLE),INTENT(out) :: b
...
END SUBROUTINE
END MODULE
C header file named "my_sub.h" for instance :
void my_sub(int, double *);
C file
#include "my_sub.h"
int main(){
double b;
int a=3;
my_sub(a,&b);
...
}
Fortran usually passes its variables by reference (passes pointers).
That means that you MUST give addresses in your calling C-program.
Function results, may be passed by value, for example, the following
code calls a FORTRAN function called "gamma":
double x, y;
..................
x = 2.0;
y = gamma_(&x)
Make sure that the
size of the variable in the calling program is identical to the size
in the Fortran routine:
float --- REAL (this is typical, but not always the case)
double --- REAL*8
The Fortran function must be declared at the beginning of the C calling function:
extern void read_(int *small, float *medium, double *large);
Note we have to pass all variables to Fortran as pointers. Although the function name is not case sensitive in Fortran, it gains an underscore in the C declaration and when it is called:
read_(&small, &medium, &large);
The Fortran function receives the variables as follows:
SUBROUTINE READ(small,medium,large)
INTEGER small
REAL medium
DOUBLE large
The precise size of these variables depends on your system's architecture (32 bit verses 64 bit), so you need to confirm the correspondence between ints, floats and doubles in C and Fortran on your system.