search

accre / lstore

LStore - A fault-tolerant, performant distributed data storage framework.
http://www.lstore.org
Apache License 2.0
4 stars 5 forks source link

Opaque-ify structs that are needlessly public. #2

Open PerilousApricot opened 8 years ago

PerilousApricot commented 8 years ago

We currently expect to be able to find includes in the top-level search path. I.E. when GOP includes the toolbox's log handler, it does so with #include "log.h". This works locally, but we have a lot of very-commonly-named headers that conflict. Best case, RPM will make our packages uninstallable next to other ones with the same names. Worst case, someone who wants to use our APIs will slam into tons of weird include cycles. For instance, if they have a "log.h" of their own (which is probable), our version is shadowed.

PerilousApricot commented 8 years ago

Since merging into one repository, this has become much simpler. I have a script that atomically (i.e. in one commit) splits the header into two parts (public and private), then changes all #includes for everywhere that references the code.

PerilousApricot commented 8 years ago

Blech. I'll have to do this in two phases -- there are a lot of users of the containers who want to add them directly to structs (and not through a pointer), which means you can't just give an opaque class.

  1. Split everything into public/private, with some overrides to add structure definitions for certain structs
  2. Everything that can't be made into a strictly opaque pointer should probably be turned into header-only definitions, to prevent having to freeze ABI
PerilousApricot commented 8 years ago

See chapter 1 of https://www.cs.rit.edu/~ats/books/ooc.pdf and http://stackoverflow.com/questions/31195551/opaque-types-allocatable-on-stack-in-c for stack-allocable opaque types

PerilousApricot commented 8 years ago

First part is done, need to work on opaque-ifying the structs.