On 7/07/2015 3:34 a.m., ponce wrote:
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
If reviewing the code itself is too much of a hassel, please review
the specification document.
http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_specification.html
Use the Cartesian coordinates system using two (X and Y) size_t integers
Why not just int? There is preciously little addressable images beyond
2^31. size_t has a variable size and is a source of build breaking.
Also, please no unsigned integers! This create all manners of bugs
because of how integer promotion work.
I've been sold on the unsigned vs signed type issue for and only for the
x and y coordinates.
Although I'm a little concerned about not using ptrdiff_t instead of a
specific integral type. For the time being, I'll alias it and use that
instead. This will need to be decided later on.
Offsets will still be size_t. As it would be too limiting.
A major concern for D is templated code. Template bloat as it is known
is when there is large amounts of templates being initiated with vast
array of compile time arguments. For this very reason, template usage
must be constrained to the bare minimum. Keeping in line with other D
code of highly reusable code, templates will be used. Be constrained
to colors (usage not definition) and constructors as much as possible.
I don't think there is so much problems with Phobos levels of
meta-programming. There are also way to reduce template instantiation
with type-punning.
To me an image library should be based on a static interface with
optionally a wrapper to auto-generate the dynamic interface much like in
std.allocator. Is it the case? Your library seem to be based around the
dynamic 'interface' instead.
I choose structs primarily for my types because it can be optimized away
and also allocated on stack instead of the heap.
If people prefer classes they can and are more than welcome to use them.
There are interfaces for just this purpose identical to ranges.
Only like ranges there is no point on just relying on it.
Instead I have SwappableImage struct. Which allows with no allocation to
wrap up any image storage type you wish via the constructor. I am very
proud of this.
http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_interfaces.html#.SwappableImage
