Updates to the ccl

[BartC]

What is "The 'CCL' library" in your mind Bart?

The one in the subject line.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×™×©×™, 8 ביוני 2012 21:55:22 UTC+1, מ×ת Ian Collins:

I don't use lcc, but I am interested in the work he is doing with this
library. So what's wrong with posting updates here? Do you prefer
reading yet more contrived examples of undefined behaviour?

My own view is that C isn't the right language for generic containers
libraries, partly because of the dependency problem, but partly
because it's as easy to manipulate pointers on an ad hoc basis as to use an
interface. I'm not sure whether that says something good or something bad
about C.

But I don't have a problem with Jacob discussing his project here. Particuarly
since he's started the process of trying to get the library standardised. It
seems clearly topical.

 

[gwowen]

My own view is that C isn't the right language for generic containers
 libraries, partly because of the dependency problem, but partly
 because it's as easy to manipulate pointers on an ad hoc basis as to use an
 interface. I'm not sure whether that says something good or something bad
 about C.

My problem was (initially) type-safety, but since Jacob's expanded his
templated approach, the improvement on that front has been massive. I
still have my doubts about the error handling mechanism.

But I don't have a problem with Jacob discussing his project here. Particuarly
 since he's started the process of trying to get the library standardised. It
 seems clearly topical.

Quite so.

 

[Guest]

You missed the message entirely apparently. As in, "major faux paus"?

missed me too. What was your point?

 

[Guest]

בת×ריך ×™×•× ×©×™×©×™, 8 ביוני 2012 21:55:22 UTC+1, מ×ת Ian Collins:

My own view is that C isn't the right language for generic containers
libraries, partly because of the dependency problem, but partly
because it's as easy to manipulate pointers on an ad hoc basis as to usean
interface.

strongly diagree! For 1. it isn't *that* easy (or clear), for 2. you reallyshouldn't be mixing conatiner code with application code. programming is supposed to be about abstraction- so use some! I seem to have spent an inordinate amount of time debugging (other people's) linked list, queues and stacks.

I'm not sure whether that says something good or something bad
about C.

pointer manipulation is highly error prone and hard to debug. Write it onceand verify it thoughly.

This a separate issue as to whether Jacob's library is the right solution.

But I don't have a problem with Jacob discussing his project here. Particuarly
since he's started the process of trying to get the library standardised.. It
seems clearly topical.
agreed

isn't this a similar thing?

 

[Guest]

I think that is the way most people think and act ("in my EXPERIENCE"): . I
do not understand such behavior. There are other behaviors I don't
understand.

Did you just say that the world revolves around you?

idiot.

 

[jacob navia]

Le 18/06/12 11:13, (e-mail address removed) a écrit :

idiot.

Exactly. This "joe" takes some word out of its context and adds
a sentence that has nothing to do whatsoever with the discussion

YAT! (Yet Another Troll)

 

[jacob navia]

Le 07/06/12 17:04, jacob navia a écrit :

Hi
I have uploaded a new "templated" version of the double linked list
container, and updated the documentation.

And now I have updated the vector container in a "templated" form.

Elements now can be passed by value, and you can build a thin
indirection layer to benefit from compile time diagnostics and easier
syntax


jacob

 

[Joe.]

You missed the message entirely apparently. As in, "major faux paus"?

missed me too. What was your point?

you don't count cuz you are too old to abuse me, but you know you would if
you could and I don't like you, or you want what? me to be a leader? pfft.
fucking liar.

 

[Joe.]

The one in the subject line.

I don't trust you.

 

[jacob navia]

Le 07/06/12 17:04, jacob navia a écrit :

Hi

I have updated a lot the documentation, introducing color figures,
more tables and explanations.

If possible take a look, and send me feedback about the layout, the
contents whatever

 

[Malcolm McLean]

בת×ריך ×™×•× ×©× ×™,18 ביוני 2012 10:10:09 UTC+1, מ×ת (e-mail address removed):

strongly diagree! For 1. it isn't *that* easy (or clear), for 2. you really shouldn't be mixing conatiner code with application code. programming issupposed to be about abstraction- so use some! I seem to have spent an inordinate amount of time debugging (other people's) linked list, queues and stacks.

Go onto my website. Go to binary image processing, binary utilities.
You'll find a floodfill routine. It contains an ad hoc and not particularly
efficient implementation of a queue. Now rewrite it using Jacob's container
library.
Do you think you've got something better or worse?

 

[Marco]

Hi
I have uploaded a new "templated" version of the double linked list
container, and updated the documentation.

If a library can compile on more than one C compiler (as you stated) then please continue announcing updates here.

Also it helps to develop a thick skin.

 

[jacob navia]

Le 07/07/12 14:14, Malcolm McLean a écrit :

Go onto my website. Go to binary image processing, binary utilities.
You'll find a floodfill routine. It contains an ad hoc and not particularly
efficient implementation of a queue. Now rewrite it using Jacob's container
library.
Do you think you've got something better or worse?

1) Since the ccl would be in the language you wouldn't need to
1.A: Write the code for a queue
1.B: Debug it

2) Since after a few years of usage implementations would improve
you would use better code than what you can write in a few hours.

3) If your software interfaces with other software, the ccl gives you
an easy way of returning queues to the other sofwtare without
writing yet adapter software.

 

[jacob navia]

Le 07/07/12 17:01, Marco a écrit :

If a library can compile on more than one C compiler (as you stated) then please continue announcing updates here.

Also it helps to develop a thick skin.

Thanks

The library compiles with any compiler. I have tested gcc (different
versions and systems), MSVC (different versions and systems) and lcc.

It compiles in 32 and 64 bits. Haven't tested in 16 bits but should be
OK.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,7 ביולי 2012 16:31:15 UTC+1, מ×ת jacob navia:

Le 07/07/12 14:14, Malcolm McLean a écrit :


1) Since the ccl would be in the language you wouldn't need to
1.A: Write the code for a queue
1.B: Debug it

2) Since after a few years of usage implementations would improve
you would use better code than what you can write in a few hours.

3) If your software interfaces with other software, the ccl gives you
an easy way of returning queues to the other sofwtare without
writing yet adapter software.

These are all advantages. To get 3 and arguably 2 queues need to be in the language. 1 is often cited as an advantage, because it seems so obvious. Itisn't really. Anyone with a few hours' exposure to C should be able to write strcpy(). Thne function's still useful, because it's a standard way of performing a commonly needed operation. The same's almost true of queues.

The main reason floodfill() doesn't use the ccl library is that it isn't standard. There's also a reason it doesn't use a slightly more complicated queue that could be more efficient. I want something that anyone can cut and paste, maybe run through to operate on integer buffers or 24 bit rgb buffers,and incorporate into their own projects with a minimum of fuss.