new functions

[Bill Cunningham]

I'm writing some new functions that work with math and should analyze stock
price information. This is what I have now.

main.h

#include <stdio.h>
#ifdef math
#include <math.h>
#endif
float relstr(float x,float y);
/* The relstr function is declared in the header */
The Body,
float relstr(float x,float y){n=x/y;
printf("%f",n);}
Simple enough. Now I want to not only be able to use this function to find
relative strength by inserting floating points into the parenthesis. I want
to attach the function to a stock name and load the results into it. I think
that might be the best way to do it. Like this.

msft.relstr(23.00,22.25);
I think I should use structs here. Right?

Bill

 

[Sidney Cadot]

I'm writing some new functions that work with math and should analyze stock
price information. This is what I have now.

main.h

#include <stdio.h>
#ifdef math
#include <math.h>
#endif

Why the guards this #include? It's quite safe to include #include <math.h>.

Note furthermore that unless you use things defined in a standard header
(stdio.h, math.h, ...) in the header, it's probably better to include
them in the C file itself.

float relstr(float x,float y);
/* The relstr function is declared in the header */

The situations where using 'float' instead of 'double' is a good idea
are few and far inbetween. Unless you are going to store massive amounts
of numbers (tens/hundreds of millions or more), just use doubles.

The Body,

I take it you mean this is no longer in your header file?

float relstr(float x,float y){n=x/y;
printf("%f",n);}

Several problems:

(1) n is not declared
(2) you fail to return a value, while your declaration states that this
function returns a float.

Simple enough.

Hmmmm.... ;-)

Now I want to not only be able to use this function to find
relative strength by inserting floating points into the parenthesis. I want
to attach the function to a stock name and load the results into it. I think
that might be the best way to do it.

What your saying here is reminiscent of declaring an object. C does not
provide language support for that. While it is technically possible to
do object oriented programming in C, this requires a quite thorough
knowledge of C.

Idiomatic C would be to declare a type (say, struct Stock), then define
functions that take a Stock as a parameter. Something like:

struct Stock {
const char *name;
double x,y; /* some unspecified fields */
};

void init_stock(struct Stock *stock,
const char *name, double x, double y)
{
stock->name = name;
stock->x = x;
stock->y = y;
}

double relstr(const struct Stock *stock)
{
/* calculate something... */
return stock->x / stock->y;
}

> Like this.

msft.relstr(23.00,22.25);
I think I should use structs here. Right?

Yes, but not like this. If you insist on using this kind of notation in
a C-ish context, check out C++ . Otherwise (for the class of problems
that you seem to be interested in solving) I would strongly recommend
that you look at other languages that are perhaps more appropriate for
the domain. As for many things on a not-too-low level, Python may be a
very suitable choice.

Best regards,

Sidney Cadot

 

[Bill Cunningham]

I take it you mean this is no longer in your header file?

Exactly. It's in a source file to be converted to obj file

Several problems:

(1) n is not declared /*Yeah I guess you're right */
(2) you fail to return a value, while your declaration states that this
function returns a float. /* Okay */


Hmmmm.... ;-)


What your saying here is reminiscent of declaring an object. C does not
provide language support for that. While it is technically possible to
do object oriented programming in C, this requires a quite thorough
knowledge of C.

Idiomatic C would be to declare a type (say, struct Stock), then define
functions that take a Stock as a parameter. Something like:

struct Stock {
const char *name;
double x,y; /* some unspecified fields */
};

void init_stock(struct Stock *stock,
const char *name, double x, double y)
{
stock->name = name;
stock->x = x;
stock->y = y;
}

double relstr(const struct Stock *stock)
{
/* calculate something... */
return stock->x / stock->y;
}


Yes, but not like this. If you insist on using this kind of notation in
a C-ish context, check out C++ . Otherwise (for the class of problems
that you seem to be interested in solving) I would strongly recommend
that you look at other languages that are perhaps more appropriate for
the domain. As for many things on a not-too-low level, Python may be a
very suitable choice.

Best regards,

Sidney Cadot

Hate Interpreters. I think the only translators python uses is interpreters.

The body above goes into a file like so.
gcc -c prg.c -o prg.lib
Then is a file where I call relstr() from main() I link the prg.lib library
like so.
gcc main.c prg.lib -o prg.exe
run the executable or use ./ or however your OS executes. Of course there
should be more functions in prg.lib than one. Or I could link likewise.

ar rc libstk.a prg.o Creates a Unix type library.

Bill

 

[Sidney Cadot]

[skip]
Yes, but not like this. If you insist on using this kind of notation in
a C-ish context, check out C++ . Otherwise (for the class of problems
that you seem to be interested in solving) I would strongly recommend
that you look at other languages that are perhaps more appropriate for
the domain. As for many things on a not-too-low level, Python may be a
very suitable choice.

Best regards,

Sidney Cadot

Hate Interpreters. I think the only translators python uses is interpreters.

Yes. IMHO, it's a bit strange to dislike interpreters, per se. The
distinction is blurry... For example, the C standard doesn't mandate C
to be a compiled language, and indeed: C interpreters exist.

On the other hand, I used to hate languages with untyped variables
myself for quite some time, which is of course the case for Python.
However, I somehow like Python. For one thing, it can support 'traits',
which gives many of the advantages of typed variables.

Another argument to prefer compiled languages is you need to produce a
stand-alone executable. Again, there are ways.... However, I'm
digressing now far beyond topicality.

The body above goes into a file like so.
gcc -c prg.c -o prg.lib

It is very advisable to get your compiler to emit as many warnings as
possible. One of the prime advantages of a compiled language is that the
compiler will go through all of your program and be busy drawing
inferences on what you wrote. Much of this information is useful for
diagnostic purposes. However, C is quite liberal in what is allowed, so
by default the compiler will not give warnings on things that are
usually questionable. You will have to tell it to emit a warning in
cases like this.

For gcc, the use of both the "-W" and "-Wall" is an exceedingly good
idea. This will potentially yield a large amount of warnings, some of
which are hard to understand without a bit of experience. However, gcc
is almost always right; most warnings it emits expose genuine bugs or
questionable constructs.

Second, by convention the thing that gcc emits when compiling a C file
is an object file, which is usually given with an ".o" extension. It may
be useful to comform to established practice in this regard.

Then is a file where I call relstr() from main() I link the prg.lib library
like so.

gcc main.c prg.lib -o prg.exe

run the executable or use ./ or however your OS executes. Of course there
should be more functions in prg.lib than one. Or I could link likewise.

ar rc libstk.a prg.o Creates a Unix type library.

To do this portably, you need to subject this to a "ranlib" afterwards.
This is a bit silly, but required on some systems.


Best regards, Sidney