Hi Jürgen: Thanks for responding to my proposal. Yes I understand and didn't take static into account. I do like your cleaner and simple proposal.
Where would the source for all these Class XyzInput files be hosted? Part of the distribution? Or would the end user supply them at build time? I would hope that they must also be GNU licensed like the rest? Also would we allow just one Android, one OS X, etc? And how do you feel about Output? Does it make sense to do the same thing there? respect…… Peter On 2014-06-16, at 12:30 PM, Juergen Sauermann <[email protected]> wrote: > Hi Peter, > > I see a few problems with your proposal. > > Currently class Input has only static functions, so virtual methods can not > be used to distinguish > between different implementations of the same function. > > Suppose we would fix that by using Input instances. Instead of eg. > > #ifdef HAVE_ANDROID > > line = Android_Input::get_line(); > > #else > > line = Input::get_android_line(); > > #endif > > We would then have eg. > > class Input { ... } > class Android_Input: public Input { ... } > class Normal_Input: public Input { ... } > > #ifdef HAVE_ANDROID > > Android_Input a_input; > Input * input = a_input; > > #else > > Normal_Input n_input; > Input * input = a_input; > > #endif > > ... > line = input->get_line(); > > IMHO this is only adding complexity without really making things more elegant. > > And it does not solve the real problem, which I believe is the following. I > assume > that Elias' Java environment has a number of nasty (read: totally > incompatible) things that > I cant support in a reasonable (read: portable) way. The two derived classes > would still need > to be compiled, but one of them is not portable, which will create a lot of > headache for all > non-Android users. > > A much cleaner (or at least simpler) proposal, in my eyes, is this: > > 1. We use two files Input.cc and AndroidInput.cc. > 2. Both use the same Input.hh so that all other source files are no affected. > Not all functions > declared in Input.hh need to be implemented, so AndroidInput.cc. can be > rather simple. > 3. The src/Makefile decides which of the two files shall be compiled in a > given environment. > > /// Jürgen > > > On 06/16/2014 04:43 AM, Peter Teeson wrote: >> I suggest once again two abstract classes for I/O with virtual methods which >> can then be inherited from and implemented by the user. >> This special case patching of fixes is not elegant - to me it is smelly >> coding. >> Sorry if I offend but that's my 2¢. >> >> Peter >> >> On 2014-06-15, at 4:06 PM, Elias Mårtenson <[email protected]> wrote: >> >>> Do you think it would be possible to apply this patch that avoids setting >>> up the output streams when compiling for Android? The Android version >>> installs its own that redirects the output to Java streams. >>> >>> Regards, >>> Elias >>> <streams.diff> >> >> >
