Re: Header Interfaces (Part 2)
- From: Robby <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 9 May 2009 14:31:01 -0700
Hello again David,
Its just that in my header, there is three define satements that the
programmer can modify to so that the source code carries out functionality
for eeprom storage... its a long story and don't really want to bother you
with that.
Just to better explain my intent in the above paragraph, the whole idea of
why I wanted to hide the defines, is because I wanted to seperate the defines
that the programmer is allowed to set from the defines he is not allowed to
set. But as you cleared it up for me, he shouldn't touch any of the defines.
But in my case I will have to allow him to modify 3 of them. Thanks again!
--
Best regards
Roberto
"Robby" wrote:
Hello David,.
If you are providing a header file and a compiled library then your clients
would be very foolish to modify your header before #including it in their code.
What is it that you are really trying to hide? People usually want to hide
source code, because that is where the value is, and what is most easily stolen.
This is why people provide compiled libraries and not source code.
David, no need to say more... I now understand that the defines can stay in
the header while we hide the source code.
Its just that in my header, there is three define satements that the
programmer can modify to so that the source code carries out functionality
for eeprom storage... its a long story and don't really want to bother you
with that. But I understand your point... I will just hide the source code
and leave all the defines in my headers.... Problem solved ! Thanks David I
really appreciate it!
--
Best regards
Roberto
"David Wilkinson" wrote:
Robby wrote:
Hello,
In my previous post, I have been introduced to the idea of
puting the statements that I don't want anyone to see at the top of my c.
file like this:
==============================something.h
typedef struct something{
int x;
} y;
void f1();
===========================something.c
#include "something.h"
void f2();
void f3();
void f1()
{
// code here....
f2(); }
void f2()
{
// code here....
f3(); }
void f3()
{ // code here....}
====================================
And I really liked this way of doing things! But now I have a problem if I
do this! Suppose I have an array in my structure and its size is determined
by a define statement which is also used in one of my functions in my .c file
(for example in f2() function).
So my dilemma is how would I provide a define statement that should be
hidden in the .c file but still can be used as the array size in a
structure's array member in the header?
Please view the following code:
==============================something.h
// The next line should not be seen in the header file!
// #define EEPROM_Q_MAX 5
typedef struct something{
int x;
long E_sel_items[EEPROM_Q_MAX];
} y;
void f1();
===========================something.c
#include "something.h"
void f2();
void f3();
void f1()
{
// code here....
f2();
}
void f2()
{int i;
for(i=0; i< EEPROM_Q_MAX ; i++) // The value is required here too????
{.....}
// code here....
f3();
}
void f3()
{ // code here....}
====================================
In summary, the following statement should not be modified by any programmers
#define EEPROM_Q_MAX 5
so how do I hide it from them while its still in scope for the E_sel_items
array?
You can't. Put the #define in the header file. If your clients are going to use
your "struct something", they need to know how big it is.
If you are providing a header file and a compiled library then your clients
would be very foolish to modify your header before #including it in their code.
What is it that you are really trying to hide? People usually want to hide
source code, because that is where the value is, and what is most easily stolen.
This is why people provide compiled libraries and not source code.
--
David Wilkinson
Visual C++ MVP
- Follow-Ups:
- Re: Header Interfaces (Part 2)
- From: Alex Blekhman
- Re: Header Interfaces (Part 2)
- References:
- Header Interfaces (Part 2)
- From: Robby
- Re: Header Interfaces (Part 2)
- From: David Wilkinson
- Re: Header Interfaces (Part 2)
- From: Robby
- Header Interfaces (Part 2)
- Prev by Date: Re: Header Interfaces (Part 2)
- Next by Date: _TCHAR* to char*
- Previous by thread: Re: Header Interfaces (Part 2)
- Next by thread: Re: Header Interfaces (Part 2)
- Index(es):
Relevant Pages
|
