gmane.comp.lib.boost.user

Zeljko Vrba | 19 Aug 08:59

Re: The problem isn't C's integer philosophy; it's your design. (was: size_type doubts / integer library..)

On Mon, Aug 18, 2008 at 07:05:10PM -0400, Daryle Walker wrote:
>
> implementing.  This is one of those times.
> 
Thanks for your deep analysis and your time.  Unfortunately, it's based on the
assumption that the task ID is opaque, which it is not..  Re-reading my
original post, this could be blamed on me..

> 
> >Integer types in C and C++ are a mess.  For example, I have made a  
> >library
> >where a task is identified by a unique unsigned integer.  The extra  
> >information
> >about the tasks is stored in a std::vector.  When a new task is  
>
[snip, rearrange]
> 
> You tasks IDs are conceptually opaque, why is any external code  
> wanting to mess with them?  The external code shouldn't be doing  
>

There are TWO task IDs: one is used by the library (which I also made), and
that one _is_ opaque (at least to library clients), it _is_ typedef, and it is
not even an integer (it's a pointer).  Now, to every created task, I need to
assign a positive[*] index (in an application which just uses the library)
which is _not_ opaque: the indices are vertex IDs which are in turn used to
construct a CSR representation (edge-lists) of a certain graph which is in turn
operated on by an external library.   (You may remember my earlier post where I
proposed that the CSR class from Boost.Graph provides a documented, public way
of accessing the raw CSR vectors.)  I will call these "other" IDs "task

(Continue reading)

headers

Daryle Walker | 20 Aug 00:59

Re: The problem isn't C's integer philosophy; it's your design. (was: size_type doubts / integer library..)

On Aug 19, 2008, at 2:59 AM, Zeljko Vrba wrote:

> On Mon, Aug 18, 2008 at 07:05:10PM -0400, Daryle Walker wrote:
>>
[SNIP]
>> You tasks IDs are conceptually opaque, why is any external code
>> wanting to mess with them?  The external code shouldn't be doing
>>
>
> There are TWO task IDs: one is used by the library (which I also  
> made), and
> that one _is_ opaque (at least to library clients), it _is_  
> typedef, and it is
> not even an integer (it's a pointer).  Now, to every created task,  
> I need to
> assign a positive[*] index (in an application which just uses the  
> library)
> which is _not_ opaque: the indices are vertex IDs which are in turn  
> used to
> construct a CSR representation (edge-lists) of a certain graph  
> which is in turn
> operated on by an external library.   (You may remember my earlier  
> post where I
> proposed that the CSR class from Boost.Graph provides a documented,  
> public way
> of accessing the raw CSR vectors.)  I will call these "other" IDs  
> "task
> indices" to avoid further confusion.
>
> I could bundle the task index in the task structure and provide a

(Continue reading)

headers

Emil Dotchevski | 20 Aug 01:24

Re: The problem isn't C's integer philosophy; it's your design. (was: size_type doubts / integer library..)

On Tue, Aug 19, 2008 at 3:59 PM, Daryle Walker <darylew <at> hotmail.com> wrote:
> On Aug 19, 2008, at 2:59 AM, Zeljko Vrba wrote:
>
>> On Mon, Aug 18, 2008 at 07:05:10PM -0400, Daryle Walker wrote:
>[snip]

I think you guys are making this discussion way too complicated. This
is not about designing graph interface, it's about using an integer
identifier of type that's different from std::vector::size_type, and
avoiding the warnings it leads to.

I'd use something like:

typedef int id_type;

template <class T>
class registry: private std::vector<T>
{
public:

  id_type add( T const & x )
  {
    size_type i=size();
    assert( i<=size_type(std::numeric_limits<id_type>::max()) );
    push_back(x);
    return id_type(i);
  }

  //etc. etc. other operations in addition to "add",
  //instead of using "naked" std::vector.

(Continue reading)