Hallöchen! In order to avoid a dependency of Lensfun's include file on GLib's include files, Lensfun's original author splitted the lfModifier class in lfModifier and lfExtModifier, the latter being private. This way, GLib's include files are only needed when compiling Lensfun, but not the calling program.
Therefore, lfModifier doesn't have a constructor. Instead, there are "Create" and "Initialize" methods that must be called to have a functioning object. "Create" sets the coordinate scale, and "Initialize" adds the callbacks to the callback chain. In all methods of lfModifier, the object "this" is first typecast to an lfExtModifier object. All of this is very ugly and error-prone (even the Lensfun developers happened to tumble over this). Besides, the API is difficult to extend. Is the non-dependency on GLib's include files really so important? I'd like to see Create and Initialize being merged into a constructor proper. What's the best way in C++ to make the parameter list extensible? For example some day, I may want to have the image's timestamp in the parameter list. How can one design the API to make such changes painless? The old API must remain parallely, which should not be a problem. Tschö, Torsten. -- Torsten Bronger Jabber ID: [email protected] or http://bronger-jmp.appspot.com ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lensfun-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lensfun-users
