Software maintenance

[BGB / cr88192]

It's not that hard to hide these things behind a few functions and
preprocessor macros -- BTDT.


The effective scheme comes down to just that -- you call your member
functions through pointers in the struct. How is this "murdering the
language"?

<--
A toy example will have just a few function pointers embedded in a
struct. You can achieve polymorhism of a sort.

When you move to a full-blown system, you realise that this simple
system doesn't provide you with the flexibility that you need. You
need to pass in a void pointer. You then need to query it for the
interface. You then need to get the function pointer from the
interface. You then need to adjust the pointer to the right base. Then
you call the function. It returns a void pointer which you have to
query for another interface ... The code doesn't look like C.
-->

one can wrap the whole mess in an API vaguely resembling the object system
exposed by JNI...

dycClass iface;
dycObject obj;
dycMethod mth;
float f;
....
iface=dycGetClass("myapp/mypkg/IFoo");
mth=dycIdxMethod(iface, "fooMethod(ii)f");
....
f=dycCallf(obj, mth, 3, 4);

however, all this proved somewhat awkward, and adds a lot of interface
overhead (via direct access via structs, casting, and function pointers).

so this is a problem...


a later extension allows things like:
void *fcn;
fcn=dycGetObjMethodAddr(obj, mth);
f=((float(*)(dycObject, int, int))fcn)(obj, 3, 4);

which can be used to reduce the overhead some, but doesn't much help
usability...


so, I am left partly considering a system which can be canonically mapped to
C structs, hence allowing a nicer C-level interface, but I am unsure if this
is a good route either (since as a cost, it could create physical dependency
on the class layout, essentially freezing runtime class layout, whereas the
current system allows extending classes with new fields or methods without
breaking any existing instances via a "versioning" system).


or such...

 

[August Karlstrom]

Only if you inherit and extend functionality, which is necessary
sometimes, but should not be common case in a good OO design.

The ability to make extensible systems is one of the great virtues of OOP.


/August

 

[Felix Palmen]

The ability to make extensible systems is one of the great virtues of OOP.

So? That's correct, but extending a /single method/ is still a corner
case and shouldn't be necessary most of the time. Much more common in a
good design are:

- methods that are needed in derived classes, but not extended
- pure virtual methods that must be defined by the derived class

So, it's not that much of a hassle to have to "save" a pointer somewhere
in a constructor when you really need to extend a methods functionality.
At least, this can't be the reason not to use C for the job

Regards,
Felix

 

[Nick Keighley]

Whether OO is difficult to do really depends on the individual.  If you
tend problem solve by breaking the problem down into objects, it is
easy.  if you don't, it's hard.  I think in objects and I was writing OO
style C long before I discovered the infant C++.

some applications naturally break down into smalltalk-like independent
objects exchanging messages (telecomms, GUIs, Network Management).

Where large C++ ssytems sometimes go wrong is very deeply inheritance
trees. Add in multiple inheritance of implementation and you have a
nightmare.

The antidote to designing systems like this is the Patterns book and
LSP.

 

[Nick Keighley]

Le 13/09/10 10:59, BartC a écrit :

In principle yes, in practice no. Since there are no classes and no
hierarchy, overloading is easy to follow. In all documentation I
underscored that operator overloading works with types that should mimic
the typical types used with that operators.

Which is the motivation for operator overloading in C++.

Arithmetic operators work
well with NUMBERS (of any kind) and should be AVOIDED with anything else
but NUMBERS. Generalized sequential container access with the square
brackets operator should be used for indexing ONLY.

So the difference between your implementation and C++ in this regard is?

Some exceptions are so standard that they can be used, for instance:

HashTable *h;
/* ... */
h["some key"] = foo;

In general however, operator overloading should NOT be overused. I
warned explicitely in my documentation against this.

As do all decent C++ texts.

but C++ does typically have more exceptions to the "only use for
numbers" rule

streams, functors, container access, smart pointers, string
concatenation, assignment, comparison, conversion operators

I bet boost has a slew more


But I agree there doesn't seem to anything except the documentaion
preventing you from going a similar route with lcc-win

 

[Malcolm McLean]

So? That's correct, but extending a /single method/ is still a corner
case and shouldn't be necessary most of the time. Much more common in a
good design are:

Imagine the following system: we derive everythign from a base class
"object".

"Object" has methods destroy, copy, clone (copy and return a malloced
object), serialise, deserialise, tostring, fromstring.

All of these methods except "clone", typically, will be implemented in
dervived classes by calling the base class. For instance to serialise
you serialise the data members of the base class, then you serialise
your own members. So there needs to be a chin of "serialise" function
pointers.
The scheme will work, but you see the sorts of problems.

 

[Felix Palmen]

Imagine the following system: we derive everythign from a base class
"object".

That's quite common.

"Object" has methods destroy, copy, clone (copy and return a malloced
object), serialise, deserialise, tostring, fromstring.

Well, let's see. I identify two classes of methods here:
- constructors/destructors (destroy, copy, clone)
- common utility methods (can't imagine a better name right now)

For the constructors/destructors, I created a scheme that allows for
simple calling of their respective parents through macros BASECTOR and
BASEDTOR, also leaving the actual memory management to macros (NEW and
DELETE). This works with very little overhead. I don't need copy
construction ATM, but this could be done quite similar.

For the second class, these common utility methods -- at least for
serialize/deserialize it would really make sense to always call the base
class' implementation first. I'm right now working on a project that
doesn't need this kind of methods. If your model ultimately has many of
these utility methods, you're probably better off using another
language.

The scheme will work, but you see the sorts of problems.

Well, I still state doing OOP (including polymorphism) in C is possible
and not really "murdering the language". Of course, it just depends very
much on your problem und your solution model, like always.

Regards,
Felix

 

[Brian]

jacob navia wrote:
[snip]

You entire post and every "point" in it was a strawman.

 

[jacob navia]

Le 16/09/10 08:06, Brian a écrit :

jacob navia wrote:
[snip]

You entire post and every "point" in it was a strawman.

Of course.

When you have no arguments the best thing to do is some polemic remarks,
and that was it.

 

[Brian]

Le 16/09/10 08:06, Brian a écrit :

jacob navia wrote:
[snip]

You entire post and every "point" in it was a strawman.

Of course.

When you have no arguments the best thing to do is some polemic
remarks, and that was it.

Not it at all, you were ranting or something similar/worse and that made
any other response pointless. Lookup the word "strawman" and analyze your
own post, though I am almost sure you know exactly what I am talking
about. You must think that people are pretty stupid.

 

[Nick Keighley]

Le 16/09/10 08:06, Brian a écrit :

jacob navia wrote:
  [snip]
You entire post and every "point" in it was a strawman.

Of course.

When you have no arguments the best thing to do is some polemic
remarks, and that was it.

Not it at all, you were ranting or something similar/worse and that made
any other response pointless. Lookup the word "strawman" and analyze your
own post, though I am almost sure you know exactly what I am talking
about. You must think that people are pretty stupid.

I've no idea what you are on about. If you have a specific criticism
of Jacob's post why not state it explicitly. Or are you just trolling?

 

[Brian]

Le 16/09/10 08:06, Brian a écrit :
jacob navia wrote:
[snip]

You entire post and every "point" in it was a strawman.

Of course.

When you have no arguments the best thing to do is some polemic
remarks, and that was it.

Not it at all, you were ranting or something similar/worse and that
made any other response pointless. Lookup the word "strawman" and
analyze your own post, though I am almost sure you know exactly what
I am talking about. You must think that people are pretty stupid.

I've no idea what you are on about. If you have a specific criticism
of Jacob's post why not state it explicitly. Or are you just trolling?

I started to add some thoughts, but after a few responses I realized he
had an agenda so didn't post anything other than the overall assessment.
Maybe you don't know C++ (he certainly doesn't get it) and so don't know
or maybe you haven't been with the industry for 20 years and can't see
right through his specious rants. If he was just getting a load off of
his chest than so what, but if he thought anyone other than the
uninitiated bought it, then he's disillusioned. A
not-so-cleverly-disguised "Why C is better than C++" rant or troll that
does nothing to improve the quality of the languages, this ng or it's
participant list. Indeed, it's posts like that that keep people out for
they assume that the group is made up of stupid people who actually
believe bullshit. (Not that it doesn't seem to be a more widespread
behavior than just him, I have observed). He knows it's BS too and that's
why he tactically puts in the weasel words when he states something, so
he can come back and say, "oh, but what I said was... see <the weasel
word>?". He thinks he is clever but the opposite is true.

 

[Malcolm McLean]

I started to add some thoughts, but after a few responses I realized he
had an agenda so didn't post anything other than the overall assessment.
Maybe you don't know C++ (he certainly doesn't get it)
A not-so-cleverly-disguised "Why C is better than C++" rant or troll that
does nothing to improve the quality of the languages, this ng or it's
participant list.

What annoys me is that you can give a perfectly well-reasoned
explanation why C++ and object-orientation isn't the route to go, and
someone somewhere will always say, "that's because you are too stupid
for C++". Of course in a sense they are right - if we all had super
brains we'd all program in brainf**k - programming languages are
designed to get round human limitations in understanding the
complexities of software.

C++ is a superset of C, so if C survives at all, it must be because
the C++ extensions have some disadvantages. What Jacob is trying to do
is to identify those disadvantages, and produce effectively a new
language - C+=0.5 let's call it - which doesn't incorporate the
disadvantages but has the advantageous features of C++. Whether he's
actually succeeded in doing this is another issue, but it's a
perfectly reasonable thing to attempt.

 

[Ian Collins]

C++ is a superset of C, so if C survives at all, it must be because
the C++ extensions have some disadvantages. What Jacob is trying to do
is to identify those disadvantages, and produce effectively a new
language - C+=0.5 let's call it - which doesn't incorporate the
disadvantages but has the advantageous features of C++. Whether he's
actually succeeded in doing this is another issue, but it's a
perfectly reasonable thing to attempt.

The point he (Jacob) either doesn't get or refuses to concede is that
language is already there. If you only want to use the C subset of C++
and a few extras, then just use them. No one or no compiler is forcing
the bits you don't want on you. That is part of the philosophy of C++:
you don't pay for what yo don't use.

 

[Nick Keighley]

I don't see this question answered

I started to add some thoughts, but after a few responses I realized he
had an agenda

he probably does. So which bits of his post are wrong or refutable? Is
there no reasoned argument you can present? If you look else-thread
you'll see I tried to address some of his points.

so didn't post anything other than the overall assessment.
Maybe you don't know C++

maybe I don't. Maybe I do know C++ and am aware of some of its
problems. Maybe I'd like tolearn more about C++ and how toprogram in
it. I've learned nothing fromyour post (except you think you're a
smarter programmer than Jacob Navia)

(he certainly doesn't get it)

why not? What's he missed? Be specific.

and so don't know
or maybe you haven't been with the industry for 20 years

If you're the Brian that posted the bitset macros I'd be astonished if
you'd been in the industry 20 years.

For the record, yep, I've been programming in the industry for 20
years or more.

I thought this thread was discussing some software engineering
principles in a fairly adult fashion.

Jacob can be a little polemnical but he also isn't stupid. So far he's
contributed more to this thread than you have.


<snip whiney rant>

 

[Nick Keighley]

On 16 Sep, 10:47, Malcolm McLean <[email protected]>
wrote:

What annoys me is that you can give a perfectly well-reasoned
explanation why C++ and object-orientation isn't the route to go,

like for instance? I'm dubious of any "this is THE way to program".
Including nested templates, OO and low level C. A carpenter has more
than one tool in his bag why shouldn't a programmer?

and
someone somewhere will always say, "that's because you are too stupid
for C++".

I'm not fond of this argument either. I tend to doubt the proponent of
it knows what he's talking about.

Of course in a sense they are right - if we all had super
brains we'd all program in brainf**k - programming languages are
designed to get round human limitations in understanding the
complexities of software.

not really. They are designed to express our ideas clearly. BF was
designed as a joke. C and C++ were both designed to make certain ideas
about programs easily accessible.

"Programs should be written for people to read, and only incidentally
for machines to execute."
Structure and Interpretation of Computer Programs.

C++ is a superset of C,

not really. They are languages in their own right and it is somewhat
incidental that they share a small common subset.

so if C survives at all, it must be because
the C++ extensions have some disadvantages.

no. It's more a case that they address different niches. C is small
and simple and close to the hardware. This makes it well suited to
embedded systems, OSs, VMs. It is also *very* portable.

C++ is designed for larger systems it has classes, templates and
exceptions. OO suits certain application domains very well (GUIs,
Telecomms, probably games).

What Jacob is trying to do
is to identify those disadvantages, and produce effectively a new
language - C+=0.5 let's call it - which doesn't incorporate the
disadvantages but has the advantageous features of C++.

personnally I think he's on a hiding to nothing. By the time he's a
added all the features he thinks C needs his language will be
appraoching the complexity of C++. But it is interesting and some of
his ideas are quite cool.

Whether he's
actually succeeded in doing this is another issue, but it's a
perfectly reasonable thing to attempt.

no argument

 

[Brian]

What annoys me is that you can give a perfectly well-reasoned
explanation why C++ and object-orientation isn't the route to go, and
someone somewhere will always say, "that's because you are too stupid
for C++". Of course in a sense they are right - if we all had super
brains we'd all program in brainf**k - programming languages are
designed to get round human limitations in understanding the
complexities of software.

C++ is a superset of C, so if C survives at all, it must be because
the C++ extensions have some disadvantages.

Maybe, but I find going back to C too big a pill to swallow after using
C++ (for many years and understanding how to use it, though I do it
differently than the status quo, go figure).

What Jacob is trying to do
is to identify those disadvantages,

No, he is picking out extreme bad programming and suggesting that is the
common case. It's a classical strawman post but way over the top with the
lame attempt at being convincing by avoiding the real issues. Even with
that lame attempt though, he hasn't even mentioned C++'s biggest problems
or ways to eliminate those in either a library or a language proper.

and produce effectively a new
language - C+=0.5 let's call it - which doesn't incorporate the
disadvantages but has the advantageous features of C++.

They call that D, yes? Problem solved? If not, why not? It's a fine thing
to do, if just for the learning experience, but why not just be up front
about the issues instead of sensationalizing a few relatively minor C++
shortcomings? Doing it better than C or C++ isn't good enough anymore.
Now it has to be better than both of those and Java and C# and D and Go
and...

Being annoying does not a leader make. Regurgitating strawman arguments
only affirms unsuitability for the task. Get into politics if that is
your mode of operation and forget about ever becoming an engineer.

 

[BartC]

The point he (Jacob) either doesn't get or refuses to concede is that
language is already there. If you only want to use the C subset of C++
and a few extras, then just use them. No one or no compiler is forcing
the bits you don't want on you. That is part of the philosophy of C++:
you don't pay for what yo don't use.

So why doesn't everybody forget C, and C compilers, and only use the
corresponding subset of C++ with a C++ compiler?

 

[Ian Collins]

So why doesn't everybody forget C, and C compilers, and only use the
corresponding subset of C++ with a C++ compiler?

Not all targets have a C++ compiler and there are a huge number of
existing C projects that have no reason to change. They won't be
changing to Jacob's dialect any time soon either. I'm not advocating
anyone changes horses, I'm just saying "C+=0.5" already exists.

I have worked with former C teams who have successfully adopted a
minimal subset of C++.

 

[Brian]

I don't see this question answered

Look immediately below.

he probably does. So which bits of his post are wrong or refutable?

Like I said, the whole thing is so lame that it is not worth responding
to other than as a whole, which I already did.

Is
there no reasoned argument you can present?

I don't debate BS.

If you look else-thread
you'll see I tried to address some of his points.


maybe I don't. Maybe I do know C++ and am aware of some of its
problems. Maybe I'd like tolearn more about C++ and how toprogram in
it. I've learned nothing fromyour post (except you think you're a
smarter programmer than Jacob Navia)

While I do program, I'm not "a programmer" nor am I here to teach anyone
to be one.

why not? What's he missed? Be specific.

He'll have to figure it out for himself.

If you're the Brian that posted the bitset macros I'd be astonished if
you'd been in the industry 20 years.

I may submit those to the comittee for inclusion into the standard.

For the record, yep, I've been programming in the industry for 20
years or more.

I thought this thread was discussing some software engineering
principles in a fairly adult fashion.

Who knows what his purpose was but it surely wasn't that. At best he was
trying to be clever and get the answers handed to him instead of figuring
it for himself.

Jacob can be a little polemnical but he also isn't stupid. So far he's
contributed more to this thread than you have.

If you like strawman posts and the tail trying to wag the dog, have a
ball. I refuse to be sucked into it.