Boost process and C

[Ian Collins]

Ian Collins wrote:

I'm not familiar with Java.
It lack operator overloading.



I'm not convinced that it provides added intuition. As I pointed out
in my response to Jacob, any sufficiently complex computation should
have a function to perform it. If foo represents a mathematical object
and we want to perform some computation on it, then whether you have
operator overloading or not, you end up with the code:
compute_contour_integral (A, f);
Having the overloading might encourage someone to write the code
in-line rather than make a function call, leading to more diffictult
code, not less.

The classic example was a complex type, but this in now part of C99.
The example of a 128 bit int type Jacob posted earlier is one good
example of an numeric user type. Others I have used often (in C++) are
time types (with a seconds and nanoseconds part) and pointers to
circular buffers.

User defined big int types are very handy for porting code between
systems that do and don't support them, for example int64_t. You can
use a typedef to select between native of user type and any code that
manipulates them doesn't care whether int64_t is a POD or a user type.

 

[Ben C]

I think Jacob's example applies equally well to this case.

You end up with the same mess that Java has to put up with.

Operator overloading enables you to use a user defined type in the same
way as a built in type. Much more intuitive.

Some of the side-effects are less agreeable though.

You end up needing something like C++ references, in order to provide a
way of overloading the operators in expressions like a = b = c.

In expressions like a = b + c, where a, b and c are all large instances,
you really want to copy the result of b + c directly into a. What you
end up with is operator+(b, c) returning an instance, and then
operator=(a, b) copying the instance into a. Compilers have clever ways
to work around this, while still having to call the constructor for the
temporary b + c and a's assignment operator (or copy ctor if it's an
initialization), as if it were doing add followed by copy, since those
could have arbitrary sideeffects.

Whether this nightmare is acceptable or not is a matter of opinion-- but
it strikes me as a whole new class of nightmare that C never had to deal
with before. Like anything, C has its strenths and weaknesses and one of
the strengths has always been the relative lack of nasty surprises.

Another thing about C is the fact that in general the cost of every
operation is fairly intuitively obvious in what you type. If you type an
expression with operators, you will get a bit of machine arithmetic. If
you need to call a function, you will see the function call. If you copy
a lot of data (rather than just one or two words) you will have to call
memcpy or friends (with the exception of struct instance assignment).
You lose this with operator overloading.

Builtin types and user-defined types are very different things in C, and
these are sensible lines along which to design a machine-oriented
language that runs on machines which have memory for data, and registers
and ALUs for operations on builtin types. In "higher-level" languages
which are further abstracted from the implementation, it's attractive to
remove this distinction-- Python for example achieves this well. But I'm
not convinced of the wisdom of the hybrid, C with operator overloading.

 

[Chris Hills]

There are "MISRA checkers", though, and I remember having seen
the option to activate MISRA-C checks in some lint tool, probably
PCLint.

There are many checkers. However, and this is the problem, there is no
official MISRA/MIRA certification or check on any of the tools that
claim to check MISRA-C.

So it is purely their interpretation of the MISRA rules and how to test
them. That said 99% of the tool vendors are doing it in good faith. SO
there is no write or wrong tool so far. Though a couple have come close
to letting their marketing team too much rope

You may need to specify where you want MISRA-C compliance which tool
should be used to test. You don't want an argument because you use one
tool and the client uses a different one.

Whilst this is not an ideal situation it is improving the general level
of things a lot. Some of the feedback from tool vendors is helping to
remove some of the ambiguity in some rules.

Future releases of MISRA-C should improve and standardise things over
time.

Thank you for the information.

Distribution was discussed last week. I think the suite should be
widely available for both tool vendors and users. We looked at a check
summed distribution so that you know you have a valid (and not edited)
suite.

This sounds promising -- I only can recommend this course of action;
the time and money usually are well invested.

Time and money....

MISRA C++ has taken this route and we will see how they get on.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ (e-mail address removed) www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Ian Collins]

Another thing about C is the fact that in general the cost of every
operation is fairly intuitively obvious in what you type. If you type an
expression with operators, you will get a bit of machine arithmetic. If
you need to call a function, you will see the function call. If you copy
a lot of data (rather than just one or two words) you will have to call
memcpy or friends (with the exception of struct instance assignment).
You lose this with operator overloading.

Builtin types and user-defined types are very different things in C, and
these are sensible lines along which to design a machine-oriented
language that runs on machines which have memory for data, and registers
and ALUs for operations on builtin types. In "higher-level" languages
which are further abstracted from the implementation, it's attractive to
remove this distinction-- Python for example achieves this well. But I'm
not convinced of the wisdom of the hybrid, C with operator overloading.

I agree 100% that operator overloading is inappropriate for C. If you
want it, use C++.

I was responding to the more abstract conjecture that operator
overloading is a bad thing per se, which I believe to be untrue. It
would be a bad thing in C for the reasons you mention, but when used
elsewhere it leads to cleaner, more maintainable code.

 

[jacob navia]

Ian Collins a écrit :

The C++ committee did it, is it too hard for C to do the same?

Apparently yes.

 

[jacob navia]

Ian Collins a écrit :

You appear unable of understanding the simple fact that "all this" is
optional in C++ as well.

In another subthread we had this argument already. It is impossible to
dissociate operator overloading from the object oriented framework in
C++. Some operators need a class to be defined, and the implementation
in C++ of operator overloading lacks essential features like
multi-dimensional array indexing, differentiation between read/write
array access and others.

jacob

 

[extrudedaluminiu]

About libclc - how is that doing? It seems to have just dried up
without notice. Also, I seem

If a C programmer is writing a reasonably large program these days,
what are the first libraries that are commonly used for collections of
data structures, better strings, etc?

 

[extrudedaluminiu]

About libclc - how is that doing? It seems to have just dried up
without notice.

If a C programmer is writing a reasonably large program these days,
what are the first libraries that are commonly used for collections of
data structures, better strings, etc?

 

[jacob navia]

Ian Collins a écrit :

It has been pointed out elsethread that C would require the same baggage
to implement operator overloading. You have to have an object to
operate on! How would yo implement a = b+c on a plain struct without
the means of constructing a temporary object?

In standard C when lcc finds a function that returns a structure by
value like:

STRUCT fn(int arg1);

actually it passes a destination address to fn1 making it:

void fn(STRUCT *__invisiblearg,int arg1);

This allows fn to return its result in an invisible passed in pointer.

I could do with some effort make lcc-win32 recognize the pattern
a = b+c and pass the address of a instead of a temporary.

I will do it this summer when I can work in that part of lcc-win32 again.

The simple point I'm trying to make is you can write C style procedural
code in C++ without any run time support or object related baggage. All
'advanced' features have a cost, paying that cost is the programmer's
choice.

Yes, true. Both languages have a common subset.

Besides, I would like to point out that I am by no means saying that
people that use C++ are bad, or that I do not respect their views. I
have another point of view, that's all.

jacob

 

[CBFalconer]

.... snip ...

Distribution was discussed last week. I think the suite should
be widely available for both tool vendors and users. We looked at
a check summed distribution so that you know you have a valid
(and not edited) suite.

This requires all of a md5sum check file and zip the whole mess
into a single zip.

 

[Bill Pursell]

Bill Pursell a écrit :

lcc-win32 offers qfloats, 350 bit floating pint. Those numbers are easy
to use. To change your precision from double (64 bits) to qfloat (350
bits) you just #define double qfloat and do not have to change anything
in the code. That's the point of all this stuff. Numerical formulae and
computations remain the same even if the precision of the computations
goes up.

If the 350 bit floating point type is a data structure that is known to
the compiler, it seems that it's not really a user defined type. In
other words, when you write the compiler to accept this data type, then
you're completely free to add semantics for operators as well. I
certainly don't think that's a bad thing. I welcome the complex data
type in C99.

I think my concern is that I've seen a lot of horribly written C++
code, and slightly less bad C, and it seems that allowing operator
overloading will just increase the amount of bad C code that's out
there.

 

[Chris Hills]

This requires all of a md5sum check file and zip the whole mess
into a single zip.

Yes. I know. It is one of several options we are looking at.
However there are problems with using this system.

 

[Herbert Rosenau]

The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all functions
must be explicitely be given the length of the strings/buffers/etc even
if it is immediately obvious that the programmer can't know in all cases
what that dammed length is nor should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;

When you nneds a string that knows its length you should use pascal.
It does this by design.

When you needs operator overloading and other OO specific things use
C++. It is designed for that. There is no need for that crap in C.

is too much for the C standards comitee. This structure is split then at
each function call in a data and a length, and it is up to the
programmer to figure out the length without ever making an error.

You proves simply that you knows nothing, abnsolutely nothing about
compilers and theyr design.

I have proposed (and implemented) a demonstration how could that be
done. See the string library of lcc-win32.

That means one has to avoid lcc-win32 because its crap.

Because everyone agrees that C is dead and should NOT be developed any
further. It should be left for embedded systems with small RAM footprint
where C++ can never run.

Now you're gets megalomaniac. You are not everyone, you are either o
nly another alias of Twitsdale or his brother, knowing nothing about
C. There are currently written more programs in C than in any other
languages together.

As the hardware evolves and even small gadgets feature megabytes of RAM
those niche applications will be more and more difficult to find.

Niche? Windows is only one little niche in the aspect of the number of
different programs programmed in C today, not counted the maintenance,
new developement that gots out the factories dayly. You're really only
an alias of Twitsdale or Schellong knowing nothing abaout reality.

Of course, but they willl not agree with this, obviously. They are still
in C89 and the few points that C99 brought in the sense of a better
language are just denied. Each time I remind people about them, they
tell me that "not all compilers support C99" what is true but doesn't
make things advance at all.

Speaks Twitsdale.

If there is no clear place where the evolution of C can be

Yes, and that is why I still try to discuss serious perspectives in this
group. Maybe because lcc-win32 is the only compiler system that is
centered around C and it is not just a C++ compiler that can also do
some C compilations.

Says a twit who has no knowledge about the real world.

Yes, but the problem is that in the C standards comitee most people care
much more about C++ than C. There is no compiler for C today. All are
C++ compilers that can do C as an after thought. Gcc has implemented
most of the standard but still never makes it to finish it.

And again you proves that you has absolutely no idea to the real
world.

Microsoft doesn't care at all, and pursues its own standards through the
windows platform, where it can dictate whatever it wishes.

Apple has got objective C, and sticks to it.

-------------------------

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.

Whjen you needs it you would know which language serves that to you. C
has no need for that.

This small change would make possible to write good string libraries,
good numerical libraries, etc.

When you are unhappy with C got to C++ for object oriented language,
pascal for pecaluar string libraries not even C++ owns by standard but
don't think that changing the features C owns are a good idea.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.

Why does you whine about missing OO features the OO language C++ gives
you for free already? It seems you are too kimited in brain to get
that C is not an OO language and never will be.

And that is all. Small but essential changes that would make C a very
good language without loosing the simplicity, what is its greatest
asset. The problem of C++'s complexity is known. C with those minor
modifications would be a very useful language.

You are really an alias of Twitsdale.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Ian Collins a écrit :

Why?

Why should I swallow that big fat language?

I just want a few specific features that are part of many programming
languages, from fortran to visual basic...

Then use fortran and its not available operator overloading, its
ackwards string handling. As you says it gives what you asks for why
does you don't use it.

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you

Yes but without all the other well known object oriented techniques
C++ owns already it is completely ueseless. So again, use fortran when
you means that this language gives you what you miss in C or simply
use C++ as it owns already the ability to use operator overloading.ö C
has no need for that.

Same thing. Why take all that machinery when it is not needed?

It is YOU who says that an programming language that does not need it
has to give it to you. As C++ gives you what you needs you should use
it instead of a language that is not designed to produce it.

The problem with ultra FAT languages like C++ is their incredible
complexity!

Constructors and destructors?

Who needs them?

YOU, because you needs operator overloading, that requires constuctors
to define the operators to overload and destructors to undefine them.

Just get a sensible garbage collector and be done with the need for them.

Java gives you that. Use Java or C++ if you needs it. I found already
out that onloy trolls, twits and mental amputated peoples who are
unable to write a simple "hello world" C program have a real need for
GC.

Object oriented programming can be nice in *some* situations but why
should it be FORCED into everyone?

Again C++ is the right way for you as it gives you all and anything
you asks for. You will be able to ignopre any OO capabilities of C++
but then you will ignore ooperator overloading too. You cries for a C
that does exactly what C++ does already. You are a twit.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[CBFalconer]

.... snip ...


Why does you whine about missing OO features the OO language C++
gives you for free already? It seems you are too kimited in brain
to get that C is not an OO language and never will be.


You are really an alias of Twitsdale.

Back in the last century I downloaded, and actually used, Navia's
system. I wondered at the time why it never showed up in the
recommended list of C systems for the x86, since it seemed fairly
usable after disabling some of the outre monstrosities (such as GC,
overloading, etc.) and it was fairly handy to be able to flip into
a debugger instantaneously.

Then I observed various things. For one, it depended on the
brain-dead Microsoft C dll and didn't create proper independent
modules. There was never any indication of revision levels, except
that suddenly the debugger no longer worked at all, it just crashed
immediately (it apparently suddenly used Pentium only instructions,
without bothering to check what it was running on). The total lack
of regression checks had led to this, and the various brand new
bugs reported on the lcc newsgroup confirmed the lack of testing.
At the time I reported it, and there was no effort to repair it.

It is probably all very well for someone willing to use Beta (at
best) software, but it is certainly not recommended. I think it
has done much harm to the reputation of the reputedly accurate LCC
compiler (which is not limited to Windoze use).

My conclusions: Lcc-win32 allows you to test Beta software, with
the advantage of easily creating totally non-portable off-beat
source which is useless elsewhere. Some sort of exercise in
masochism. I have kept these conclusions more or less to myself
for some time, but Navia's insistence on posting silly off-topic
material here and insulting those who object has aroused my ire.
His recent citing of Trollsdale as an authority goes beyond any
pale.

 

[websnarf]

About libclc - how is that doing? It seems to have just dried up
without notice.

If a C programmer is writing a reasonably large program these days,
what are the first libraries that are commonly used for collections of
data structures, better strings, etc?

Well, I know that "better strings" are somewhere on that list for a lot
of people, if the periodic requests for feature improvements for
Bstrlib from people starting new projects are any indication.

 

[Keith Thompson]

(e-mail address removed) a écrit :

Nowhere. Since the C standard comitee refuses to improve the language,
there are a lot of libraries but all of them incompatible.

Perhaps I should have pointed out that, although comp.std.c is the
best newsgroup to discuss changes to the C standard, there's no
guarantee that anyone will actually like your idea, and nobody has any
obligation to discuss it.

Basically, the opinion here is that data structures are too much of an
intellectual effort for C programmers...

Adding a smiley to a pointless insult doesn't make it any less
insulting.

 

[Keith Thompson]

The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all
functions must be explicitely be given the length of the
strings/buffers/etc even if it is immediately obvious that the
programmer can't know in all cases what that dammed length is nor
should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;

is too much for the C standards comitee. This structure is split then
at each function call in a data and a length, and it is up to the
programmer to figure out the length without ever making an error.

Are you suggesting that the C standard should be changed so that
strings are no longer terminated by '\0'? There are dozens of
standard library functions that use this representation, and it's
central to the semantics of string literals.

Conceivably you could add a new string representation *in addition to*
the existing one. You would then be permanently stuck with two
distinct and incompatible ways of representing strings. (Breaking
nearly all existing code is not an option.)

Of course, it's easy enough to implement this kind of thing in a
library using purely standard C; perhaps that's why there isn't much
enthusiasm for adding it to the language.

I have proposed (and implemented) a demonstration how could that be
done. See the string library of lcc-win32.

If you'll provide a pointer to the documentation, I might take a look
at it. (If I can't read the documentation without installing
lcc-win32, I'm not going to bother.)

[...]

Of course, but they willl not agree with this, obviously. They are
still in C89 and the few points that C99 brought in the sense of a
better language are just denied. Each time I remind people about them,
they tell me that "not all compilers support C99" what is true but
doesn't make things advance at all.

Speaking only for myself, I routinely quote from the C99 standard.
Yes, I and others often point out that not all compilers support C99.
We do so because it happens to be true, and programmers in the real
world need to be aware of that fact.

[...]

Yes, but the problem is that in the C standards comitee most people
care much more about C++ than C. There is no compiler for C today. All
are C++ compilers that can do C as an after thought. Gcc has
implemented most of the standard but still never makes it to finish it.

<OT>
gcc is a suite of compilers with a common backend. The C and C++
frontends are separate. There are also frontends for a number of
other languages, including Fortran, Objective C, and Ada.

C is certainly not an "afterthought".

Microsoft doesn't care at all, and pursues its own standards through
the windows platform, where it can dictate whatever it wishes.

Apple has got objective C, and sticks to it.

Which suggests a possible approach. If you want to use a C-like
language, but you don't think standard C has some feature you require,
*use a different language*. Changing the C standard itself, even if
there's general agreement that your change is a good idea, will take
many years; that's just the nature of the standardization process.
Any such change will be imposed on *all* conforming implementations.
There are numerous other C-like languages that you can use *today*.
One of them happens to be the C-like language implemented by
lcc-win32; I'm fairly sure you have access to it.

Nobody is preventing you from implementing and using whatever
extensions you like. The only thing you're having a problem with is
your inability to impose those extensions on the entire world.

 

[Richard Heathfield]

jacob navia said:

We had this discussion already. I started yet another discussion about
the need for a portable standard container library several times and the
answers were:

The standards comitee doesn't even accept simple data structures like
strings. Lists, flexible arrays, stacks, queues, etc etc must be done
over and over, and are kept OUTSIDE the standard library.

Why?

Well, okay, let's just say for the sake of argument that we're going to add
standard data structure APIs to C.

First step - decide what's in and what's out. Let battle commence.

When you eventually get the blood out of the carpet, the second step is to
agree on an interface. That will take forever and a day.

Third step - get people to use your shiny new standard container library.
Except that they won't, of course, because they will all just carry on
using whatever it is that they're using right now.

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

Until they have to port it to a new environment.

Mine ports just fine, thanks. You know why? Because I am careful to write
portable code that isn't full of silly use-me-and-lock-yourself-in
extensions such as are to be found in, say, lcc.