Popularity Of C among developer
-
Abhays01 wrote:
The main reason behind is, it doesn't support object-oriented programming features … Inheritance Encapsulation
Inheritance (structs inheriting from other structs), and encapsulation (struct name in the H file, and struct implementation in the C file) are certainly possible with C.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
David Crow wrote:
struct name in the H file, and struct implementation in the C file
That's not encapsulation, in any sense.
In object oriented programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof: - A language mechanism for restricting direct access to some of the object's components. - A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
Opaque structs in C fit at least one of those definitions for abstraction. You could probably make the case that since you'd need to bundle the opaque struct with some subroutines to manipulate it that you're basically writing methods - the only difference is the class keyword and the lack of an implicit *this* pointer.
-
David Crow wrote:
struct name in the H file, and struct implementation in the C file
That's not encapsulation, in any sense.
How about something like: car.h
struct car;
car.c
struct car
{
private:
char make[10];
char model[10];
int year;public:
char *getMake();
char *getModel();
char *getYear();
};-
Direct access to the object's components has been restricted.
-
The data and the methods that operate on that data are bundled together.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
-
How about something like: car.h
struct car;
car.c
struct car
{
private:
char make[10];
char model[10];
int year;public:
char *getMake();
char *getModel();
char *getYear();
};-
Direct access to the object's components has been restricted.
-
The data and the methods that operate on that data are bundled together.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
-
In object oriented programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof: - A language mechanism for restricting direct access to some of the object's components. - A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
Opaque structs in C fit at least one of those definitions for abstraction. You could probably make the case that since you'd need to bundle the opaque struct with some subroutines to manipulate it that you're basically writing methods - the only difference is the class keyword and the lack of an implicit *this* pointer.
-
Indeed (too many years away from it), but that does not change my point. If you had something like this in the H file:
struct CarPrivate;
struct Car
{
struct CarPrivate* priv;
};extern char* GetYear(struct Car* car);
And had something like this in the C file:
struct CarPrivate
{
int year;
};int GetYear(struct Car* car)
{
return car->priv->year;
}You would not be able to access members of
CarPrivatelike:void main( void )
{
struct Car* car = some_method_to_create_car();
int year = car->priv->year; // error
}"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Indeed (too many years away from it), but that does not change my point. If you had something like this in the H file:
struct CarPrivate;
struct Car
{
struct CarPrivate* priv;
};extern char* GetYear(struct Car* car);
And had something like this in the C file:
struct CarPrivate
{
int year;
};int GetYear(struct Car* car)
{
return car->priv->year;
}You would not be able to access members of
CarPrivatelike:void main( void )
{
struct Car* car = some_method_to_create_car();
int year = car->priv->year; // error
}"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
Putting the definition in a header file only matters if you are trying to access the struct in separate source modules; and that has nothing to do with encapsulation. And yes, of course you could do what you suggest above, but it serves little purpose since you can still access the data directly, and thus break the pseudo encapsulation. In OOP languages the data can actually be hidden from the users of the class, in C it cannot.
-
Putting the definition in a header file only matters if you are trying to access the struct in separate source modules; and that has nothing to do with encapsulation. And yes, of course you could do what you suggest above, but it serves little purpose since you can still access the data directly, and thus break the pseudo encapsulation. In OOP languages the data can actually be hidden from the users of the class, in C it cannot.
Richard MacCutchan wrote:
...since you can still access the data directly...
What if the structs were compiled into a LIB file? The user of that LIB file only has access to what is in the corresponding H file, correct?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Richard MacCutchan wrote:
...since you can still access the data directly...
What if the structs were compiled into a LIB file? The user of that LIB file only has access to what is in the corresponding H file, correct?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
How would that work? If you have the definitions in a header that you include in your source, then you have access to all members of the struct. Whether the actual struct is allocated on the stack, the heap or via a pointer to an external piece of memory, you can still see all the members.
-
How would that work? If you have the definitions in a header that you include in your source, then you have access to all members of the struct. Whether the actual struct is allocated on the stack, the heap or via a pointer to an external piece of memory, you can still see all the members.
Richard MacCutchan wrote:
If you have the definitions in a header...
The declaration would be in the H file. The implementation/definition would be in the C file, which would get compiled into a LIB file. Thus the only thing accessible to those using the LIB file would be the declarations in the corresponding H file (which does not include anything private).
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Richard MacCutchan wrote:
If you have the definitions in a header...
The declaration would be in the H file. The implementation/definition would be in the C file, which would get compiled into a LIB file. Thus the only thing accessible to those using the LIB file would be the declarations in the corresponding H file (which does not include anything private).
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
At the risk of repeating myself, that is not going to work. If you are going to do all the data manipulation in the lib file and not provide the struct definition to the user, then there is nothing required in the H file at all. But that means the user cannot allocate any space for the data in the first place.
-
At the risk of repeating myself, that is not going to work. If you are going to do all the data manipulation in the lib file and not provide the struct definition to the user, then there is nothing required in the H file at all. But that means the user cannot allocate any space for the data in the first place.
Richard MacCutchan wrote:
At the risk of repeating myself, that is not going to work.
Please repeat, because I really want to know what I'm doing wrong.
Richard MacCutchan wrote:
...and not provide the struct definition to the user...
In the sample code that I showed, the user would have access to the definition of the
Carstruct (which could obviously contain more public members), and to the declaration of theCarPrivatestruct.CarPrivatewould be fully implemented/defined in the LIB file.Richard MacCutchan wrote:
But that means the user cannot allocate any space for the data in the first place.
Are you referring to the user doing something like:
struct Car* car = some_method_to_create_car();
Similar to the
GetYear()function shown earlier, thesome_method_to_create_car()function (that I didn't bother implementing) would have access to theCarPrivatemembers."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
But you cannot do any form of abstraction or encapsulation in C. There is no mechanism for hiding members of a struct.
Richard MacCutchan wrote:
There is no mechanism for hiding members of a struct.
Are you saying that given the H and LIB files I mentioned earlier, that you'd be able to directly access the members of the
CarPrivatestruct?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Richard MacCutchan wrote:
There is no mechanism for hiding members of a struct.
Are you saying that given the H and LIB files I mentioned earlier, that you'd be able to directly access the members of the
CarPrivatestruct?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
Sorry, I misread that. No you could not refer to the members if they are not defined in the header. But in most cases of writing pure C code this is not an issue. Both the caller and the provider need the definition of the struct in order to pass data between them.
-
Richard MacCutchan wrote:
At the risk of repeating myself, that is not going to work.
Please repeat, because I really want to know what I'm doing wrong.
Richard MacCutchan wrote:
...and not provide the struct definition to the user...
In the sample code that I showed, the user would have access to the definition of the
Carstruct (which could obviously contain more public members), and to the declaration of theCarPrivatestruct.CarPrivatewould be fully implemented/defined in the LIB file.Richard MacCutchan wrote:
But that means the user cannot allocate any space for the data in the first place.
Are you referring to the user doing something like:
struct Car* car = some_method_to_create_car();
Similar to the
GetYear()function shown earlier, thesome_method_to_create_car()function (that I didn't bother implementing) would have access to theCarPrivatemembers."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Richard MacCutchan wrote:
At the risk of repeating myself, that is not going to work.
Please repeat, because I really want to know what I'm doing wrong.
Richard MacCutchan wrote:
...and not provide the struct definition to the user...
In the sample code that I showed, the user would have access to the definition of the
Carstruct (which could obviously contain more public members), and to the declaration of theCarPrivatestruct.CarPrivatewould be fully implemented/defined in the LIB file.Richard MacCutchan wrote:
But that means the user cannot allocate any space for the data in the first place.
Are you referring to the user doing something like:
struct Car* car = some_method_to_create_car();
Similar to the
GetYear()function shown earlier, thesome_method_to_create_car()function (that I didn't bother implementing) would have access to theCarPrivatemembers."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
Interesting discussion, since i have implemented similar functionality in the passed. The only thing the user had to work with was a handle and predefined functions that take the handle as an argument. I used this method to create STL type containers. The drawback being there was no type checking, as the data stored was just a block of memory supplied by the user. I used a similar method when creating my old DOS interface library, it would wire up the function pointers defined in the window structure at run-time. Basically all visual elements were a window; how they were wired-up depended on the function called to create them. You cannot created protected members, but you can created hidden members. If I remember correctly, MS uses a similar method when you create a window - there is hidden data. The following is just off the top of my head and does not represent an actual implementation.
/* In ExpContainer.h */
/* this is one possibility for a handle */
#define EXPHANDLE void*EXPHANDLE ExpContainer_Create(size_t data_size, size_t count);
void ExpContainerDestroy(EXPHANDLE hExpContainer);
size_t ExpContainer_Insert(EXPHANDLE hExpContainer, void*, size_t pos);
size_t ExpContainer_Append(EXPHANDLE hExpContainer, void*); // or push_back
/* etc. *//* In ExpContainer.c */
/* example container */
struct ExpContainer
{
/* hidden data can be anything you wish */
size_t data_size_; /* size passed as argument to create method */
size_t size_; /* current number data_size_ elements space allocated */
size_t used_; /* current number of elements */
void* data_; /* just one possibility for storage *//\* the handle/pointer will be pointing to this value \*/ unsigned signature\_; /\* in case you want handle validation \*/};
EXPHANDLE ExpContainer_Create(size_t data_size, size_t count);
{
/* create a new container */
struct ExpContainer* pContainer = malloc(sizeof(struct ExpContainer));/* continue with other initiation */
/* return a handle to the user */
return (EXPHANDLE)(pContainer + offsetof(signature_));
}INTP "Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra "I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
-
Why C is not popular among developers?
Aakashdata wrote:
Why C is not popular among developers?
What developers are you referring to specifically? The ones here? Probably because the pool here is mainly focused on windows. But in general it is a rather popular language and has been so for a long time. TIOBE Index | TIOBE - The Software Quality Company[^]
-
Interesting discussion, since i have implemented similar functionality in the passed. The only thing the user had to work with was a handle and predefined functions that take the handle as an argument. I used this method to create STL type containers. The drawback being there was no type checking, as the data stored was just a block of memory supplied by the user. I used a similar method when creating my old DOS interface library, it would wire up the function pointers defined in the window structure at run-time. Basically all visual elements were a window; how they were wired-up depended on the function called to create them. You cannot created protected members, but you can created hidden members. If I remember correctly, MS uses a similar method when you create a window - there is hidden data. The following is just off the top of my head and does not represent an actual implementation.
/* In ExpContainer.h */
/* this is one possibility for a handle */
#define EXPHANDLE void*EXPHANDLE ExpContainer_Create(size_t data_size, size_t count);
void ExpContainerDestroy(EXPHANDLE hExpContainer);
size_t ExpContainer_Insert(EXPHANDLE hExpContainer, void*, size_t pos);
size_t ExpContainer_Append(EXPHANDLE hExpContainer, void*); // or push_back
/* etc. *//* In ExpContainer.c */
/* example container */
struct ExpContainer
{
/* hidden data can be anything you wish */
size_t data_size_; /* size passed as argument to create method */
size_t size_; /* current number data_size_ elements space allocated */
size_t used_; /* current number of elements */
void* data_; /* just one possibility for storage *//\* the handle/pointer will be pointing to this value \*/ unsigned signature\_; /\* in case you want handle validation \*/};
EXPHANDLE ExpContainer_Create(size_t data_size, size_t count);
{
/* create a new container */
struct ExpContainer* pContainer = malloc(sizeof(struct ExpContainer));/* continue with other initiation */
/* return a handle to the user */
return (EXPHANDLE)(pContainer + offsetof(signature_));
}INTP "Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra "I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone