Hi,
Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?
Thanks,
-vs
Apr 29 '06
335  11418 
Bill Pursell wrote: Ian Collins wrote:
I'm not familiar with Java.
It lack operator overloading.Operator overloading enables you to use a user defined type in the same
way as a built in type. Much more intuitive.
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.
--
Ian Collins.
Bill Pursell a écrit : As I said, I'm not suggesting that the basic arithmetic operators be
removed from the language, and this is an excellent example of their
utility. Can you come up with a similar example that doesn't rely on
fundamental types? I've never seen an object in any language that was
prone to this type of calculation, and certainly never seen a structure
in a C program to which this would apply. Any such calculation should
be performed by a function anyway, so rather than forcing the
maintenance programmer to parse:
z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);
that same programmer would have to parse:
z = determinant( A);
or the like.
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.
Besides, making a function for every moderately complex statement is an
overkill. The equation above is just one line, but in any serious
mathematical software there are literally hundredths of them.
Of course you can misuse operator overloading, as you can misuse anything.
For instance the famous overloading of the "+" operator for character
strings that C++ promotes is WRONG (this is not "shouting" is just
emphasis!)
Why?
Because + is commutative in maths: a+b is equal to b+a, and that is not
the case with a+b when a and b are strings:
"Hello" + " World" is different from
"World" + "Hello"
Ingeneral operator overloading is good with numbers because it allows
people to create their own types of numbers.
Yes, you have to COMPILE THEM by hand producing this incredible GIBBERISH!
tmp1=float_add(a,b);
tmp2=float_sub(b,d);
tmp3=float_div(tmp1,tmp2);
tmp4=float_mul(0.5,d);
tmp5=float_mul(a,d);
tmp6=float_mul(b,d);
tmp7=float_sub(tmp5,tmp6);
tmp8=float_div(tmp4,tmp7);
tmp9=float_add(tmp3,tmp8);
z=sqrt(tmp9);
Which would be implemented as an appropriately named function.
But that function would be a lot of GIBBERISH and completely unmaintenable.
The gibberish would be encapsulated but it would be a pain to maintain
anyway!
On 2006-04-30, Ian Collins <ia******@hotmail.com> wrote: Bill Pursell wrote: Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.
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.
In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes Chris Hills schrieb: In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes
Chris Hills schrieb:
In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes
>Chris Hills schrieb:
>
>>For embedded work most of the world uses MISRA-C. It is also what the
>>tool vendors support.
>
>Don't I know it...
>Especially Japanese customers ask for MISRA compliance even in
>generated code -- and, ideally, always all versions at once.
There are only 2 versions. You can not comply with both at once.
I know ;-)
In any event "compliance" is anything you want as there is no official
certification or compliance testing for MISRA-C. Just like most C
compilers claim to be "ANSI C" or "ISO C".
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. However there will be an example suite for MISRS-C2 by the end of the
year. It will not be exhaustive so I expect it to grow over the next
couple of years.
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. Hopefully as MISRA-C3 is developed the example suite will be developed
with it and launched at the same time..
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 /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Ben C wrote: 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.
--
Ian Collins.
Ben C a écrit : 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.
Since there are no constructors neither copy constructors in C the
optimization is muc h simpler than in C++.
True, we need the references, what is a good improvement anyway.
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.
No surprise here either, if you do not use this feature. Contrary to C++
all this is completely optional. The behavior of old programs and of
programs written not using this features is not affected.
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.
Sorry but in a 32 bit machine:
unsigned long long a,b,c;
...
a = b/c;
is very likely to invoke a function call...
Many operations are implemented as function calls behind the scenes,
specially in 16 bit compilers that need to implement 64 bit types.
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.
Truncated addition is present in many CPUs since several years but since
C has not operator overloading nobody can do that in C.
In truncated addition
char a=200,b=200,c;
c = a+b;
c is now 255. The highest value acceptable. No wrap around.
This has been available in ALL PCs since years with the MMX instruction
set. But nobody can use them because since operators can't be
overloaded, this would need
c = truncated_addition(a,b);
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 am certain that the conservative option just puts brakes to the
development of the language
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?
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?
ex**************@gmail.com a écrit : 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?
Nowhere. Since the C standard comitee refuses to improve the language,
there are a lot of libraries but all of them incompatible.
Basically, the opinion here is that data structures are too much of an
intellectual effort for C programmers... :-)
jacob navia wrote: Bill Pursell a écrit : As I said, I'm not suggesting that the basic arithmetic operators be
removed from the language, and this is an excellent example of their
utility. Can you come up with a similar example that doesn't rely on
fundamental types? I've never seen an object in any language that was
prone to this type of calculation, and certainly never seen a structure
in a C program to which this would apply. Any such calculation should
be performed by a function anyway, so rather than forcing the
maintenance programmer to parse:
z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);
that same programmer would have to parse:
z = determinant( A);
or the like.
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.
Bill Pursell a écrit : jacob navia wrote:
Bill Pursell a écrit :
As I said, I'm not suggesting that the basic arithmetic operators be
removed from the language, and this is an excellent example of their
utility. Can you come up with a similar example that doesn't rely on
fundamental types? I've never seen an object in any language that was
prone to this type of calculation, and certainly never seen a structure
in a C program to which this would apply. Any such calculation should
be performed by a function anyway, so rather than forcing the
maintenance programmer to parse:
z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);
that same programmer would have to parse:
z = determinant( A);
or the like.
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.
No, it is a user defined type, using operator overloading precisely.
The compiler acepts it in two ways special ways though:
1) Constants:
qfloat pi = 3.14159265358979323846264338327950288419716939Q
I have not had the time to define this as a user defined function.
It could be done if I would implement something like
#pragma number_suffix(qfloat,'Q',asctoqfloat)
i.e. if I would allow the user to implement an association between a
numeric suffix (in this case 'Q') to a function (that should be
implemented in a dll or in some way accessible to the compiler at
compile time). I am planning to do this this sommer, when I will review
the whole implementation of operator overloading in lcc-win32
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.
Yes, the danger is clear, it can be misused. But *anything* can be misused.
Chris Hills wrote:
.... 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.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
In article <44***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> writes Chris Hills wrote:
... 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.
Yes. I know. It is one of several options we are looking at.
However there are problems with using this system.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Sat, 29 Apr 2006 12:18:12 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:
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.
The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course.
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 discussed, then it won't be, and C will not evolve.
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!
On Sat, 29 Apr 2006 13:05:21 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote: Ian Collins a écrit : jacob navia wrote:
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.
C isn't dead, it's mature, there is a difference.
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.
If you want overloading, use C++.
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.
This small change would make possible to write good string libraries,
good numerical libraries, etc.
Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.
Same here, these features exist elsewhere, if you want them, go there.
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!
I am impressed by the depth of your argumentation.
You must be a brilliant person really
:-)
ex**************@gmail.com wrote: 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.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
Herbert Rosenau wrote: jacob navia <ja***@jacob.remcomp.fr> wrote:
.... snip ... 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.
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.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
CBFalconer a écrit : 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.
This is no longer the case. It costed me years of development to do
that. Writing a C library from scratch is not something you do so
easily, unles your name is Chuck Falconer of course. Normal guys like me
take years.
This is hard to understand, specially for genius types of guys like Chuck.
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).
Mr Falconer insisted that I keep lcc-win32 compatible with his 486
system. I refused without a maintenance contract, and he did not forgive
me that to this day.
So is life :-)
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.
Not even that. I told him that I would not even look into it without a
fair payment. Why should I work for him for free? He was the only one
using a 486 that I have ever heard of.
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.
Wow, I am impressed. I will commit suicide shortly.
His recent citing of Trollsdale as an authority goes beyond any
pale.
Maybe you should cite the context too?
I did not cite him as an authority but as a representative of a view
that is always repeated here:
C++ is the future, C is the past. If you want any improvement to C just
use C++.
jacob navia <ja***@jacob.remcomp.fr> writes: ex**************@gmail.com a écrit : 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?
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_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia <ja***@jacob.remcomp.fr> writes:
[...] 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".
</OT>
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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
ex**************@gmail.com a écrit :
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?
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.
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:
Mr Flash Gordon, a "regular" here said: (11 Oct 2004)
"Not only can a lot of programing be done without using hash tables,
list, queues etc, but as I said a lot of programming *is* done without
using such things. Also the natural solution for a lot of problems does
not use such things.
Our dear Dan Pop, another "regular" said... (21 March 2004)
"It's been 12 years since I've used a binary tree the last time. In the
meantime, the most complex data structure I *needed* to use was an array
of structures. And I suspect that many programmers use linked lists
only in their homework assignments. "
And everyone accepted those things in silence. Nobody complained.
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?
Because everyone should use the STL damm it!
I repeat that such an attitude towards data structures means that indeed
C is the past and C++ the dreaded future.
I am not inventing this Keith, you should know. You participated to
those discussions.
And you know perfectly well that when I say: Basically, the opinion here is that data structures are too much of an
intellectual effort for C programmers... :-)
I am not insulting anyone but precisely arguing AGAINST that frame of mind.
jacob
Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
[...]
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'?
Yes. If we have the length as a size_t we do not need to start scanning
memory at each access to get the length of the string, what is GREATLY
inefficient and has been pointed out as inefficient since decades!!!!!
There are dozens of
standard library functions that use this representation, and it's
central to the semantics of string literals.
lcc-win32 proposed replacing
strcmp --> Strcmp
strcat --> Strcat
where the arguments are the same but in THOSE kind of strings.
Similarly, the compiler when it sees:
String s = "This is a string";
would make an array of characters and prepend the length instead of
adding a terminating zero.
Conceivably you could add a new string representation *in addition to*
the existing one.
Yes.
You would then be permanently stuck with two
distinct and incompatible ways of representing strings. (Breaking
nearly all existing code is not an option.)
Yes, new code would use Strcmp, old would use strcmp.
I have tried porting code that uses heavily strings in the old
representation to the new one and it is relatively easy to do.
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.
No. The problem is that you want to keep:
String s;
....
s[23] = 'b';
and not forcing people to use:
strindex(s,23)
strindexassign(s,23,'c');
or similar nonsense.
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.)
Basically it implements all functions of the C library using the new
Strings. The syntax is almost the same:
Strcmp --> strcmp
Strcat --> Strcat
etc
Using operator overloading operators like
if (! s) {
}
have their usual meanings.
[...]
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.
Maybe. I would not say that it is wrong. But the insistence for using
gcc with the -pedantic etc options that is getting recommended here goes
with the attitude of negating C99 in this bgroup. I remember the
discussion about the FAQ we had, where I was flamed because I insisted
on upgrading the FAQ to C99.
[...]
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".
</OT>
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.
I am not imposing anything to anyone. I have explained with a lot of
arguments why I am doing this or that. Nobody is forced to use lcc-win32
but I think that arguing and convincing people still is possible, and
is still the oenly way to publish your own ideas.
Nobody is behind me, there is no FSF nor Microsoft nor any other
organization trying to promote the ideas exposed here. I have just
confidence that good ideas speak for themselves and that they win at the
end.
jacob
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:
<various answers snipped>
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
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield a écrit : 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:
<various answers snipped>
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.
Until they have to port it to a new environment. Then they will see how
easy is to port the libc. Basically you do not port it.
*and that is my point* ...
Yes, it is a lot of work. But is doable if anyone would care about
improving the language.
jacob
Herbert Rosenau a écrit : 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.
This sentence will go into my collection of sentences "to be framed" and
put in a shrine.
What a nice prose. It perfectly describes the general attitude of the
people that are against GC ...
jacob navia said: Richard Heathfield a écrit :
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.
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
On Sun, 30 Apr 2006 11:56:16 UTC, "ex**************@gmail.com"
<ex**************@gmail.com> wrote: 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?
stdlib
string.h
sometimes but not regulary:
- curses ones when his job requires curses
- database ones when his job requires database
and the ones he needs to get his program to work. That means
- system specific ones holding the system APIs he needs.
- the ones he has used to write his own libraries
when he have a need for.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
On Sun, 30 Apr 2006 03:25:47 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote: ex**************@gmail.com a écrit : 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?
Twitsdale, who has proven already that he does not even know what C is
quacks:
Nowhere. Since the C standard comitee refuses to improve the language,
there are a lot of libraries but all of them incompatible.
Basically, the opinion here is that data structures are too much of an
intellectual effort for C programmers... :-)
Leave this group and go to FORTRAN and use its operator overloading
that you says it owns instead to babble senseless crap.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
Richard Heathfield wrote: 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:
<various answers snipped>
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.
The C++ committee did it, is it too hard for C to do the same?
--
Ian Collins.
Ian Collins said: Richard Heathfield wrote:
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.
The C++ committee did it, is it too hard for C to do the same?
Let's find out. First, the wishlist. See if you can get everyone here to
agree what's in and what's out.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
jacob navia wrote:
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.
No surprise here either, if you do not use this feature. Contrary to C++
all this is completely optional. The behavior of old programs and of
programs written not using this features is not affected.
You appear unable of understanding the simple fact that "all this" is
optional in C++ as well.
--
Ian Collins.
In article <44***********************@news.wanadoo.fr>, jacob navia
<ja***@jacob.remcomp.fr> writes CBFalconer a écrit : Back in the last century I downloaded, and actually used, Navia's
Not even that. I told him that I would not even look into it without a
fair payment. Why should I work for him for free? He was the only one
using a 486 that I have ever heard of.
The 486's I know that are still used tend to use the Caduel compiler.
However I think there is more use of the 386 than the 486.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <4b*************@individual.net>, Ian Collins <ian- ne**@hotmail.com> writes Richard Heathfield wrote: 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:
<various answers snipped>
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.
The C++ committee did it, is it too hard for C to do the same?
Most users of C want a compact and efficient language. Many have
complained that they don't want all the "new" features in C99 hence the
reason why 7 years on there have been very few implementations of 99
I can't understand why people want to add a lot of C++ features to C. If
you really need those features use C++
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
Most users of C want a compact and efficient language. Many have
complained that they don't want all the "new" features in C99 hence the
reason why 7 years on there have been very few implementations of 99
I can't understand why people want to add a lot of C++ features to C. If
you really need those features use C++
Agreed, that's why a draw the distinction between new language features
and a new library.
The former can be found in other languages, the latter will make
reliable, portable code easier to produce. The C++ standard library
certainly has, no more roll your own and vendor specific containers.
--
Ian Collins.
Ian Collins a écrit : Richard Heathfield wrote:
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:
<various answers snipped>
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.
The C++ committee did it, is it too hard for C to do the same?
Apparently yes.
Ian Collins a écrit : jacob navia wrote:
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.
No surprise here either, if you do not use this feature. Contrary to C++
all this is completely optional. The behavior of old programs and of
programs written not using this features is not affected.
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
jacob navia said: Ian Collins a écrit : Richard Heathfield wrote:
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.
The C++ committee did it, is it too hard for C to do the same?
Apparently yes.
I'd be delighted to be proved wrong - but nobody seems terribly interested
in providing concrete proposals (possibly because they know that nobody
will agree about which containers should be included or what their APIs
should look like).
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
jacob navia wrote: Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
ex**************@gmail.com a écrit :
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?
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.
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:
Mr Flash Gordon, a "regular" here said: (11 Oct 2004)
"Not only can a lot of programing be done without using hash tables,
list, queues etc, but as I said a lot of programming *is* done without
using such things. Also the natural solution for a lot of problems does
not use such things.
In reply to you saying:
| Since the first message in this thread (admitted, polemic)
| I wanted to take a critical look at remarks like "I never use any
| data structures", and such, implying that C (or programming) can
| be done without using containers like hash tables, lists,
| queues, etc.
Is there anything wrong with pointing out that there are large problem
domains which
Our dear Dan Pop, another "regular" said... (21 March 2004)
"It's been 12 years since I've used a binary tree the last time. In the
meantime, the most complex data structure I *needed* to use was an array
of structures. And I suspect that many programmers use linked lists
only in their homework assignments. "
They fact that people have spent years on serious projects without the
needs of such things proves that you implication that they are required
for serious programming is false.
And everyone accepted those things in silence. Nobody complained.
Obviously they could see the point that there is a lot of serious
programming that does not require such things.
Oh, I just noticed, you appear not to have complained about my comment
either as far as I can see in Google.
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.
They don't have to be done over and over again. Just pick an
implementation and keep using it.
Why?
Because everyone should use the STL damm it!
Why?
I repeat that such an attitude towards data structures means that indeed
C is the past and C++ the dreaded future.
You (or others) can implement those things in standard reusable C if you
require then. In fact, since October 2004 my job has moved on and I've
done some work using a linked list library written by someone else in
standard C and I'm now using an XML library written in C (the bits I've
looked at are all standard C). I didn't have to write these libraries,
nor did I need them to be part of the C language to use them.
Just because you are unable to write a reusable linked list
implementation in standard C doesn't mean that others can't. To quote you:
| OK. That is what I wanted. I think that the language is making too
| difficult to do that. Each time I need a list, I have to rewrite
| a new set of:
| DATA_LIST *AddToList(DATA *item);
| FindInList(DATA_LIST *list,DATA *item);
| etc
Strangely enough you didn't respond (as far as I can see in Google) to
my suggested alternative interface that would not require rewriting each
time.
I am not inventing this Keith, you should know. You participated to
those discussions.
And you know perfectly well that when I say:
>>Basically, the opinion here is that data structures are too much of an
>>intellectual effort for C programmers... :-)
I am not insulting anyone but precisely arguing AGAINST that frame of mind.
We use complex data structures when we need them often just reusing
existing code. We don't use them when we don't need them.
Personally I would have no problem if some of the things you suggest
were added to standard C, but that is a discussion for comp.std.c as has
already been pointed out. Or for the standards committee if you want to
join it.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro: http://clc-wiki.net/wiki/Intro_to_clc
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
jacob navia wrote: Ian Collins a écrit :
jacob navia wrote:
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.
No surprise here either, if you do not use this feature. Contrary to C++
all this is completely optional. The behavior of old programs and of
programs written not using this features is not affected.
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.
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?
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.
--
Ian Collins.
Richard Heathfield wrote: jacob navia said: Richard Heathfield a écrit :
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.
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.
Now you are being unfair to lcc, which AFAIK is an accurate and
portable C compiler. It's the lcc-win32 version that is far behind
(I think by about 10 versions) and that sports the anti-portability
execrations and lack of reliability.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
jacob navia wrote: CBFalconer a écrit :
.... snip ... 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).
Mr Falconer insisted that I keep lcc-win32 compatible with his 486
system. I refused without a maintenance contract, and he did not
forgive me that to this day.
Don't lie. I never insisted on anything. You were totally unaware
of a problem, due to lack of testing. I simply abandoned the
system, and have never recommended it since.
You will note that M.Navia does not want to hear about bugs.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
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
jacob navia wrote: 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.
That's OK to avoid a temporary, but a typical implementation of operator
+ is
T operator+( const T& a, const T& b )
{
T tmp = a;
a += b;
return tmp;
}
The problems I see are the new requirement for references and the
creation of tmp when a shallow copy of a T is inappropriate (say it
contains pointer members).
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.
Good, that ends that silly argument!
--
Ian Collins.
CBFalconer said: Richard Heathfield wrote: jacob navia said: Richard Heathfield a écrit :
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.
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.
Now you are being unfair to lcc, which AFAIK is an accurate and
portable C compiler.
I have no wish to be unfair to lcc. What I am talking about is the use of
extensions such as Jacob Navia frequently mentions here in clc. Such
extensions render unportable any code that uses them. It is interesting
that Jacob is here arguing that portability is a significant issue, whereas
he has so often argued that it is not.
It's the lcc-win32 version that is far behind
(I think by about 10 versions) and that sports the anti-portability
execrations and lack of reliability.
I shan't comment on reliability aspects, because I don't use lcc-win32
myself. As for extensions, I think they're a Good Thing, in that they add
power to the programmer's elbow. But I also think that discussion of them
should be restricted to newsgroups where they are topical. This newsgroup
isn't one of those.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
"Herbert Rosenau" <os****@pc-rosenau.de> writes: On Sat, 29 Apr 2006 13:05:21 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:
[...] 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.
Not at all. Operator overloading is (or can be) nothing more than
syntactic sugar, allowing an operator symbol to be used as a function
name. There no necessary connection to constructors and destructors.
(The 1983 version of Ada had operator overloading but did not directly
support object orientation.)
I believe that, theoretically, a form of operator overloading could be
added to C without bringing in any of the other baggage of C++.
(I'm not commenting on whether it would be a good idea.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia <ja***@jacob.remcomp.fr> writes: CBFalconer a écrit :
[...] His recent citing of Trollsdale as an authority goes beyond any
pale.
Maybe you should cite the context too?
I did not cite him as an authority but as a representative of a view
that is always repeated here:
C++ is the future, C is the past. If you want any improvement to C
just use C++.
If the only example of that attitude you can think of is a quotation
from Tisdale, you should consider the possibility that this attitude
is not as common here as you claim it is.
There are programmers who need (or think they need) features that are
provided by C++, but not by C. Those programmers are better advised
to use C++ than to wait however many decades it might take to get
those features standardized and implemented in C. Most of the rest of
us here in comp.lang.c are content to use and discuss C as it
currently exists.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia <ja***@jacob.remcomp.fr> writes: Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
[...]
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'?
Yes. If we have the length as a size_t we do not need to start
scanning memory at each access to get the length of the string, what
is GREATLY inefficient and has been pointed out as inefficient since
decades!!!!!
There are dozens of
standard library functions that use this representation, and it's
central to the semantics of string literals.
lcc-win32 proposed replacing
strcmp --> Strcmp
strcat --> Strcat
where the arguments are the same but in THOSE kind of strings.
Similarly, the compiler when it sees:
String s = "This is a string";
would make an array of characters and prepend the length instead of
adding a terminating zero.
Conceivably you could add a new string representation *in addition to*
the existing one.
Yes.
You would then be permanently stuck with two
distinct and incompatible ways of representing strings. (Breaking
nearly all existing code is not an option.)
Yes, new code would use Strcmp, old would use strcmp.
I have tried porting code that uses heavily strings in the old
representation to the new one and it is relatively easy to do.
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.
No. The problem is that you want to keep:
String s;
...
s[23] = 'b';
and not forcing people to use:
strindex(s,23)
strindexassign(s,23,'c');
or similar nonsense.
I don't recall every saying I "want to keep" any such thing.
C does not currently support operator overloading. Your String type
could be implemented in standard C, but it would require using
additional function calls. In a hypothetical C-like language that
*does* support operator overloading, a new String type could be
implemented more conveniently.
I do not necessarily oppose either adding operator overloading to a
future C standard, or implementing it as an extension in an existing C
compiler. I've used languages that support operator overloading, and
I've found it very convenient at times. (It's also prone to abuse.)
On the other hand, operator overloading is really nothing more than
syntactic sugar; there's nothing you can do with it that you can't do
without it (though perhaps much more verbosely).
A string library implemented in standard C would be a good topic for
discussion in this newsgroup. A string library that depends on
extensions provided by a single compiler would be a good topic for a
newsgroup that deals with that copmiler. Advocacy of changes to the C
language belongs in comp.std.c. You've complained that your
suggestions haven't been well received there; that doesn't seem to
have stopped you from talking about them here.
Get this through your head. I do not oppose your ideas. Some of them
are undoubtedly worth considering. I am sick and tired of your
attitude and your insistence on discussing them in a form where they
are off-topic.
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.)
Basically it implements all functions of the C library using the new
Strings. The syntax is almost the same:
Strcmp --> strcmp
Strcat --> Strcat
etc
Using operator overloading operators like
if (! s) {
}
have their usual meanings.
I asked for a pointer to the documentation. Is there any? If not,
it's not worth my time to consider it.
[...]
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.
Maybe. I would not say that it is wrong. But the insistence for using
gcc with the -pedantic etc options that is getting recommended here
goes with the attitude of negating C99 in this bgroup.
Have you tried "gcc -pedantic -std=c99"? I use it routinely.
I remember the
discussion about the FAQ we had, where I was flamed because I insisted
on upgrading the FAQ to C99.
I don't remember that.
[...] I am not imposing anything to anyone. I have explained with a lot of
arguments why I am doing this or that. Nobody is forced to use
lcc-win32 but I think that arguing and convincing people still is
possible, and is still the oenly way to publish your own ideas.
You are imposing extensions that are specific to lcc-win32 on this
newsgroup. You are imposing your advocacy of changes to the standard
on a newsgroup that discusses the language *as it currently exists*,
after being told repeatedly that such discussions would be more
appropriate in comp.std.c.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia <ja***@jacob.remcomp.fr> wrote: It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed. Most of them think, as one of them
said:
"C++ is the future, we are just waiting that C programmers die out."
Tisdale is a known idiot, and you are a known liar.
_This group_ discusses ISO C. It does not discuss any of the gazillions
extensions to it that are out there. In particular it does not discuss
toy compiler suites crufted together by someone who hasn't even read the
Standard properly. It is understandable that this gets up your tits, but
you'll just have to learn to live with being marginal.
Richard
Ian Collins <ia******@hotmail.com> wrote: jacob navia wrote:
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.
No surprise here either, if you do not use this feature. Contrary to C++
all this is completely optional. The behavior of old programs and of
programs written not using this features is not affected.
You appear unable of understanding the simple fact that "all this" is
optional in C++ as well.
s/optional/an abomination/.
Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?
References... yikes! When I want my object to change behind my back
without me even being aware of it, I'll use first-generation FORTRAN and
change the value of 3, thank you very much.
STL... bah. When I want to use a linked list, I want to use _this_
linked list which is tailored to _this_ application, not some Extruded
Datatype Product which may be "good enough" for most applications and
has precisely the wrong properties for mine.
C is simple, clean and efficient. Let's keep it that way.
Richard This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: perseus |
last post by:
I think that everyone who told me that my question is irrelevant,
in particular Mr. David White,
is being absolutely ridiculous. Obviously, most of you up here
behave like the owners of the C++...
|
by: Jeremy Siek |
last post by:
CALL FOR PAPERS/PARTICIPATION
C++, Boost, and the Future of C++ Libraries
Workshop at OOPSLA
October 24-28, 2004
Vancouver, British Columbia, Canada
http://tinyurl.com/4n5pf
Submissions
|
by: Howard Gardner |
last post by:
/*
If I am using boost, then how should I write this program?
As it sits, this program is using SFINAE to determine whether
or not a type supports particular syntax. I suspect that there
is...
|
by: smith4894 |
last post by:
{ not sure you're aware of that but there are the newsgroups for all
major operating systems. you might want to try asking in the forum
'comp.os.linux.development.apps', since memory-mapped files...
|
by: linyanhung |
last post by:
I used a boost multi thread in VS 2005 on a Duo Core PC, and made a two
thread process.
The code is something like this:
#include <boost/thread/thread.hpp>
void fun1()
{
//do something
| | |
by: Matt England |
last post by:
My team currently using Boost Threads, but we are considering
switching to ZThreads. (We seek cross-platform, C++ multithreading
capabilities in an external library.)
ZThread(s):
...
|
by: ironpingwin |
last post by:
Hi!
I'd like to make few threads which will run in the same time in C++.
I try to use boost library v 1.34.1 (it can't be newest, because I
compile on remote machine, which is not...
|
by: brad |
last post by:
Still learning C++. I'm writing some regex using boost. It works great.
Only thing is... this code seems slow to me compared to equivelent Perl
and Python. I'm sure I'm doing something incorrect....
|
by: ameyav |
last post by:
Hi All,
I am converting some C code into C++ code. The objective is to improve throughput.
I have some code written in C which serially parses through a list of files, opens each one of them,...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
