Search This Blog

Monday, April 4, 2011


Well, my project is approximately 12 days old, but when I mentioned what I was working on at an all-day meeting on Friday, I got immediate interest from 2 different groups, along the lines of 'why isn't it done yet?'.  I knew that there was a need for fast, accurate radio propagation software, but I didn't realize HOW MUCH need there was! 

On to more prosaic matters.

I spent a little while finding a good UUID generation library, which I have.  I'm using the OSSP UUID library for all the reasons I outlined in the wiki (which I updated), and more reasons besides.  I still haven't decided if I should wrap their functions to make it easy to port to other platforms or not, but I think that for the time being I'm not going to bother wrapping them.  I don't have enough time to do so at the moment, and the UUIDs will never be exposed in the public API, so in the worst case, someone is going to foolishly try to extract a UUID, and then get burned when the internals all suddenly change.  I'm fine with that, private APIs should never be linked against, it breaks modularity in a big way.

I also slightly reorganized my code so that everything that is supposed to be private will live in the Private directory from now on.  I can't think of any way to make it more clear that you shouldn't link to stuff down there than that, but I know someone is going to try anyways.

Finally, I think I'm going to have to go to a client/server architecture; I need to cache a lot of stuff on the backend, its the only way to get the necessary performance.  I was originally thinking I could do everything in C, but I need fast, well-written containers.  I can use uthash, but I know the STL is supported absolutely everywhere, which means C++.  I don't like it, but it's practical, and it lets me use Boost and Thrust, if I really need them.  I'm going to keep the public API in C though; it makes getting SWIG working easier, if I decide to add it in the future.  Thoughts?

1 comment:

  1. As we discussed, I like your C API. I'll be curious to hear your experience if you use Thrust under the hood in addition to (or instead of) raw CUDA. I agree - definitely don't waste time wrapping the UUID library. Move on to the meat of the problem.