freenode/#clasp - IRC Chatlog
Search
13:02:24
drmeister
template_SimpleVector<...> is a template class (obviously) that has the base class AbstractSimpleVector_O
13:04:29
drmeister
SimpleVector_byte16_t_O has no __write__ and it would mean lots of code duplication to put __write__ there.
13:08:18
drmeister
grrr, there is invalid utf8 in my paste - how do I get rid of it so I can paste it?
13:10:32
drmeister
Ok, I think the __write__ in template_SimpleVector . is the one you want - EXCEPT tempate_SimpleVector is also the base class for some non-integer and non-byte data types
13:11:22
drmeister
kpoeck: How will your correct __write__ work? Is it for arrays of integer values?
13:12:12
drmeister
The array classes used to inherit from each other in a type oriented way - integer arrays inherit from a common integer array base class.
13:13:32
drmeister
But stassats taught me the importance of making the arrays efficient by having common offsets of length, fill_pointer and the data pointer. That kind of screwed the type oriented inheritance hierarchy and gave us what we have now.
13:13:53
kpoeck
I believe the code in SimpleVector_byte8_t_O::__write__ would work for all these classes, just would need adapt the class name in writestr_stream("#<SIMPLE-VECTOR-BYTE8-T ", stream);
13:17:30
drmeister
Currently you would have to specialize every __write__ for every specialized template class - this is kind of forced on us by the hierarchy structure.
13:18:12
kpoeck
Well i wrote a __write__ for every specialized template, it is just a hell of code duplication
13:19:56
drmeister
Only the specialized template_SimpleVector<...> and the final subclass have access to the array contents - so those are the two choices.
13:23:47
drmeister
Note: This isn't a case of bad design - it's just that C++ forces these kind of choices on us.
13:25:26
drmeister
You could write a templated: template <typename T> void write_fits_in_fixnum(T_sp strm) that does the printing and invoke that from all of your __write__ that fit in a fixnum. Then you will still have 9 methods - but they will all have one function call to this template function.
13:26:02
drmeister
Remember the thing I said about Common Lisp macros being like poetry and C++ templates being like tax forms?
13:31:33
drmeister
int8/byte8, int16/byte16, int32/byte32 will be straightforward (6 cases) - but int64/byte64 may be bignums and will need to be handled specially.
13:32:19
drmeister
You could use to_object<T> converters - they already do the work of converting C++ types T to Common Lisp types.
13:33:24
drmeister
Also (and this is a big one) - lets say we decide to implement a 32 bit version of clasp? We have a whole mess of problems like the following.
13:34:09
drmeister
In that case int32/byte32 need to be handled like int64/byte64 now because Fixnums would be less than 32 bits.
13:35:32
drmeister
Since I didn't handle this conversion problem properly I don't expect you to handle them.
13:36:09
drmeister
So feel free to add another "future 32bit conversion of Clasp" problem to the pile that I already started. :-)
13:39:01
drmeister
I don't think so either. Clasp is for scientific computing and 64bit is the present and the future.
13:39:41
drmeister
I just always thought it would be easier to implement a 32bit processor in a nanobot than a 64bit processor. (sigh)