Re: [boost] Interest in a static-sized version of cvalarray

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-06-07 13:58:04

Hi Michael!

Sorry for the slight delay, I've been reading up on things so that I
don't make yet another series of uninformed statements without at
least trying to do better :-)

On 6/5/07, Michael Tegtmeyer <tegtmeye_at_[hidden]> wrote:
> > I would really like to see this library in boost, would you like any
> > help getting it ready for submission?  I have recently learned how to
> > use bjam, do boost-style docs etc, and have time to lend a hand.  If
> > we wanted to work together on preparing this, it would be good to put
> > the code in the boost sandbox so we can both access it via subversion.
>
> Thanks, I am interested in whatever help you could offer. I have little
> experience in bjam nor the boost document style.

Cool - let's coordinate this off the list.

> > code readability and maintainability - there is a lot of code
> > repetition in the .h file, also it could use to be chunked up into
> > smaller files (it is really hard to look at a ~5000 line header file).
> > Did you use a code generation script to make that file?  It could
> > benefit from using macros for all the similar functions, which can be
> > readily made from the code generation script if you used one.
>
> I didn't use a code generator but most is copy-paste, At one point I had
> macros to generate each individual case but debugging (use code, not
> library code) became a pain. ie it was easier to track down a compiler
> error when it said  "no operator in expression<lots and lots of stuff> on
> line 42 which said __positive::T operator[](std::size_t n) const {return
> +(value[n]);} rather than MAKE_EXPRESSION_TIMES(...) which was a top-level
> macro and the real problem was missing operator + nested 8 layers. (real
> problem we had). So since the library has been stable for a few years, we
> got rid of the macros to aid debugging it's use.

Yeah, I suppose macros are a matter of taste.  I've had similar
problems with similar uses of macros as what you mention.  An
alternative is something like
#define THIS add
#define THAT +
#include <template_file_that_uses_this_and_that>

, which preserves line numbers of readable code and is a little more
debugging friendly.  In your case, I think it even might be possible
to use the preprocessor library to define sequence of function names
and operators, and iterate over the same file that just pops a pair of
function name and operator from the sequence into their
implementation.  But I've never tried anything like that so I'm not
sure.

> I think that I have a better understanding of what you are looking for but
> let me get the following out of the way:
>
> I'm not sure that a general purpose container is the best use for this
> class. cvalarray is meant to mimic the semantics and purpose of
> std::valarray. Which is specifically designed for numeric values. I think
> that if the purpose is general, then so should the interface, ie not mimic
> std::valarray. One could claim that the incorrect use of boost::array and
> by implication a general-purpose cvalarray is not our problem but IMHO,
> libraries should be easy to use correctly and hard to use incorrectly.

After looking into what you're doing, and what could be done in the
general case, I agree with you 100%.  I didn't realize that you were
limited by adopting the requirements for valarray.  Out of curiosity,
why "incorrect use of boost::array"?

> Additionally, the next step for cvalarray here is for it to automatically
> use SIMD instructions to further speed up the numeric operations. Again
> making its use general purpose will unnecessarily complicate things.

Actually, I stuck the std::string bit into the code I sent you just to
see if it would work  :-).  I'm not really vested into elementwise
concatenation of strings personally.

> On a side and somewhat historical note, if cvalarray morphs into anything
> else, one of the issues here for the adoption is the adding dependancies.
> Currently,  the libraries is one file, self-contained, and does not rely
> on anything outside of the language. That is very important in many
> peoples view. As it is now, one can drop the file into their own project
> and it is available everywhere there is a standard compliant compiler.
> Boost, unfortunately is still not everywhere so unless adding dependancies
> adds significant functionality, I'd like to avoid them. I also thought
> about submitting cvalarray to the c++ standard at one time. For it to ever
> be adopted there, it cannot have dependancies outside of the language.

I understand your point, and being that the only thing (I could find)
that could be reused from Boost is is_pod, the whole issue is indeed
minor.  I suppose I was prompted to raise it because the thing I
personally love about Boost is the level of code reuse, which allows
me to learn something once to know what it is.  That way, when I look
at source code I can understand what is happening more quickly (I
didn't realize that your __is_fundamental is essentially is_pod until
I saw how it was used).

>
> All of that said, I believe that your general-purpose need/desires are
> legitimate. Therefore, I think that it is worth working for a
> general-purpose solution. I have may ideas towards this end but one of the
> biggest ones is the use of expressions. Currently, both std::valarray and
> cvalarray use expressions solely as an implementation detail allowed to
> under the standard:

<snip requirements and example>

> Notice that the above creates an unnecessary temporary that could easily
> be solved with an expression type. But since the expression type is not
> formally exposed, there is no way to write portable code to take advantage
> of it. I think in a new, general-purpose container with a general-purpose
> interface, we could have an exposed expression type that uses a boost
> concept that ensures that as long as (for example) the contained type has
> a valid [] operator, any additional functionality can take advantage of
> it. ie
<snip example>
> Thoughts?

If going general like that, perhaps bulding on top of Fusion2
containers and adding support for elementwise operations over the
containers into Phoenix2 would be the way to go (maybe it's already
there, I didn't find it upon a cursory look)  That way it would
support things like vector<float, float, float>  or a vector <float,
double, double> or even vector<float, string, double>.

In hopes I didn't say many more silly things yet again, :-)

Stjepan