libclc: bitset interface, new final vote 
Author Message
 libclc: bitset interface, new final vote

Hello, voters and nay-sayers :-)

This is a second attempt to get an approval for clc_bitset. Hopefully
the last attempt? Please vote again, try "yes" this time :-)

I have changed a few things based on your feedback. Here's a summary:

1. extern is gone. It was put there to make splint shut up about the
usage of each function, but it didn't do much good.

2. The #endif in the tag now has a comment.

3. clc_bitset_set() has a new parameter, value.
        void clc_bitset_set(bitset, size_t, int value);
If value is 0, the bit is set to 0, else the bit is set to 1. This
change allows us to remove clc_bitset_clear and clc_bitset_assign.

4. Same thing for clc_bitset_set_all(). clc_bitset_clear_all() is gone.

5. clc_bitset_remap() is gone.

6. The #include statement is gone. You must now include stdlib.h yourself.

7. A function named clc_bitset_clone() has been added. It creates a new
bitset from an existing bitset. It will allocate all necessary memory
and then copy the bitset. It returns a new clc_bitset on success and
NULL on failure. Call clc_bitset_free() to free it. This one is added so
that bd can implement md5.

8. The empty/full functions have been renamed to
        int clc_bitset_is_all_set(clc_bitset b);
        int clc_bitset_is_all_clear(clc_bitset b);
We're getting closer and closer to COBOL here...

Unless I screwed up somewhere, this is a new and working version of the
interface.

Bj?rn

#ifndef CLC_BITSET_H
#define CLC_BITSET_H

/*
  * Copyright (c) 2003, Bj?rn Augestad
  * All rights reserved.
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  *   - Redistributions of source code must retain the above copyright
  *     notice, this list of conditions and the following disclaimer.
  *   - Redistributions in binary form must reproduce the above copyright
  *     notice, this list of conditions and the following disclaimer in
  *     the documentation and/or other materials provided with the
  *     distribution.
  *   - Neither the name of the newsgroup comp.lang.c nor the names of
  *     its contributors may be used to endorse or promote products
  *     derived from this software without specific prior written
  *     permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
  * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
  * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
  * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
  * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
  * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
  * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
  * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
  * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
  * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
  * THE POSSIBILITY OF SUCH DAMAGE.
  */

#ifdef __cplusplus
extern "C" {
#endif

typedef struct clc_bitset_tag* clc_bitset;

clc_bitset clc_bitset_new(size_t bitcount);
clc_bitset clc_bitset_clone(clc_bitset b);
void clc_bitset_free(clc_bitset b);
int  clc_bitset_resize(clc_bitset b, size_t bitcount);

void clc_bitset_set(clc_bitset b, size_t i, int value);
void clc_bitset_set_all(clc_bitset b, int value);
int  clc_bitset_is_set(clc_bitset b, size_t i);
int  clc_bitset_is_all_set(clc_bitset b);
int  clc_bitset_is_all_clear(clc_bitset b);

void clc_bitset_toggle(clc_bitset b, size_t i);
void clc_bitset_toggle_all(clc_bitset b);

size_t clc_bitset_size(clc_bitset b);
void*  clc_bitset_data(clc_bitset b);

clc_bitset clc_bitset_map(void* mem, size_t cb);
void clc_bitset_unmap(clc_bitset b);

#ifdef __cplusplus

Quote:
}

#endif

#endif /* CLC_BITSET_H */



Wed, 17 Aug 2005 16:19:19 GMT  
 libclc: bitset interface, new final vote

Quote:
>   * Copyright (c) 2003, Bj?rn Augestad

I'm not sure the '?' character is supported everywhere by all the compilers.
I know that it's a pity, but I suggest

Quote:
>   * Copyright (c) 2003, Bjorn Augestad

--
-ed- emdel at noos.fr ~]=[o
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
C-library: http://www.dinkumware.com/manuals/reader.aspx

"Say 'No' to the war!" http://www.votenowar.org/



Wed, 17 Aug 2005 17:39:37 GMT  
 libclc: bitset interface, new final vote


Quote:

> >   * Copyright (c) 2003, Bj?rn Augestad

> I'm not sure the '?' character is supported everywhere by all the compilers.

Aww, let him keep his name, at least until a compiler coughs up
{*filter*} on it.

--
Randy Howard
remove the obvious bits from my address to reply.



Wed, 17 Aug 2005 17:44:29 GMT  
 libclc: bitset interface, new final vote


02:39:37a:

Quote:

>>   * Copyright (c) 2003, Bj?rn Augestad

> I'm not sure the '?' character is supported everywhere by all the
> compilers. I know that it's a pity, but I suggest

Eh, wouldn't a trigraph be ANSI-compliant now?

:: Ducks and runs like a Pascal programmer faced with JCL. ::



Wed, 17 Aug 2005 19:08:56 GMT  
 libclc: bitset interface, new final vote

Quote:

> This is a second attempt to get an approval for clc_bitset. Hopefully
> the last attempt? Please vote again, try "yes" this time :-)

> I have changed a few things based on your feedback. Here's a summary:
... snip ...

> #ifndef CLC_BITSET_H
> #define CLC_BITSET_H

... snip ...

> #ifdef __cplusplus
> extern "C" {
> #endif

> typedef struct clc_bitset_tag* clc_bitset;

> clc_bitset clc_bitset_new(size_t bitcount);
> clc_bitset clc_bitset_clone(clc_bitset b);
> void clc_bitset_free(clc_bitset b);
> int  clc_bitset_resize(clc_bitset b, size_t bitcount);

> void clc_bitset_set(clc_bitset b, size_t i, int value);
> void clc_bitset_set_all(clc_bitset b, int value);
> int  clc_bitset_is_set(clc_bitset b, size_t i);
> int  clc_bitset_is_all_set(clc_bitset b);
> int  clc_bitset_is_all_clear(clc_bitset b);

> void clc_bitset_toggle(clc_bitset b, size_t i);
> void clc_bitset_toggle_all(clc_bitset b);

> size_t clc_bitset_size(clc_bitset b);
> void*  clc_bitset_data(clc_bitset b);

> clc_bitset clc_bitset_map(void* mem, size_t cb);
> void clc_bitset_unmap(clc_bitset b);

> #ifdef __cplusplus
> }
> #endif

> #endif /* CLC_BITSET_H */

Better, but not done.  I still see no purpose to data/map/unmap,
except to lock in the implementation and make future revision
impossible.  I don't even understand what they are supposed to do.

The resize operation should return a bitset.  Without this the
system cannot expand a bitset via realloc, which may change the
pointer.

As I said earlier, I think there should be certain other
operations.  However omitting them does not make future revision
incompatible, so no more on that.

You don't need set_all and is_all_set, but they may well be
handy.  You have set and toggle, but not clr.  You should have all
three, and they should return the previous bit state IMO
(especially set and clr).

--

   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!



Wed, 17 Aug 2005 21:08:12 GMT  
 libclc: bitset interface, new final vote

Quote:


>>This is a second attempt to get an approval for clc_bitset. Hopefully
>>the last attempt? Please vote again, try "yes" this time :-)

>>I have changed a few things based on your feedback. Here's a summary:

> ... snip ...

>>#ifndef CLC_BITSET_H
>>#define CLC_BITSET_H

> ... snip ...

>>#ifdef __cplusplus
>>extern "C" {
>>#endif

>>typedef struct clc_bitset_tag* clc_bitset;

>>clc_bitset clc_bitset_new(size_t bitcount);
>>clc_bitset clc_bitset_clone(clc_bitset b);
>>void clc_bitset_free(clc_bitset b);
>>int  clc_bitset_resize(clc_bitset b, size_t bitcount);

>>void clc_bitset_set(clc_bitset b, size_t i, int value);
>>void clc_bitset_set_all(clc_bitset b, int value);
>>int  clc_bitset_is_set(clc_bitset b, size_t i);
>>int  clc_bitset_is_all_set(clc_bitset b);
>>int  clc_bitset_is_all_clear(clc_bitset b);

>>void clc_bitset_toggle(clc_bitset b, size_t i);
>>void clc_bitset_toggle_all(clc_bitset b);

>>size_t clc_bitset_size(clc_bitset b);
>>void*  clc_bitset_data(clc_bitset b);

>>clc_bitset clc_bitset_map(void* mem, size_t cb);
>>void clc_bitset_unmap(clc_bitset b);

>>#ifdef __cplusplus
>>}
>>#endif

>>#endif /* CLC_BITSET_H */

> Better, but not done.  I still see no purpose to data/map/unmap,
> except to lock in the implementation and make future revision
> impossible.  I don't even understand what they are supposed to do.

They are not supposed to do anything special, but they allow the caller
to create bitsets from existing memory. This basically means that you
can manipulate any writable range of memory as a bitset. This may for
some people be a very good thing.

Remember that a memory mapped file can be a "writable range of memory".

Consider this if you wonder why we need clc_bitset_map(). You can write
a bitset to file today, but how do you read it back from a file and
create a bitset?

Quote:

> The resize operation should return a bitset.  Without this the
> system cannot expand a bitset via realloc, which may change the
> pointer.

The bitset uses a separate pointer to store the data. That pointer can
be reallocated. Check the implementation thread for further details.

Quote:

> As I said earlier, I think there should be certain other
> operations.  However omitting them does not make future revision
> incompatible, so no more on that.
Agree.

> You don't need set_all and is_all_set, but they may well be
> handy.  You have set and toggle, but not clr.  You should have all
> three, and they should return the previous bit state IMO
> (especially set and clr).

I humbly disagree :-) Please see elsethread for why.

BTW, did you miss the change to clc_bitset_set()? It now includes a
value parameter (set|clear), which removes the need for clc_bitset_clear().

Bj?rn



Wed, 17 Aug 2005 21:31:19 GMT  
 libclc: bitset interface, new final vote


Quote:
> Remember that a memory mapped file can be a "writable range of memory".

> Consider this if you wonder why we need clc_bitset_map(). You can write
> a bitset to file today, but how do you read it back from a file and
> create a bitset?

More importantly, how do you do this portably?  I.e. write a
file on platform a, and read it back on platform b?  Expecting
all the while for bit 17 to always come back the way you expect.

--
Randy Howard
remove the obvious bits from my address to reply.



Wed, 17 Aug 2005 22:14:02 GMT  
 libclc: bitset interface, new final vote

Quote:



>>Remember that a memory mapped file can be a "writable range of memory".

>>Consider this if you wonder why we need clc_bitset_map(). You can write
>>a bitset to file today, but how do you read it back from a file and
>>create a bitset?

> More importantly, how do you do this portably?  I.e. write a
> file on platform a, and read it back on platform b?  Expecting
> all the while for bit 17 to always come back the way you expect.

I'll just wait for the libclc DOM parser. Then we dump and restore it as
XML :-)

Bj?rn



Wed, 17 Aug 2005 22:40:16 GMT  
 libclc: bitset interface, new final vote

Quote:

> Hello, voters and nay-sayers :-)

> This is a second attempt to get an approval for clc_bitset. Hopefully
> the last attempt? Please vote again, try "yes" this time :-)

[snip]

It's okay for now. We'll want to add things later, like range functions,
etc, but this is a good first version.
--
Freenet distribution (temporary): http://24.25.175.161:8891/z-iSjFHtTuo/
Peter's hungry, time to eat lunch.



Wed, 17 Aug 2005 23:05:02 GMT  
 libclc: bitset interface, new final vote

Quote:



> 02:39:37a:


> >>   * Copyright (c) 2003, Bj?rn Augestad

> > I'm not sure the '?' character is supported everywhere by all the
> > compilers. I know that it's a pity, but I suggest

> Eh, wouldn't a trigraph be ANSI-compliant now?

There's a trigraph for ??
--
"We put [the best] Assembler programmers in a little glass case in the hallway
 near the Exit sign.  The sign on the case says, `In case of optimization
 problem, break glass.'  Meanwhile, the problem solvers are busy doing their
 work in languages most appropriate to the job at hand." --Richard Riehle


Thu, 18 Aug 2005 01:42:35 GMT  
 libclc: bitset interface, new final vote

Quote:



> >>This is a second attempt to get an approval for clc_bitset. Hopefully
> >>the last attempt? Please vote again, try "yes" this time :-)

> >>I have changed a few things based on your feedback. Here's a summary:

> > ... snip ...

> >>#ifndef CLC_BITSET_H
> >>#define CLC_BITSET_H

> > ... snip ...

> >>#ifdef __cplusplus
> >>extern "C" {
> >>#endif

> >>typedef struct clc_bitset_tag* clc_bitset;

> >>clc_bitset clc_bitset_new(size_t bitcount);
> >>clc_bitset clc_bitset_clone(clc_bitset b);
> >>void clc_bitset_free(clc_bitset b);
> >>int  clc_bitset_resize(clc_bitset b, size_t bitcount);

> >>void clc_bitset_set(clc_bitset b, size_t i, int value);
> >>void clc_bitset_set_all(clc_bitset b, int value);
> >>int  clc_bitset_is_set(clc_bitset b, size_t i);
> >>int  clc_bitset_is_all_set(clc_bitset b);
> >>int  clc_bitset_is_all_clear(clc_bitset b);

> >>void clc_bitset_toggle(clc_bitset b, size_t i);
> >>void clc_bitset_toggle_all(clc_bitset b);

> >>size_t clc_bitset_size(clc_bitset b);
> >>void*  clc_bitset_data(clc_bitset b);

> >>clc_bitset clc_bitset_map(void* mem, size_t cb);
> >>void clc_bitset_unmap(clc_bitset b);

> >>#ifdef __cplusplus
> >>}
> >>#endif

> >>#endif /* CLC_BITSET_H */

> > Better, but not done.  I still see no purpose to data/map/unmap,
> > except to lock in the implementation and make future revision
> > impossible.  I don't even understand what they are supposed to do.

> They are not supposed to do anything special, but they allow the caller
> to create bitsets from existing memory. This basically means that you
> can manipulate any writable range of memory as a bitset. This may for
> some people be a very good thing.

You are tying the implementation down.  If they are needed, they
belong in a separate module specifically labelled as non-portable,
or as dependant on the core module.

Quote:
> Remember that a memory mapped file can be a "writable range of memory".

> Consider this if you wonder why we need clc_bitset_map(). You can write
> a bitset to file today, but how do you read it back from a file and
> create a bitset?

That is NOT universally possible, let alone convenient.  As it
stands the user has the tools to create such.

    for (i = 0; i < bitset_size(bitset); i++)
      putchar(bitset_is_set(bitset, i) + '0');

memory mapped files are not part of standard C.  Even files are
not guaranteed, just functions to ***try*** to use them.

Quote:

> > The resize operation should return a bitset.  Without this the
> > system cannot expand a bitset via realloc, which may change the
> > pointer.

> The bitset uses a separate pointer to store the data. That pointer can
> be reallocated. Check the implementation thread for further details.

Once more, you are tying down the implementation.  Less
stringently, but unnecessarily.

- Show quoted text -

Quote:

> > As I said earlier, I think there should be certain other
> > operations.  However omitting them does not make future revision
> > incompatible, so no more on that.
> Agree.

> > You don't need set_all and is_all_set, but they may well be
> > handy.  You have set and toggle, but not clr.  You should have all
> > three, and they should return the previous bit state IMO
> > (especially set and clr).

> I humbly disagree :-) Please see elsethread for why.

> BTW, did you miss the change to clc_bitset_set()? It now includes a
> value parameter (set|clear), which removes the need for clc_bitset_clear().

Yes, I did miss that.  Set and toggle should still return the
previous value.  This allows code such as:

     savedbit = set(bitset, bitnum, bit);
     dosomethingthatneedsitset(bitset);
     set(bitset, bitnum, savedbit); /* put things back */

which is not the cleanest thing in the world, but may save a lot
of time and effort.

--

   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!



Thu, 18 Aug 2005 03:14:38 GMT  
 libclc: bitset interface, new final vote

Quote:




>>>>This is a second attempt to get an approval for clc_bitset. Hopefully
>>>>the last attempt? Please vote again, try "yes" this time :-)

>>>>I have changed a few things based on your feedback. Here's a summary:

>>>... snip ...

>>>>#ifndef CLC_BITSET_H
>>>>#define CLC_BITSET_H

>>>... snip ...

>>>>#ifdef __cplusplus
>>>>extern "C" {
>>>>#endif

>>>>typedef struct clc_bitset_tag* clc_bitset;

>>>>clc_bitset clc_bitset_new(size_t bitcount);
>>>>clc_bitset clc_bitset_clone(clc_bitset b);
>>>>void clc_bitset_free(clc_bitset b);
>>>>int  clc_bitset_resize(clc_bitset b, size_t bitcount);

>>>>void clc_bitset_set(clc_bitset b, size_t i, int value);
>>>>void clc_bitset_set_all(clc_bitset b, int value);
>>>>int  clc_bitset_is_set(clc_bitset b, size_t i);
>>>>int  clc_bitset_is_all_set(clc_bitset b);
>>>>int  clc_bitset_is_all_clear(clc_bitset b);

>>>>void clc_bitset_toggle(clc_bitset b, size_t i);
>>>>void clc_bitset_toggle_all(clc_bitset b);

>>>>size_t clc_bitset_size(clc_bitset b);
>>>>void*  clc_bitset_data(clc_bitset b);

>>>>clc_bitset clc_bitset_map(void* mem, size_t cb);
>>>>void clc_bitset_unmap(clc_bitset b);

>>>>#ifdef __cplusplus
>>>>}
>>>>#endif

>>>>#endif /* CLC_BITSET_H */

>>>Better, but not done.  I still see no purpose to data/map/unmap,
>>>except to lock in the implementation and make future revision
>>>impossible.  I don't even understand what they are supposed to do.

>>They are not supposed to do anything special, but they allow the caller
>>to create bitsets from existing memory. This basically means that you
>>can manipulate any writable range of memory as a bitset. This may for
>>some people be a very good thing.

> You are tying the implementation down.  If they are needed, they
> belong in a separate module specifically labelled as non-portable,
> or as dependant on the core module.

Forgive my lack of understanding here, but I fail to see why
clc_bitset_map() is non-portable. To me the function is 100% portable,
the same way that UINT_MAX and sizeof(int) is portable. Please explain.

I do understand that it may be hard to write the contents of a bitset to
a file on one platform and then read it into a bitset on another
platform. That doesn't make make clc_bitset_map() any less portable than
    int i;
    fwrite(&i, sizeof i, 1, f);
on one platform and the corresponding fread() on another platform.

- Show quoted text -

Quote:

>>Remember that a memory mapped file can be a "writable range of memory".

>>Consider this if you wonder why we need clc_bitset_map(). You can write
>>a bitset to file today, but how do you read it back from a file and
>>create a bitset?

> That is NOT universally possible, let alone convenient.  As it
> stands the user has the tools to create such.

>     for (i = 0; i < bitset_size(bitset); i++)
>       putchar(bitset_is_set(bitset, i) + '0');

> memory mapped files are not part of standard C.  Even files are
> not guaranteed, just functions to ***try*** to use them.

So? You know what I meant :-)

- Show quoted text -

Quote:

>>>The resize operation should return a bitset.  Without this the
>>>system cannot expand a bitset via realloc, which may change the
>>>pointer.

>>The bitset uses a separate pointer to store the data. That pointer can
>>be reallocated. Check the implementation thread for further details.

> Once more, you are tying down the implementation.  Less
> stringently, but unnecessarily.

>>>As I said earlier, I think there should be certain other
>>>operations.  However omitting them does not make future revision
>>>incompatible, so no more on that.

>>Agree.

>>>You don't need set_all and is_all_set, but they may well be
>>>handy.  You have set and toggle, but not clr.  You should have all
>>>three, and they should return the previous bit state IMO
>>>(especially set and clr).

>>I humbly disagree :-) Please see elsethread for why.

>>BTW, did you miss the change to clc_bitset_set()? It now includes a
>>value parameter (set|clear), which removes the need for clc_bitset_clear().

> Yes, I did miss that.  Set and toggle should still return the
> previous value.  This allows code such as:

>      savedbit = set(bitset, bitnum, bit);
>      dosomethingthatneedsitset(bitset);
>      set(bitset, bitnum, savedbit); /* put things back */

> which is not the cleanest thing in the world, but may save a lot
> of time and effort.

Which can be written as
        savedbit = clc_bitset_is_set(bitset, bitnum);
        clc_bitset_set(bitset, bitnum, bit);
        dosomethingthatneedsitset(bitset);
        clc_bitset_set(bitset, bitnum, savedbit);

One extra line, I don't see a lot of time and effort saved ;-)

It is feature creep and a potentionally confusing interface. Why
confusing? Here's a couple of reasons:
- Does toggle return the new or the old value?
- Does set/toggle returning 0 mean that an error occured?
- Why does set return 0 the first time it's called and 1 the second time?

(Not very confusing, I admit that)

The good thing about the proposed interface is
- It is not confusing in any way.
- It is the best performing solution for most users
- If "most users" ignore the returned value, "most users" don't get lint
warnings about ignored values.
- It can be changed to implement your solution later. Your solution
cannot be reversed without invalidating existing code.

Let's triage this, is it a "Must have", "Should have" or "Nice to have"?

Bj?rn



Thu, 18 Aug 2005 04:07:42 GMT  
 libclc: bitset interface, new final vote

Quote:



>>>   * Copyright (c) 2003, Bj?rn Augestad

>> I'm not sure the '?' character is supported everywhere by all the
>> compilers.

> Aww, let him keep his name, at least until a compiler coughs up
> {*filter*} on it.

You mean 'Bj?rn'?  All the world is not latin-1, you know.

--
Hallvard



Thu, 18 Aug 2005 06:28:12 GMT  
 libclc: bitset interface, new final vote

Quote:

>> Consider this if you wonder why we need clc_bitset_map(). You can write
>> a bitset to file today, but how do you read it back from a file and
>> create a bitset?

> That is NOT universally possible, let alone convenient.  As it
> stands the user has the tools to create such.

>     for (i = 0; i < bitset_size(bitset); i++)
>       putchar(bitset_is_set(bitset, i) + '0');

That's slow and takes up much more file space than necessary if one only
needs files used for a single platform.  Which is OK sometimes, but I
like to have the option of dumping and restoring the data structure
quickly.  At least for something as simple as a bitset.

Quote:
>>> The resize operation should return a bitset.

Then it must return NULL if realloc fails.  Should that mean the bitset
was destroyed, or that the old bitset is still intact?  With realloc I
almost always would have preferred the former option since it makes the
code simpler, but that would make it annoying if I ever wanted the
latter option.

BTW, I still think the _free operation should be renamed _delete.

Also, Bj?rn, I think you are moving far too quickly.  I don't see much
point in calling for a vote when several things are still being
discussed and new points are cropping up.  (As opposed to when the
discussion gets repetitive and people are just shooting old arguments at
each other).  Now you ended up modifying the interface (in other
threads) _after_ calling for the vote.  Not good.  Also, people who have
been away for a week or so should have time to go through the discussion
they have missed and raise any points they are concerned about.  It's
not as we are in any hurry.  If you feel the waiting slows you down too
much, you can always start discussion on a new module in the meantime.

--
Hallvard



Thu, 18 Aug 2005 06:53:36 GMT  
 libclc: bitset interface, new final vote

says...

Quote:



> >>>   * Copyright (c) 2003, Bj?rn Augestad

> >> I'm not sure the '?' character is supported everywhere by all the
> >> compilers.

> > Aww, let him keep his name, at least until a compiler coughs up
> > {*filter*} on it.

> You mean 'Bj?rn'?  All the world is not latin-1, you know.

I mean, do you know of any compiler that will fail to work on a
source with his name in the copyright string within a comment
block?  If so, then I agree it needs to be changed.  Otherwise, I
don't see the point.

--
Randy Howard
remove the obvious bits from my address to reply.



Thu, 18 Aug 2005 08:45:20 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. libclc: clc_bitset interface, final vote

2. libclc: bitset interface

3. libclc bitset import/export

4. libclc: string module, VOTE & summary of changes

5. libclc: clc_assert interface

6. call for votes: new newsgroup comp.lang.eiffel

7. libclc: New function for the string module?

8. libclc: clc_bitset, a new version

9. HELP: A new Interface or a New object?

10. New interface = new guid

11. new Interface in existing object or new object

12. New warning (non-dll interface) with vc++7

 

 
Powered by phpBB® Forum Software