their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120929/62f5f21a/attachment.html>
On Sep 29, 2012, at 10:42 PM, Matthew Knepley wrote:
> http://en.wikipedia.org/wiki/Composability
>
> http://en.wikipedia.org/wiki/Levels_of_Conceptual_Interoperability
>
> I think we can take it to Level 7!
It's nice that they use C indexing so level 7 is really level 6 :-)
>
> Matt
On Sep 29, 2012, at 9:08 PM, Jed Brown wrote:
> On Sat, Sep 29, 2012 at 12:20 PM, Dmitry Karpeev
> wrote:
> > ^^^ Note that this const is superfluous.
> Why is it superfluous? Isn't the second argument type const char* const this
> way?
>
> It's superfluous for the same reason we don't "set
person who wrote it doesn't understand types.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120929/895fd43f/attachment.html>
gt; b) typedef const char* VecType; imposes usability restrictions and
> would hence break a lot of user-code.
> > > c) Keep it as-is. This compiles cleanly, yet the GetType() issue is
> not intuitive. Also, the Sword of Damocles (here: the preprocessor define)
> is a constant threat to other code...
> > > d) Consider the following modification: Instead of a single
> preprocessor-define, use
> > > typedef char* VecType;
> > > typedef const char* VecType_;
> > > and use the function headers
> > > int SetType(const VecType_ v);
> > > int GetType(VecType * v)
> > > This allows for a more intuitive const-correctness, i.e.
> > > VecType type; GetType(&type);
> > > and gets rid of the C preprocessor issue. Also, the reason for the
> trailing underscore can be explained rather nicely in the documentation and
> should not cause confusion: Even if a user writes
> > > VecType_ new_type = "shared"; SetType(new_type);
> > > the code remains valid.
> > >
> > > So, even if option d) is still not the cleanest solution we could
> dream of, I think it is preferable over the current state.
> > >
> > > Best regards,
> > > Karli
> > >
> > >
> >
> >
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120929/37aff8d6/attachment.html>
On Sep 29, 2012, at 11:03 AM, Jed Brown wrote:
> On Fri, Sep 28, 2012 at 9:24 PM, Barry Smith wrote:
>
> I don't like having two typedefs
>
> I tried
>
> typedef const char* VecType;
> PETSC_EXTERN PetscErrorCode VecSetType(Vec, const VecType);
>
> ^^^ Note that this const is superfluou
de...
> > d) Consider the following modification: Instead of a single
> preprocessor-define, use
> > typedef char* VecType;
> > typedef const char* VecType_;
> > and use the function headers
> > int SetType(const VecType_ v);
> > int GetType(VecType * v)
> > This allows for a more intuitive const-correctness, i.e.
> > VecType type; GetType(&type);
> > and gets rid of the C preprocessor issue. Also, the reason for the
> trailing underscore can be explained rather nicely in the documentation and
> should not cause confusion: Even if a user writes
> > VecType_ new_type = "shared"; SetType(new_type);
> > the code remains valid.
> >
> > So, even if option d) is still not the cleanest solution we could dream
> of, I think it is preferable over the current state.
> >
> > Best regards,
> > Karli
> >
> >
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120929/b1da9783/attachment-0001.html>
