Popularity Of C among developer
-
Why C is not popular among developers?
And what is popular among developers?
-
And what is popular among developers?
-
Why C is not popular among developers?
-
Richard MacCutchan wrote:
Wine, women and song.
<looks around> Where?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Richard MacCutchan wrote:
Wine, women and song.
:-D :thumbsup:
-
And i really do like 'M'... :laugh:
-
Why C is not popular among developers?
C is highly portable and simple language. But, because of some limitation of C, it is loosing fame. The main reason behind is, it doesn't support object-oriented programming features. Means- Inheritance Encapsulation Polymorphism etc. are not suported by C programming language, that's why C++ is developed. Even C doesn't perform run time type checking.
-
C is highly portable and simple language. But, because of some limitation of C, it is loosing fame. The main reason behind is, it doesn't support object-oriented programming features. Means- Inheritance Encapsulation Polymorphism etc. are not suported by C programming language, that's why C++ is developed. Even C doesn't perform run time type checking.
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
-
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.
