| 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
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 <address@hidden> 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>
|