LinuxQuestions.org
Page 2 of 3 1 2 3
Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Understanding Class Member Functions (https://www.linuxquestions.org/questions/programming-9/understanding-class-member-functions-4175467477/)

Sergei Steshenko 07-01-2013 08:13 AM
Quote:
Originally Posted by ta0kira (Post 4981676)
Good point. In fact, you can even change the underlying language while keeping the API the same.

Kevin Barry
And, furthermore, a typical Linux application is dynamically linked, so, for example, parts of standard library, or even the whole standard library, can be replaced. A keyword to look up on 'net: LD_PRELOAD.

psionl0 07-02-2013 06:59 PM
Quote:
Originally Posted by Sergei Steshenko (Post 4981666)
To be fair, the same can be done in "C" - luckily, DLLs (I am not talking specifically about Windows) exist as concept and implementation.
It is true that you can always write a function that calls a library function then does its own thing. C++ does not add to the functionality of C.

What C++ does do is save some of the work that would otherwise go into modifying a module. If you wanted to "extend" a structure in C (ie add new members to it) you would first need to make a copy of the original structure to do so. Any function that took the original structure as a parameter would have to be re-written for the new structure even if it did nothing different. If both structures are present in the same program then you would need to give the new functions different names (there is no "method overloading" in C).

For a single programmer, this would mainly be just a copy and paste exercise and no great hardship. However, in a multi-programmer environment, there would be considerable scope for mis-communication. In C++ none of the foregoing is necessary. If you don't like the way a team mate has written a class, you can just make a derived class from it that is more to your liking. You can even make any instances of that derived class private to avoid making waves.

Sergei Steshenko 07-02-2013 07:16 PM
Quote:
Originally Posted by psionl0 (Post 4982908)
...Any function that took the original structure as a parameter would have to be re-written for the new structure even if it did nothing different. If both structures are present in the same program then you would need to give the new functions different names (there is no "method overloading" in C).

For a single programmer, this would mainly be just a copy and paste exercise and no great hardship. However, in a multi-programmer environment, there would be considerable scope for mis-communication. In C++ none of the foregoing is necessary. If you don't like the way a team mate has written a class, you can just make a derived class from it that is more to your liking. You can even make any instances of that derived class private to avoid making waves.
???????????????????????????

I define types in separate files and then include them into the code doing processing.

So, if I initially have in separate file (say, 'foo_struct.h') :

Code:
typedef struct
  {
  int i;
  double d;
  } foo_struct;
and then I decide to extend it (because I need new functionality implemented via new functions) to become

Code:
typedef struct
  {
  int i;
  double d;
  float f; // newly added field
  } foo_struct; // the 'foo_struct' name has _not_ changed
, what do I need to rewrite in already written functions ?

...

The horror and beauty of C++ is template engine, and C++ is overall more strictly typed language.

psionl0 07-02-2013 07:23 PM
As a single programmer working on a single program, what you have done is fine. However, if a team mate was in charge of that section of code, he might not appreciate you modifying his header file.

Sergei Steshenko 07-02-2013 07:25 PM
Quote:
Originally Posted by psionl0 (Post 4982916)
As a single programmer working on a single program, what you have done is fine. However, if a team mate was in charge of that section of code, he might not appreciate you modifying his header file.
Alas, adopted code screwing practices are mostly nonsense. Header files are interfaces and as such should be controlled by project level architects and not "everyday" coders.

Conceptually header files are derived from spec.

ta0kira 07-02-2013 07:25 PM
Quote:
Originally Posted by Sergei Steshenko (Post 4982914)
???????????????????????????

I define types in separate files and then include them into the code doing processing.

So, if I initially have in separate file (say, 'foo_struct.h') :

Code:
typedef struct
  {
  int i;
  double d;
  } foo_struct;
and then I decide to extend it (because I need new functionality implemented via new functions) to become

Code:
typedef struct
  {
  int i;
  double d;
  float f; // newly added field
  } foo_struct; // the 'foo_struct' name has _not_ changed
, what do I need to rewrite in already written functions ?

...

The horror and beauty of C++ is template engine, and C++ is overall more strictly typed language.
Unfortunately it's not that simple if data structures, or pointers to them, are passed among libraries that are compiled at different times. In general, you need to recompile every library or binary that accesses a member of a class/struct if you change it. The few exceptions are in C++ (e.g. only changing the body of a function, adding a non-virtual member function,) and only if you link all member functions into a single library and link users of the class to that library. This generally rules out trying to tweak templates without anyone noticing.

Kevin Barry

psionl0 07-02-2013 07:38 PM
Quote:
Originally Posted by Sergei Steshenko (Post 4982917)
Header files are interfaces and as such should be controlled by project level architects and not "everyday" coders.
If a bureaucracy is involved then that makes what you suggested even more difficult. ;)

Quote:
Originally Posted by ta0kira (Post 4982918)
In general, you need to recompile every library or binary that accesses a member of a class/struct if you change it.
I take it you are referring to C. In C++ creating an extended class doesn't involve modifying the original class.
EDIT: I see that you have clarified your post.

Sergei Steshenko 07-02-2013 07:49 PM
Quote:
Originally Posted by psionl0 (Post 4982921)
If a bureaucracy is involved then that makes what you suggested even more difficult. ;)

I take it you are referring to C. In C++ creating an extended class doesn't involve modifying the original class.
What bureaucracy ?

For example, I used to be VLSI project integrator, and part of my job duties was to maintain the project level header files.

Designers did not change project level header files, I did not change block level header file.

...

It is possible to have per developer extensions in "C", with some textual overhead, e.g. to begin with

Code:
// contents of 'foo_body' include file
  int i;
  double d;

Code:
// contents of 'foo_struct.h'  include file
typedef struct
  {
#include "foo_body"
  } foo_struct
.

Then "derived class" can be implemented as

Code:
// contents of 'foo_struct.h'  include file
#define foo_struct extended_foo_struct
typedef struct
  {
#include "foo_body"
#include "foo_extension_body"
  } foo_struct
, and each developer chooses actual name and contents for/of 'extended_foo_struct', 'foo_extension_body'.

psionl0 07-02-2013 08:09 PM
OK, so not impossible but it has definitely become more complicated than you originally made out.

Is there any reason why you would prefer your programmers to use C instead of C++ in the scenario you have outlined?

Sergei Steshenko 07-02-2013 08:48 PM
Quote:
Originally Posted by psionl0 (Post 4982939)
...
Is there any reason why you would prefer your programmers to use C instead of C++ in the scenario you have outlined?
I didn't say I would prefer your programmers to use C instead of C++, I was simply pointing out that perceived/declared in this thread advantages of C++ are not that advantages - because the examples are implementable in "C".

I reiterate: the two real IMO advantages of C++ is templates (with all their debugability horror) and overall better type strictness.

IIRC, in 2011 stndard threads are part of C++ standard library, there is some lambda-calculus, better enums, etc.

psionl0 07-02-2013 10:12 PM
Quote:
Originally Posted by Sergei Steshenko (Post 4982965)
I reiterate: the two real IMO advantages of C++ is templates (with all their debugability horror) ...
I don't understand what you are saying. You appear to be dismissing the ability to create a derived class without the need to touch the original source code as having no particular advantage.

Sergei Steshenko 07-03-2013 07:36 AM
Quote:
Originally Posted by psionl0 (Post 4983025)
I don't understand what you are saying. You appear to be dismissing the ability to create a derived class without the need to touch the original source code as having no particular advantage.
I have shown that properly textually structured "C" code allows to create derived class (i.e. derived, i.e. extended struct) without the need to touch "the original source code", i.e. the original struct.

psionl0 07-03-2013 08:14 PM
Quote:
Originally Posted by Sergei Steshenko (Post 4983374)
I have shown that properly textually structured "C" code allows to create derived class (i.e. derived, i.e. extended struct) without the need to touch "the original source code", i.e. the original struct.
That was the bit I understood. You have demonstrated that it is possible to set up "extendable" structures in C if you have the necessary "textual overhead" in the header files.

If the other person hasn't gone to that trouble then you are back to copy and paste. Also, in either case, you can not use the other person's object file - you have to re-compile his source in order for the functions to use the extended structure.

Method overriding is not possible in C.
Code:
class A
{
  ... ... ...
  public:
      void a_method()
      {
        ... ... ...
      }
};

class B : public A
{
  ... ... ...
  public:
      void a_method()
      {
        ... ... ...
        A::a_method();
        ... ... ...
      }
};

Sergei Steshenko 07-03-2013 08:36 PM
Quote:
Originally Posted by psionl0 (Post 4983808)
...
Method overriding is not possible in C.
...
Method overriding is possible in "C" since "C" has pointers to functions.

What is impossible in "C" is to create a number of functions with the same name, but different signatures, and let the compiler choose the needed one according to number of arguments and their type.

psionl0 07-03-2013 09:10 PM
Quote:
Originally Posted by Sergei Steshenko (Post 4983816)
Method overriding is possible in "C" since "C" has pointers to functions.
This is true.

If keeping the same names is not a matter of life and death, you can extend a struct and its "methods" in C without recompiling the original source in the following way:
Code:
struct base_struct
{
  ... ... ...
};

struct extended_struct
{
  // copied and pasted from base_struct
  ... ... ...  // extra bits
};

void base_func(struct base_struct b)
{
  ... ... ...
};

void copy_extended(struct base_struct *b; struct extended_struct e)
{
  // copies members from extended struct to base struct
};

void extended_func(struct extended_struct e)
{
  base_struct b;
  ... ... ...
  copy_extended(&b, e);
  base_func(b);
  ... ... ...
}


All times are GMT -5. The time now is 05:39 AM.
Page 2 of 3 1 2 3
Show 50 post(s) from this thread on one page