Prev: Why is reference from unused function required?
Next: simple reference "for each" question
From: Igor Tandetnik on 3 Feb 2010 16:32
Robby <Robby(a)discussions.microsoft.com> wrote:
> "Igor Tandetnik" wrote:
>
>> #define extCrys 8
>> #define fpllidiv 2
>> #define fpllmul 21
>> #define fpllodiv 8
>> #define FREQ
>> (((float)(extCrys/fpllidiv)*(float)(fpllmul/fpllodiv))*1000000)
>
> Igor, one thing though, I am trying to create structures that hold
> only one type of data which relates to one type of task in my code.
> Then I would like to create functions that would manipulate the
> respective structure accordingly.

Well, if they are compile-time constants, what precisely does it mean to "manipulate" them?

> So for example, if I am setting up
> a #define statement to hold the current system clock... like this:
>
> #define extCrys 8
> #define fpllidiv 2
> #define fpllmul 21
> #define fpllodiv 8
> #define
> CURR_SYS_OSC(((float)(extCrys/fpllidiv)*(float)(fpllmul/fpllodiv))*1000000)
>
> I would rather create a structure holding this type of data. Then
> call a function to manipulate it. I think!!!

So, forget about implementation details. Design the interface from the client's point of view: if you somehow magically had a thrid-party library of your dreams doing precisely what you want to do, what would that library's API look like? What calls would you make to it? Then, once you have your ideal interface, fill in the implementation.

> So what I am saying is, that, isn't there a better and more
> structured way of doing...

Perhaps. It's hard for me to say, as I have no idea what it is you are trying to achieve. Now, before you go and write a long explanation, note that I'm probably not going to read it: except in very simple and obvious cases, it takes too much effort to understand the problem well enough to offer a good design, so as a rule, I don't give design advice.

> Mind you, one thing that doesn't help here is
> that I am a little confused as what is the difference between an API
> call *and* a normal function call

None. API is just a collection of functions, usually designed to work together and united by a common theme. An "API call" is just a shorthand for "a call to a function from some API" (it is usually clear from context which API is meant).

> *and* when we create an object and
> call a function passing a pointer to the object as a parameter.

I don't know of any special name for this technique. It's a function call like any other.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

From: Robby on 3 Feb 2010 18:22
"Igor Tandetnik" wrote:

> Well, if they are compile-time constants, what precisely does it mean >to "manipulate" them?

The values never change once they are set innitially! After that in very
rare cases would a system's frequency have to be altered. But nontheless it
might! So defining them is probably not a good idea.

> So, forget about implementation details. Design the interface from the client's >point of view: if you somehow magically had a thrid-party library of your dreams >doing precisely what you want to do, what would that library's API look like? What >calls would you make to it? Then, once you have your ideal interface, fill in the >implementation.

Its just a matter of calculating the values we saw earlier and assigning the
result to CURR_SYS_OSC and making it global..... but there are dozens of
ways to do this.... is it better to call a function and use the macro in
there , like this:

====================================x.h
#define COMPUTE(extCrys, fpllidiv, fpllmul, fpllodiv) \
(((float)(extCrys/fpllidiv)*(float)(fpllmul/fpllodiv))

#define OSC_PERIOD (1.0/CURR_SYS_OSC)

===================================x.c
main()
{ int CURR_SYS_OSC;
CURR_SYS_OSC = compute_sys_osc(8.0, 2.0, 21.0, 8.0);
SYSTEMConfig(CURR_SYS_OSC, SYS_CFG_ALL);
}

int compute_sys_osc(extCrys, fpllidiv, fpllmul, fpllodiv)
{
int FREQ;

FREQ = COMPUTE(extCrys, fpllidiv, fpllmul, fpllodiv);
return FREQ;
}
==================================

But if I do this, CURR_SYS_OSC is not available to other modules that might
need it.
Also, CURR_SYS_OSC would not be available for the OSC_PERIOD #define
statement. So I think, the above code is not an object oriented approach!
This is *code it* just so that it works!

Another solution would be how I have it now with simple defines:

====================================x.h
#define CURR_SYS_OSC (((float)(8.0/2.0)*(float)(21.0/8.0))*1000000)
#define OSC_PERIOD (1.0/CURR_SYS_OSC)

====================================x.c
int main(void)
{
SYSTEMConfig(CURR_SYS_OSC, SYS_CFG_ALL);
//... other code
}
======================================

This too is *code it* just so that it works!

> Perhaps. It's hard for me to say, as I have no idea what it is you are trying to ? >achieve. Now, before you go and write a long explanation,

Sorry if I come across this way! :-)

>note that I'm probably not going to read it: except in very simple and obvious >cases, it takes too much effort to understand the problem well enough to offer a >good design, so as a rule, I don't give design advice.

And that's okay too. I understand.

> None. API is just a collection of functions, usually designed to work together and >united by a common theme. An "API call" is just a shorthand for "a call to a >function from some API" (it is usually clear from context which API is meant).

So what you are saying is that this is an API function:

void f1()
{
// does something!
}

Its also possible that API's take in a pointer to an object. And once in the
function, they manipulate the data of that object through the pointer that
was passed in. And that's okay! Having said that, where I get confused is I
may create an object like this:

=========================
typedef struct tag_x
{int z;} x;

void config_obj(struct tag_x y, int a)
{
y.z = a;
}

int main()
{
x y;
config_obj(y,100);
return 0;
}
=========================

now, is config_obj() an API or just a simple function used to innitialize
the values of an object?

Thanks for your time and help!

Rob
From: Igor Tandetnik on 3 Feb 2010 20:18
Robby wrote:
> "Igor Tandetnik" wrote:
>> So, forget about implementation details. Design the interface from the client's >point of view: if you somehow magically had a
>> thrid-party library of your dreams >doing precisely what you want to do, what would that library's API look like? What >calls
>> would you make to it? Then, once you have your ideal interface, fill in the >implementation.
>
> Its just a matter of calculating the values we saw earlier and assigning the
> result to CURR_SYS_OSC and making it global..... but there are dozens of
> ways to do this.... is it better to call a function and use the macro in
> there , like this:
>
> ===================================x.c
> main()
> { int CURR_SYS_OSC;
> CURR_SYS_OSC = compute_sys_osc(8.0, 2.0, 21.0, 8.0);
> SYSTEMConfig(CURR_SYS_OSC, SYS_CFG_ALL);
> }
>
> int compute_sys_osc(extCrys, fpllidiv, fpllmul, fpllodiv)
> {
> int FREQ;
>
> FREQ = COMPUTE(extCrys, fpllidiv, fpllmul, fpllodiv);
> return FREQ;
> }
> ==================================
>
> But if I do this, CURR_SYS_OSC is not available to other modules that might
> need it.

How about breaking it into two calls:

set_sys_osc(parameters_here);
get_sys_osc();

Have set_sys_osc store the computed value in a file-level static variable, for example, in the source file where these two functions are defined, and get_sys_osc return that variable. No macros needed.

> Also, CURR_SYS_OSC would not be available for the OSC_PERIOD #define
> statement. So I think, the above code is not an object oriented approach!

I'm not sure what "object oriented" has to do with this problem. In any case, piling on ever more macros is certainly not the one true way to the OOP nirvana.

> So what you are saying is that this is an API function:
>
> void f1()
> {
> // does something!
> }

If it is part of a collection of related functions, then why not. "API" doesn't mean anything special at the language level - there's no keyword or anything to mark a function as being "API". It's just a way to think about organizing software.

> now, is config_obj() an API or just a simple function used to innitialize
> the values of an object?

Again - API is a collection of related functions. It's meaningless to ask whether one isolated function is "an API".
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
From: Robby on 4 Feb 2010 11:32
"Igor Tandetnik" wrote:

> How about breaking it into two calls:
>
> set_sys_osc(parameters_here);
> get_sys_osc();
>
> Have set_sys_osc store the computed value in a file-level static variable, for >example, in the source file where these two functions are defined, and >get_sys_osc return that variable. No macros needed.

Thanks for your guidence Igor. I will probably do that... so your saying, no
structures to keep these 5 variables together, no macros to carry out the
calculations in an orderly fashion.... seems so basic. But hey! I will do
just 2 functions for now.

Thanks for your help and feedback!

Regards
Rob


From: Igor Tandetnik on 4 Feb 2010 11:56
Robby <Robby(a)discussions.microsoft.com> wrote:
> "Igor Tandetnik" wrote:
>
>> How about breaking it into two calls:
>>
>> set_sys_osc(parameters_here);
>> get_sys_osc();
>>
>> Have set_sys_osc store the computed value in a file-level static
>> variable, for >example, in the source file where these two functions
>> are defined, and >get_sys_osc return that variable. No macros
>> needed.
>
> Thanks for your guidence Igor. I will probably do that... so your
> saying, no structures to keep these 5 variables together

Well, do you need these five pieces of data separately for some other reason, or do you just need the end result of the calculation? If you just need them once to calculate this sys_osc value, then there's no reason to store them.

> no macros
> to carry out the calculations in an orderly fashion

Why have macros when you can use functions?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Why is reference from unused function required?
Next: simple reference "for each" question