[concurrency-interest] ParallelFloatArray

Mark Thornton mthornton at optrak.co.uk
Wed Mar 12 15:20:01 EDT 2008

Phil Goodwin wrote:
> On Tue, Mar 11, 2008 at 5:20 PM, Doug Lea <dl at cs.oswego.edu 
> <mailto:dl at cs.oswego.edu>> wrote:
>     Rune Schjellerup Philosof wrote:
>     > ParallelFloatArray isn't provided because you assume people only
>     use double?
>     Not exactly. It isn't provided because the number of support classes
>     goes up with the square of the number of primitive specializations
>     provided (each multiplied by filter and mapping views). Stopping
>     at one integral type (long) and one floating (double) is not ideal,
>     but the alternative of adding thousands of lines of nearly
>     redundant code to support float (and int and then what about the
>     others) is even less ideal.
>     There are some further discussions of this in the list archives.
>     We wish we knew a good way out of this.
> Would you consider adding code generation to the development/build 
> process? The String Template library that comes with ANTLR seems like 
> the right kind of solution for this problem. Both the code and the 
> tests could be generated. The cleanest way to go seems to be to 
> generate the code into the source tree in a pre-build step and to keep 
> both under revision control. Then you can distribute the generated 
> code just as if it had been written by hand. After the initial set up 
> cost the burden of maintaining the code across all primitive types 
> nearly approaches that of maintaining it for a single type.
> Phil
The NIO *Buffer classes seem to be generated in this way. However in our 
case you still get the explosion of interfaces and methods in the 
JavaDoc even if you don't have to write all the implementations.

Mark Thornton

More information about the Concurrency-interest mailing list