On 2012-11-16 20:58, Artur Wroblewski wrote:
On Fri, Nov 16, 2012 at 6:40 PM, Jef Driesen jefdriesen@telenet.be wrote:
On 2012-11-15 19:43, Dirk Hohndel wrote:
Please make the memory application owned and have the application be responsible for freeing memory. Unless you are planning to run libdivecomputer on a wristwatch the overhead for that is negligible with today's OSs (that all have a reasonably smart malloc implementation that will reuse the recently freed memory block on its own).
I certainly agree that this is probably the most intuitive and simple design.
But while I'm not too concerned about the memory allocations by themselves, I still find it a bit silly having to allocate resources where it's not strictly necessary. For the sample data I simply can't think of any use-case where you would want to hold on to the sample objects outside the callback function. Hence my search for possible alternatives.
I agree with Dirk. Trust the users of your lib and keep it simple.
Create an instance of data for each sample or have one data container and require application to copy the data before next iteration step.
There are plenty of data containers and frameworks (i.e. language bindings), which can be used. The simpler libdc is, the easier integration is going to be. No need to reinvent your own.
See my response to Dirk. Using "applications owns" everywhere to make the api consistent is fine for me.
CNS/OTU can be calculated from the samples
IMHO, you can't if you don't have previous dive information as you don't know the initial CNS.
True, but nobody says that an application can't take into account a series of dives :-)
But that doesn't mean we won't support it. We are just trying to see what is out there, what users want to have, and then make a good decision based on that.
, but we can consider to support it too. I have no idea which devices record this in the data. I know the Suunto's have this weird OLF (Oxygen Limit Factor) value, which is either the CNS or OTU, whichever is higher. And I think the Oceanics have a scale from 1 to 5 or something. So that might be a bit more difficult to support in a uniform way.
If some devices do something their own way, i.e. OLF or 1-5 scale, then ignore it until they document how to recalculate into CNS. For those who really want to deal with such "inventions", there sill is raw data. The rest of us will benefit from simpler (but still flexible) interface.
That's also how I think about it.
I assume with NDL, you mean the remaining no-deco time? I don't think any device does support that.
OSTC supports above.
And we'll support it to. It's already implemented and will be committed soon :-)
Jef