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

Groups > comp.lang.c > #22526

Re: Design decisions

Show all headers | View raw

Le 22/06/12 10:00, gwowen a écrit :
>> I had this strategy but it is unworkable since you can't know in
>> >advance if a zero will appear in the data!
> But it might be desirable for a user to be able to specify such
> behaviour in his error handler.  For example, in signal processing its
> often useful to assume that the data-array is zero-padded-to-infinity,
> so I may use a C++ object like this:
>
> class zero_padded_array
> {
> private:
>   public std::vector<double> v_;
>
> public:
>   const double& at(size_t idx) const {
>     if(idx >= v_.size()){
>        return 0.0;
>     } else {
>        return v_[idx];
>     }
>   }
>   // Rest of interface.
> }
>
> Can I use an error handler to handle out-of-bounds access in you
> library to get that behaviour?
>

Yes.

Method 1: Modify a vector's VTable (long)

You write a new "GetElement" function:


typedef void *(*fnPtr)(Vector *,size_t);

fnPtr oldGetElementFunction;

static double error_return = 0.0;

static double *MyGetElement(doubleVector *v,size_t idx)
{
     if (idx >= iVector.Size(v))
         return &error_return;
     // Call the original function;
     return oldGetElementFunction(v,idx);
}

Now, when you want to create an infinite vector you write:

Vector *CreateExtensibleVector(size_t realSize)
{
     VectorInterface *intf;
     Vector *result = idoubleVector.Create(20); // 20 real elements
     // Save the original function to be used later
     oldGetElementFunction = result->VTable->GetElement;
     intf = malloc(sizeof(VectorInterface));
     memcpy(intf,result->VTable,sizeof(VectorInterface));
     result->VTable = intf;
     // Replace the GetElement in THIS vector
     result->VTable->GetElement = MyGetElement;
     result->Vtable->Finalize = MyFinalize;
     return result;
}

Instead of writing iVector.GetElement you use the macro:

#define iVector_GetElement(vector,idx)  \
          vector->VTable->GetElement(vector,idx);

That will work with normal vectors AND with extensible ones.
Note that the trivial new Finalize procedure is skipped. It just frees
the copied VTable allocated with malloc.

True, this approach is not as easy as the C++ one, but it has the
advantage of being much more flexible. You can subclass before
or after calling the original procedure, or you can bypass the
called procedure entirely.

Method 2: Shorter
Make ALL vectors extensible:
Vector *CreateExtensibleVector(size_t realSize)
{
     Vector *result = idoubleVector.Create(20); // 20 real elements
     // Save the original function to be used later
     oldGetElementFunction = result->VTable->GetElement;
     // Replace the GetElement in ALL vectors
     iVector.GetElement = MyGetElement;
     return result;
}
-----------------------------------------------------------------------------

Note that I haven't answered your original question:

 > Can I use an error handler to handle out-of-bounds access in you
 > library to get that behaviour?

I think you have a point here. I will modify the behavior of the
GetElement function so that it RETURNS the value returned by the
error handling procedure (if that procedure returns of course).

The return value of the error handling function should be a pointer
to a replacement data, or NULL or whatever.

Thanks for your input. Really appreciated.

jacob

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Design decisions jacob navia <jacob@spamsink.net> - 2012-06-21 22:19 +0200
  Re: Design decisions Andrew Cooper <amc96@cam.ac.uk> - 2012-06-21 21:43 +0100
  Re: Design decisions "BartC" <bc@freeuk.com> - 2012-06-21 22:02 +0100
    Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-21 23:23 +0100
      Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 09:12 +0200
        Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-22 19:44 +1200
          Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:32 -0600
        Re: Design decisions gwowen <gwowen@gmail.com> - 2012-06-22 01:00 -0700
          Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 10:08 +0200
            Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-22 17:18 +0100
              Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 18:27 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 08:44 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 23:58 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 10:21 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 02:13 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 12:59 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 11:03 +0200
                Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 21:52 +1200
                Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 12:32 +0200
                Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-23 13:54 +0100
            Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:36 -0600
          Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 10:42 +0200
            Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-22 17:18 +0100
            Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-24 18:32 +0200
    Re: Design decisions James Kuyper <jameskuyper@verizon.net> - 2012-06-21 18:43 -0400
      Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:40 -0600
    Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:28 -0600
  Re: Design decisions "io_x" <a@b.c.invalid> - 2012-06-22 08:35 +0200
  Re: Design decisions Neil Cerutti <neilc@norwich.edu> - 2012-06-22 12:40 +0000
    Re: Design decisions gwowen <gwowen@gmail.com> - 2012-06-22 06:01 -0700
      Re: Design decisions Neil Cerutti <neilc@norwich.edu> - 2012-06-22 14:26 +0000
    Re: Design decisions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-22 14:01 +0100
    Re: Design decisions David Resnick <lndresnick@gmail.com> - 2012-06-22 06:13 -0700
  Re: Design decisions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-22 19:05 +0200
  Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:27 -0600

csiph-web