Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #18560 > unrolled thread

things i would ban from clc

Back to article view | Back to comp.lang.c

Contents

  things i would ban from clc jgk@panix.com (Joe keane) - 2012-03-11 23:05 +0000
    Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-12 10:33 -0700
      Re: things i would ban from clc gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-12 23:57 +0000
    Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-12 18:44 +0100
      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 12:26 -0700
        Re: things i would ban from clc "osmium" <r124c4u102@comcast.net> - 2012-03-12 14:36 -0600
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 13:57 -0700
        Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-12 17:34 -0400
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 15:00 -0700
            Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-12 18:21 -0400
              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 15:43 -0700
                Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-12 23:53 +0100
                  Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 17:17 -0700
                    Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 09:09 +0100
                      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 01:24 -0700
                        Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-13 05:59 -0700
                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 10:55 -0700
                            Re: things i would ban from clc blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 11:07 -0700
                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 11:25 -0700
                                Re: things i would ban from clc blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 11:32 -0700
                                  Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-13 12:18 -0700
                                    Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:13 -0700
                                  Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 13:49 -0700
                                    Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 17:14 -0400
                                      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 14:35 -0700
                                        Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 18:09 -0400
                                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:06 -0700
                                            Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 08:18 +0100
                                              Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 10:07 +0100
                                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 12:41 -0700
                                                Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 21:53 +0100
                                                  Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 14:16 -0700
                                                    Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-18 07:14 +0100
                                          Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-14 10:39 +0100
                                    Re: things i would ban from clc Ben Pfaff <blp@cs.stanford.edu> - 2012-03-13 14:33 -0700
                                      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 14:40 -0700
                              Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 16:25 -0700
                                Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 00:51 -0700
                                  Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-14 14:25 -0700
                                    Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 13:40 -0700
                                      Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-18 17:05 -0700
                                        Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-23 11:59 -0700
                                          Re: things i would ban from clc Robert Wessel <robertwessel2@yahoo.com> - 2012-03-23 17:02 -0500
                                            Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-23 16:51 -0700
                                              Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-24 07:16 +0100
                                          Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-27 11:26 -0700
                                        Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-23 19:43 +0000
                                          Re: things i would ban from clc Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 19:45 +0000
                                          Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 23:49 +0100
                                            Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-24 11:54 +1300
                                              Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:26 +0100
                                              Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-26 07:31 -0700
                                            Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-24 05:45 +0000
                                              Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:31 +0100
                            Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 14:34 -0400
                            Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 16:18 -0700
                              Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 08:18 +0100
                                Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-14 14:06 -0700
                        Re: things i would ban from clc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-15 15:22 +0000
                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 12:26 -0700
                            Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-15 21:28 +0100
                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 13:49 -0700
                        Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-15 16:36 +0000
                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 12:16 -0700
                            Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-16 00:13 +0000
                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 20:40 -0700
                  Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-13 01:52 -0700
                    Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-13 11:31 +0100
                    Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 11:41 +0100
                      Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-13 06:06 -0700
                        Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 15:06 +0100
                        Re: things i would ban from clc ImpalerCore <jadill33@gmail.com> - 2012-03-13 07:46 -0700
                        Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 19:08 +0100
                      Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-13 13:20 +0000
                        Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-13 20:41 +0100
                  Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-13 19:34 +0000
                    Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:14 -0700
                      Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-13 23:28 +0000
                        Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 21:18 -0700
        Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-13 20:19 +1300
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 01:09 -0700
            Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-13 21:32 +1300
    Re: things i would ban from clc nick_keighley_nospam@hotmail.com - 2012-03-13 01:52 -0700
      Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-13 11:31 +0100
        Re: things i would ban from clc nick_keighley_nospam@hotmail.com - 2012-03-14 01:18 -0700
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 12:09 -0700
    Re: things i would ban from clc ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-03-14 13:01 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#18810

Le 15/03/12 20:26, Don Y a écrit :
>
> OTOH, there are applications where all of printf's different
> formats are just excess baggage. The size of printf()'s
> executable is *staggering* when you think of how "little"
> it (appears to) does. Yet, it seems to be one of the first
> modules that a developer draws into his project...

I know, I have written printf for my compiler system lcc-win.

It is quite big mind you:

d:\repos\lcc-src\libc>pedump /summary xprintf.obj
xprintf.obj 41871 bytes, linked Tue Mar 13 19:22:37 2012

Section Name       Size
    01   .text      14780
    02   .data      1112


almost 15K, + 12 K for character strings, tables, etc...

But it will print a denormalized number extracting all the
available precision from it.

Supports all the C99 formats, etc. Actually printf is a
run time intepreter of the format string. My printf also
must support all the extensions: 450 significant digits
qfloats, printng the comma separator to separate the number
in thousands, and many other "goodies".

I would like to have to possibility of trimming it, something
like "slimPrintf()" but it would make programming more complex
than it needs to.

And with only 15K, it is not THAT big, compared to other
implementations that do less with more.

jacob

[toc] | [prev] | [next] | [standalone]

#18812

Hi Jacob,

On 3/15/2012 1:28 PM, jacob navia wrote:
> Le 15/03/12 20:26, Don Y a écrit :
>>
>> OTOH, there are applications where all of printf's different
>> formats are just excess baggage. The size of printf()'s
>> executable is *staggering* when you think of how "little"
>> it (appears to) does. Yet, it seems to be one of the first
>> modules that a developer draws into his project...
>
> I know, I have written printf for my compiler system lcc-win.
> It is quite big mind you:
>
> d:\repos\lcc-src\libc>pedump /summary xprintf.obj
> xprintf.obj 41871 bytes, linked Tue Mar 13 19:22:37 2012
>
> Section Name Size
> 01 .text 14780
> 02 .data 1112
>
> almost 15K, + 12 K for character strings, tables, etc...

Exactly.  You can write an *application* in that much
space!  And all *it* does is "print stuff".

> But it will print a denormalized number extracting all the
> available precision from it.
>
> Supports all the C99 formats, etc. Actually printf is a
> run time intepreter of the format string. My printf also
> must support all the extensions: 450 significant digits
> qfloats, printng the comma separator to separate the number
> in thousands, and many other "goodies".
>
> I would like to have to possibility of trimming it, something
> like "slimPrintf()" but it would make programming more complex
> than it needs to.

If you have support for late/lazy binding, you can modularize
it and have only the portions that are actually *used*
dragged into the executable (e.g., in a hosted environment).

A more practical approach, IME, is to discard printf and
adopt hybrid functions that handle the formats of interest
to you.

E.g., I take great pains *not* to use floats/doubles in
most of my applications.  The cost is usually too high
and the results they make available don't warrant the
expense (floating point emulation library, suppporting
floating point context in the OS, etc.).

Instead, I put the binary point where I want it and
carefully analyze the range and domain of each operation
that I perform to ensure I get the precision I need
in my results.  (yeah, more tedious but cuts the
resource requirement$ significantly)

> And with only 15K, it is not THAT big, compared to other
> implementations that do less with more.

[toc] | [prev] | [next] | [standalone]

#18803

Don Y <this@isnotme.com> writes:
<snip>
> When was the last time you used:
>
>    digits = INT_MAX
>    decimals = INT_MAX
>    printf("The answer is %*.*e", value, digits, decimals)

Never!  It needs semi-colons, and it needs the printf arguments to be in
the right order!  Also, making the field width equal to the precision is
a little odd for the 'e' conversion.

> In fact, when was the last time you used the '*' flag in printf??

I use it quite a lot, but that may just be that I like to parametrise my
code a lot.  By the way, it's not a "flag".  printf specifiers do have
flags (there are +, -, #, ' ' and 0) so using the wrong term might be
confusing.

> Will your copy of the libraries even *handle* this specific
> case??

It doesn't need to.  printf need only support conversions that generate
no more than 4095 characters.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#18807

Hi Ben,

On 3/15/2012 9:36 AM, Ben Bacarisse wrote:
> Don Y<this@isnotme.com>  writes:
> <snip>
>> When was the last time you used:
>>
>>     digits = INT_MAX
>>     decimals = INT_MAX
>>     printf("The answer is %*.*e", value, digits, decimals)
>
> Never!  It needs semi-colons, and it needs the printf arguments to be in
> the right order!  Also, making the field width equal to the precision is
> a little odd for the 'e' conversion.
>
>> In fact, when was the last time you used the '*' flag in printf??
>
> I use it quite a lot, but that may just be that I like to parametrise my
> code a lot.  By the way, it's not a "flag".  printf specifiers do have
> flags (there are +, -, #, ' ' and 0) so using the wrong term might be
> confusing.

Wow, I am *so* relieved!  With all your criticisms, I was
afraid you might not have UNDERSTOOD WHAT I INTENDED!  Whew!
Glad I won't have to worry about *that*!

[If you have some EXTRA free time, how about checking my past
posts for spelling and grammatical errors.  It might help
others who are confused by a typo here or there... e.g., my
recent use of 'int' in place of 'age'...  There might be
*other* folks who would also welcome your attention to this
level of detail!]

Of course, aside from the obligatory picking of nits, you
*did* (?) realize that the point I was making to Jacob was that
certain things are moved into LIBRARIES vs. part of the
language "proper" so that they *can* be elided from
particular applications without compromising the language's
functionality.  That you can still successfully deploy an
application with a printf(3) implementation that *won't*
handle the case illustrated above.

You can't elide "int's" from C.  Nor support for arrays.  etc.

>> Will your copy of the libraries even *handle* this specific
>> case??
>
> It doesn't need to.  printf need only support conversions that generate
> no more than 4095 characters.

You may be lucky enough to work in environments where you
can be assured that the tools are strictly conforming AND
when you encounter something that *isn't*, your employer/client
is willing to wait for <someone> to fix it so you can get back
to work.

But, if you look at a wider range of products claiming to
be "C compilers", you will find these sorts of "problems"
are commonplace.  When confronted, the vendor will often
skirt the issue with "Well why would you want to do *that*?"
(instead of addressing a documented PROBLEM, let's infer
that the developer is doing something 'wrong' or that could
be done in a DIFFERENT manner).

I work with a *lot* of compilers for a lot of different
iron.  I've taken up the practice of adding examples of
test cases that I've encountered that weren't well-behaved.
I apply that test suite as one of the first things I do
when using a "new" compiler to see what sort of confidence
I can have in its results.

As I spot things that don't work, I gauge how much I will
either have to *avoid*, *fix* or replace with my own
library components.  Or, how strong a case I will have to
recommend to client that he abandon a particular toolchain
in favor of another ("What *exactly* is wrong with the
product we purchased?  We've got a lot of money invested
in those tools!  Not to mention several deployed products!")

[toc] | [prev] | [next] | [standalone]

#18817

Don Y <this@isnotme.com> writes:

> Hi Ben,
>
> On 3/15/2012 9:36 AM, Ben Bacarisse wrote:
>> Don Y<this@isnotme.com>  writes:
>> <snip>
>>> When was the last time you used:
>>>
>>>     digits = INT_MAX
>>>     decimals = INT_MAX
>>>     printf("The answer is %*.*e", value, digits, decimals)
>>
>> Never!  It needs semi-colons, and it needs the printf arguments to be in
>> the right order!  Also, making the field width equal to the precision is
>> a little odd for the 'e' conversion.
>>
>>> In fact, when was the last time you used the '*' flag in printf??
>>
>> I use it quite a lot, but that may just be that I like to parametrise my
>> code a lot.  By the way, it's not a "flag".  printf specifiers do have
>> flags (there are +, -, #, ' ' and 0) so using the wrong term might be
>> confusing.
>
> Wow, I am *so* relieved!  With all your criticisms, I was
> afraid you might not have UNDERSTOOD WHAT I INTENDED!  Whew!
> Glad I won't have to worry about *that*!
>
> [If you have some EXTRA free time, how about checking my past
> posts for spelling and grammatical errors.  It might help
> others who are confused by a typo here or there... e.g., my
> recent use of 'int' in place of 'age'...  There might be
> *other* folks who would also welcome your attention to this
> level of detail!]

I'm sorry.  I have no desire to annoy you with details that don't
interest you.  Some people are interested in details and some are not
and I made the wrong call.  I will try not to do it again.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#18823

Hi Ben,

On 3/15/2012 5:13 PM, Ben Bacarisse wrote:
> Don Y<this@isnotme.com>  writes:
>
>> Hi Ben,
>>
>> On 3/15/2012 9:36 AM, Ben Bacarisse wrote:
>>> Don Y<this@isnotme.com>   writes:
>>> <snip>
>>>> When was the last time you used:
>>>>
>>>>      digits = INT_MAX
>>>>      decimals = INT_MAX
>>>>      printf("The answer is %*.*e", value, digits, decimals)
>>>
>>> Never!  It needs semi-colons, and it needs the printf arguments to be in
>>> the right order!  Also, making the field width equal to the precision is
>>> a little odd for the 'e' conversion.
>>>
>>>> In fact, when was the last time you used the '*' flag in printf??
>>>
>>> I use it quite a lot, but that may just be that I like to parametrise my
>>> code a lot.  By the way, it's not a "flag".  printf specifiers do have
>>> flags (there are +, -, #, ' ' and 0) so using the wrong term might be
>>> confusing.
>>
>> Wow, I am *so* relieved!  With all your criticisms, I was
>> afraid you might not have UNDERSTOOD WHAT I INTENDED!  Whew!
>> Glad I won't have to worry about *that*!
>>
>> [If you have some EXTRA free time, how about checking my past
>> posts for spelling and grammatical errors.  It might help
>> others who are confused by a typo here or there... e.g., my
>> recent use of 'int' in place of 'age'...  There might be
>> *other* folks who would also welcome your attention to this
>> level of detail!]
>
> I'm sorry.  I have no desire to annoy you with details that don't
> interest you.  Some people are interested in details and some are not
> and I made the wrong call.  I will try not to do it again.

No, I apologize for "jumping down your throat".  I understand
the point(s) you were trying to make.

OTOH, it is very annoying to have little "distractions" that
don't address the *substance* of the argument being made.
Too often, a thread wanders into totally arcane territory
at the expense of the original subject matter.  Lots of
text flows back and forth but very little information
gets added to the actual discussion.

If someone posts a code fragment or makes a statement that
"doesn't look right" (to me), I *assume* they are intelligent
and wonder what *my* problem might be in grasping what they
are trying to convey.  Am I not seeing some issue that *they*
have (and are trying to draw my attention to)?  Has some
previous comment of mine been misinterpreted/unclear?  Is
there a typographical error that could explain the confusion
on my part?  Is natural *language* a problem? etc.

I'm not a teacher "grading papers".  Nor do I have a desire to
be.  And, unless the comments/code/etc. are *clearly* off the
mark, I suspect the other person isn't interested in my
corrections -- if they re-read their post, chances are, they
will find them independently.  Nor do I want folks feeling they
have to quickly update their posts to correct piddly errors
to avoid having others correct them on their behalf.

E.g., in a discussion with "io_x", I have to consider if the
code he (?) presented glossed over a key feature of my
example -- or, if it addressed that feature in a different
manner.  *Not* whether his code would compile without errors.
Or whether it would achieve the intended results.  (a compiler
and debugger can comment more authoritatively on those issues
WITHOUT my involvement).

Instead, my focus is on "do you understand what this
*mechanism* is and what it does *for* you?"  I.e., do you
understand what *I* am saying and do I understand what
*you* are saying...

Again, my apologies.

[toc] | [prev] | [next] | [standalone]

#18656

jacob navia wrote:
>
> My proposal is to standardize this in a similar way to C++
> stl and allow you to use lists and hashtables in your C code without
> reinventing the wheel.
>

Your proposal will fail, and your energy will be wasted.  Among the
many reasons for this not least because using void* as your
fundamental type shifts makes the compiler implenters life easy by
shifting all the effort onto to the programmer.  No one want generics
where type safety is the responsibility of the programmer, and they
have to keep casting their object pointers back and forth.

That why C++ templates win - compile time type safety. You haven't got
that, and you haven't got exceptions, and that means that your
interfaces and error handling is horrible to the point of
unusability.  So what you have will never be widely accepted.

Other reasons include your inability to accept any technical criticism
of your design.  You simply won't be able to persuade anyone of
anything without a change in attitude.

You may now accuse be of making personal attacks thereby proving my
point.

[toc] | [prev] | [next] | [standalone]

#18660

"gwowen" <gwowen@gmail.com> ha scritto nel messaggio
news:62bbf6e8-4508-49d8-b2ec-da449cb8ac2f@p13g2000yqd.googlegroups.com...
> jacob navia wrote:
>>
>> My proposal is to standardize this in a similar way to C++
>> stl and allow you to use lists and hashtables in your C code without
>> reinventing the wheel.

in the few i know, in the little i'm, I agree on that... if the library
is multithread [ie can be used from different threads and chach from
different threads their state] and use uintBits types for portabilty
and it is written by me or someone as me

> Your proposal will fail, and your energy will be wasted.  Among the
> many reasons for this not least because using void* as your
> fundamental type shifts makes the compiler implenters life easy by
> shifting all the effort onto to the programmer.  No one want generics
> where type safety is the responsibility of the programmer, and they
> have to keep casting their object pointers back and forth.
>
> That why C++ templates win - compile time type safety. You haven't got
> that, and you haven't got exceptions, and that means that your
> interfaces and error handling is horrible to the point of
> unusability.  So what you have will never be widely accepted.

i read all these C++ templates functions,
i read a book that use C++ stl functions, implement these in assembly
without "exceptiosn" and modify what it seem to me wrong
on these, and came out with a library i like, multithread etc
they [my traslated functions] are ugly to the see in the page
but when run i understand they are better [even if i never used stl]

> Other reasons include your inability to accept any technical criticism
> of your design.

my traslation of the example of book that use C++ stl for doing .cpp files
for set up a web blog [not remember the name of thecnics term], are better.

Even if i read 20% documentation on how a server web has to work...
it is ok in the limit of test i have done...

> You simply won't be able to persuade anyone of
> anything without a change in attitude.
>
> You may now accuse be of making personal attacks thereby proving my
> point.

i like attacks but not personal... it is not ok when all say the same thing
and when all say good of something...

_
this life is about to speak about, this is the fire prove for the humans
Ciao

[toc] | [prev] | [next] | [standalone]

#18662

Le 13/03/12 09:52, gwowen a écrit :
> jacob navia wrote:
>>
>> My proposal is to standardize this in a similar way to C++
>> stl and allow you to use lists and hashtables in your C code without
>> reinventing the wheel.
>>
>
> Your proposal will fail, and your energy will be wasted.

Says "gwowen", widely known guy.

They have been aproved by the French Normalization committee.

> Among the
> many reasons for this not least because using void* as your
> fundamental type shifts makes the compiler implenters life easy by
> shifting all the effort onto to the programmer.

I use void pointers for the data stored in the containers, yes. This
is the generic pointer in C. If you want C++ go there and do that.

I am programming for the C language because I work in C and I do not
want C++ or templates. Now, if you do not like that it is OK with me,
use the STL!


> No one want generics
> where type safety is the responsibility of the programmer, and they
> have to keep casting their object pointers back and forth.
>

There are no casts to void * needed or from void * to any other kind of
pointer needed in C, to the contrary of C++.

Learn C before you accuse me of forcing casts!

> That why C++ templates win - compile time type safety.

Use templates then pleeeeze.  f you want to program in C++ do that
but let me program in C.

> You haven't got
> that, and you haven't got exceptions,

You haven't even bothered to READ the error handling proposed
in the library. There are exceptions: they are called

"Error handling functions"

and they provide you with all the
needed hooks to change them, to trap  certain kinds of error and not
others, etc.

They are provided in a
(1) Global basis (to trap ALL errors or ALL errors of a certain kind for
    ALL containers
(2) IN a per class way so that you can change error behavior for lists
    only, for instance
(3) In a per container way so that you can change the error behavior in
    a per single list way for instance


and that means that your
> interfaces and error handling is horrible to the point of
> unusability.

You can always say that, but since you do not address ANY of the
specifications proposed it is just an assertion of your personal
dislike of C as a programming language. Granted, you think C++ is
the best thing since sliced bread.

Use C++ then!


> So what you have will never be widely accepted.
>

Maybe, there are many technically sound proposals that were rejected 
because the people proposing them had no political (and economic) clout.

> Other reasons include your inability to accept any technical criticism
> of your design.  You simply won't be able to persuade anyone of
> anything without a change in attitude.

You are not doing any technical criticism, just ranting. You have not 
even cared to address why the error interface concretely is wrong,
what would you change in it, what the technical problems are.

Your only message is

C++ is better.

>
> You may now accuse be of making personal attacks thereby proving my
> point.

No, you are just ranting, I do not feel personally attacked, nor I
consider your critic as justified since there isn't a SINGLE concrete
reason why the error interface is bad. You just haven't even read what
I propose.

[toc] | [prev] | [next] | [standalone]

#18673

jacob navia wrote:
> Le 13/03/12 09:52, gwowen a �crit :
> > jacob navia wrote:
> > Your proposal will fail, and your energy will be wasted.
>
> Says "gwowen", widely known guy.

Wow, straight in with the ad hominem.

> Learn C before you accuse me of forcing casts!

Casts wasn't the right term, but the point still stands.

Suppose I have a list of doubles and want to write a function that
adds them all together and returns the result.   That's a reasonable
function, right?
Can I do that without a cast? Please show the code.

Can I do that with your library in such a way that attempting to pass
a list of strings to that function is a compile time error? Please
show the code.

If the compiler can't distinguish between a container of beans and a
container of buses, the programmer is forced to carry all the type
information around in their head.

(Don't bother responding to the below unless you've provided the code
for the above).

> You haven't even bothered to READ the error handling proposed
> in the library.

Yes I have. I understand completely your error handling system, thank
you very much.

>  There are exceptions: they are called "Error handling functions"

Error handling functions are not exceptions.  If you think they are
equivalent, its no wonder you don't understand other peoples technical
complaints.  Error handling functions transfer code control to a
specified function at error time.  Exceptions propagate down the call
chain *automatically freeing unrelated stack resources unrelated to
the object in which the error occured*.

How can your error functions can do that?  Error functions can't do
resource handling unless I register a new error function at every
point in the call chain in which resources are allocated. That's
unmanageable. RAII and proper exceptions give you it for free. The
best you can do is the equivalent making the programmer use a setjmp()
at every point where resources are allocated.

[toc] | [prev] | [next] | [standalone]

#18675

Le 13/03/12 14:06, gwowen a écrit :
> jacob navia wrote:
>> Le 13/03/12 09:52, gwowen a �crit :
>>> jacob navia wrote:
>>> Your proposal will fail, and your energy will be wasted.
>>
>> Says "gwowen", widely known guy.
>
> Wow, straight in with the ad hominem.
>
>> Learn C before you accuse me of forcing casts!
>
> Casts wasn't the right term, but the point still stands.
>
> Suppose I have a list of doubles and want to write a function that
> adds them all together and returns the result.   That's a reasonable
> function, right?

You can do that with the valarray container.

> Can I do that without a cast? Please show the code.
>

#include "ccl/containers.h"

int fn(void)
{
	ValArrayDouble *tab = iValArrayDouble.Create(25);
	iValARrayDouble.Add(tab,"boooo");   <----- compile time error
}

You can add compile time error checking using the templated source
code provided with the library. Since you have (as you imply) read
the documentation you know how to do this.

> Can I do that with your library in such a way that attempting to pass
> a list of strings to that function is a compile time error? Please
> show the code.
>

The code is in the home page of the library. Use the valarray code
for instance.

> If the compiler can't distinguish between a container of beans and a
> container of buses, the programmer is forced to carry all the type
> information around in their head.
>

You want C++? Well, you know where to go if you need that.

> (Don't bother responding to the below unless you've provided the code
> for the above).
>


I have presented a generic valarray container and instantiated it for
double, ints, size_t. That adds compile time checks if you need it.

>> You haven't even bothered to READ the error handling proposed
>> in the library.
>
> Yes I have. I understand completely your error handling system, thank
> you very much.
>
>>   There are exceptions: they are called "Error handling functions"
>
> Error handling functions are not exceptions.  If you think they are
> equivalent, its no wonder you don't understand other peoples technical
> complaints.  Error handling functions transfer code control to a
> specified function at error time.  Exceptions propagate down the call
> chain *automatically freeing unrelated stack resources unrelated to
> the object in which the error occured*.
>

You can do that with lcc-win SEH. It is not part of the library because 
that's not standard C. I am programming in C as you MAY know. I do not
need C++ nor do I need hand holding for cleaning up.


> How can your error functions can do that?  Error functions can't do
> resource handling unless I register a new error function at every
> point in the call chain in which resources are allocated.

That its not how the C language works "gwowen". Please, go to the C++
group and do not ask C software to do what C++ software does.

There are no exceptions in THAT sense in standard C. I implemented them
in lcc-win. But they aren't part of the library since the library uses 
only C89.

That's
> unmanageable.

No. If your error function returns you TEST THE RESULT of each operation
and act accordingly.


  RAII and proper exceptions give you it for free.

But they cost the incredibly mess of C++ . That is not free, by any
means.


> The
> best you can do is the equivalent making the programmer use a setjmp()
> at every point where resources are allocated.

Or, when you do an operation that can fail you test the result and free
the resources if you need to.

[toc] | [prev] | [next] | [standalone]

#18677

On Mar 13, 9:06 am, gwowen <gwo...@gmail.com> wrote:
> jacob navia wrote:
> > Le 13/03/12 09:52, gwowen a crit :
> > > jacob navia wrote:
> > > Your proposal will fail, and your energy will be wasted.
>
> > Says "gwowen", widely known guy.
>
> Wow, straight in with the ad hominem.
>
> > Learn C before you accuse me of forcing casts!
>
> Casts wasn't the right term, but the point still stands.
>
> Suppose I have a list of doubles and want to write a function that
> adds them all together and returns the result.   That's a reasonable
> function, right?
> Can I do that without a cast? Please show the code.
>
> Can I do that with your library in such a way that attempting to pass
> a list of strings to that function is a compile time error? Please
> show the code.
>
> If the compiler can't distinguish between a container of beans and a
> container of buses, the programmer is forced to carry all the type
> information around in their head.
>
> (Don't bother responding to the below unless you've provided the code
> for the above).

I don't understand the point of this challenge.  Templates are not a
part of standard C, so it's like asking him to fill a circular hole
with a square peg.  If you're asking for language features that aren't
supported by C, use a different language?

I understand that there are fundamental advantages of using a language
like C++ over C, especially with the STL.  It's probably one of C++'s
top 3 biggest selling points.  In C, the best you can do is a tradeoff
between type-safety and code maintenance/duplication.  If you want to
parameterize code using 'void*' and 'int (*cmp_fn)( const void*, const
void* )' to reduce code maintenance/duplication, I don't see how
that's the "wrong" choice to make when designing a container in C.  If
type-safety matters that much to you, then you obviously won't use
Jacob's library for that reason.

> > You haven't even bothered to READ the error handling proposed
> > in the library.
>
> Yes I have. I understand completely your error handling system, thank
> you very much.
>
> >  There are exceptions: they are called "Error handling functions"
>
> Error handling functions are not exceptions.  If you think they are
> equivalent, its no wonder you don't understand other peoples technical
> complaints.  Error handling functions transfer code control to a
> specified function at error time.  Exceptions propagate down the call
> chain *automatically freeing unrelated stack resources unrelated to
> the object in which the error occured*.
>
> How can your error functions can do that?  Error functions can't do
> resource handling unless I register a new error function at every
> point in the call chain in which resources are allocated. That's
> unmanageable. RAII and proper exceptions give you it for free. The
> best you can do is the equivalent making the programmer use a setjmp()
> at every point where resources are allocated.

Again, you are asking for support for implicitly executed destructors,
not part of the standard C.

It seems that you think that writing a container library is a fool's
errand when C++ is so readily available.  That is certainly a strong
argument for choosing the right language.  But if you've chosen C to
do your job, you have to live with the consequences.  If you want to
abstract container code, the programmer will have to live with
carrying the type information around in his head.  You may think the
burden is too much, but we're C programmers!  We write our own linked
lists and string libraries and we like it.

With that said, while I am in favor of creating a generic container
library, in my opinion it should at best be relegated to something of
a de-facto standard like Boost to see if it gains wide acceptance
(whatever that means), then maybe consider it for standardization as
you'd have at least a little political pull.

But if Jacob wants to swim in dangerous waters, who are we to deny
him?

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#18686

Le 13/03/12 14:06, gwowen a écrit :
> jacob navia wrote:
>> Le 13/03/12 09:52, gwowen a �crit :
>>> jacob navia wrote:
>>> Your proposal will fail, and your energy will be wasted.
>>
>> Says "gwowen", widely known guy.
>
> Wow, straight in with the ad hominem.
>

Yes, that was utterly unnecessary.

The problem is that we have gone through this too many times. I loose
my mind. You say I will fail because I write C, and C++ is much better
as everybody knows.

That is not an excuse to start with a stupid sentence like I did.

I apologize for that.

[toc] | [prev] | [next] | [standalone]

#18674

jacob navia <jacob@spamsink.net> writes:
<snip>
>> jacob navia wrote:
>>>
>>> My proposal is to standardize this in a similar way to C++
>>> stl and allow you to use lists and hashtables in your C code without
>>> reinventing the wheel.
>>>
>>
>> Your proposal will fail, and your energy will be wasted.
>
> Says "gwowen", widely known guy.
>
> They have been aproved by the French Normalization committee.

Congratulations.  Can you provide a link or document number or something
so that the progress can be tracked?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#18694

Am 03/13/2012 02:20 PM, schrieb Ben Bacarisse:
> jacob navia <jacob@spamsink.net> writes:
>> They have been aproved by the French Normalization committee.
> 
> Congratulations.  Can you provide a link or document number or something
> so that the progress can be tracked?

yeah, would be nice if there would be a page where one could check for
the progress on that national committee. Last time I search I didn't
find any sensible information (but a phone number I guess) on the web

Jens

[toc] | [prev] | [next] | [standalone]

#18693

On 2012-03-12, jacob navia <jacob@spamsink.net> wrote:
> If you are interested in knowing what the container's library is about 
> look at
>
> http://code.google.com/p/ccl/
>
> There you will find the whole containers library for C, the
> documentation, and the source code.
>
> "containers" means lists (single/double linked), hash-tables,
> flexible arrays, buffers, circular buffers, trees, and several others.
>
> My proposal is to standardize this in a similar way to C++
> stl and allow you to use lists and hashtables in your C code without
> reinventing the wheel.

I made a decent little library for hashing, trees and lists more than fifteen
years ago.

http://www.kylheku.com/~kaz/kazlib.html

Fairly widely used and well-tested. E.g. lookie here:

http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;f=e2fsck/dict.c;hb=HEAD

I wrote a standard-like document (almost a pardody of such things) describing
everything to a ridiculous detail.

Another useful thing are the BSD macros "queue.h" et cetera.

We have quasi-standard things for containers in the C culture which, in
practical terms is as good (if not better) as having them in the language.

Those who reinvent wheels just don't know how to use Google.

[toc] | [prev] | [next] | [standalone]

#18730

Hi Kaz,

On 3/13/2012 12:34 PM, Kaz Kylheku wrote:

> Those who reinvent wheels just don't know how to use Google.

Or, can't find a wheel that is durable enough, big enough,
small enough, wide enough, smooth enough, etc. for their
needs!

But, that doesn't mean they should experiment with SQUARE
ones!

[toc] | [prev] | [next] | [standalone]

#18734

On 2012-03-13, Don Y <this@isnotme.com> wrote:
> Hi Kaz,
>
> On 3/13/2012 12:34 PM, Kaz Kylheku wrote:
>
>> Those who reinvent wheels just don't know how to use Google.
>
> Or, can't find a wheel that is durable enough, big enough,
> small enough, wide enough, smooth enough, etc. for their
> needs!

Most importantly: invented here enough.

[toc] | [prev] | [next] | [standalone]

#18741

Hi Kaz,

On 3/13/2012 4:28 PM, Kaz Kylheku wrote:
> On 2012-03-13, Don Y<this@isnotme.com>  wrote:
>> On 3/13/2012 12:34 PM, Kaz Kylheku wrote:
>>
>>> Those who reinvent wheels just don't know how to use Google.
>>
>> Or, can't find a wheel that is durable enough, big enough,
>> small enough, wide enough, smooth enough, etc. for their
>> needs!
>
> Most importantly: invented here enough.

I don't see that, much.  I see more of a trend away from
"roll your own" towards more of a "plug in systems".
People seem (finally?) to not want to muck with much
of the "mechanism" involved in solving problems.

And, with multicore, GHZ CPUs, people are becoming even
lazier in how much they "push" the platform:  "By the
time we finish the project, the hardware will be twice
as fast/cheap/etc."

[toc] | [prev] | [next] | [standalone]

#18642

On 03/13/12 08:26 AM, Don Y wrote:
>
> If you've ever dealt with a "building inspector", you've
> seen how they might (and *are*, LEGALLY!) be the epitome of
> what is allowed/expected in the construction of a building.
> But, chances are, you'd never hire any of them to *design*
> a building for you!  Or, furnish it.  Sure, it might meet
> all the structural, electrical, plumbing, etc. requirements
> of the current Codes... but that doesn't mean it would be a
> pleasant or *useful* place to live/work!

Nice analogy.

It can probably be stretched a little further to say a building company 
benefits from an inspector and a software company benefits from a 
language lawyer!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web