Ilya,
Thanks for provoking me to share my observations about a way how we,
java people, use C.
I agree that at the first place the usage of names should be
conventional, and if you have code which is reusable for non-java
purposes then the name jboolean is definitely not the best choice. I
would not call our JIT reusable, and even most portlib functions have
a small chance of being reused in different projects because they were
built and selected to reflect java semantics at the first place. If
they are really reusable, do we have a patch suggesting them to be
added to APR?
For C++ code we may use bool, which is a part of C+ standard and that
is why it is quite conventional. For pure C interfaces using booleans
is not a typical practice. My honest believe is that using boolean
type is not a typical pattern of C programming, and hardcode C
programmers use ints, bit masks or bit fields instead. For example, to
indicate that an operation was successful, a C programmer would use an
integer return code with predefined semantics, eg ENOMEM would mean
that C heap is exhausted.
Another consideration is that C is usually used for compactness and
tends to avoid passing booleans backward and forward between
components. Consider strcmp call: it is mostly used to compare
strings, but returns integer to allow string alphabetical comparison.
Another example is initialization:
if (!is_initialized()) {
initizalize();
}
Instead of exposing two interface functions, one may choose exposing
one with the following semantics: initialize_if_not_initialized(). For
general compactness we use 0 for false, and some useful value for some
sort of true. This true has something descriptive about the truth it
represents. The malloc returns 0 for false, and a useful pointer
otherwise. All this helps to replace two interface function calls
(check + action) with one and minimize an interface. Generally if the
code is expected to look like conventional C, it's good to use C style
for interfaces.
It would be great to have portions of our code reused in other
projects, and if that projects expose a different semantics, I'm more
than ok to use coherent aligned semantics for that portions of code.
But in general JVM has java/C++/C semantics, and so
jboolean/bool/int/bit mask/bit field should be used unless the code
have a real different use case.
What do you think about it?
Thanks!
On Fri, Mar 7, 2008 at 7:08 PM, Ilya Berezhniuk
<[EMAIL PROTECTED]> wrote:
> Alexei,
>
> I agree, these type and values look reasonable in the code related to Java.
> However, using them everywhere in C/C++ code is not feasible - I hate this.
> Specifically, JIT can be used for compiling a code not only from Java
> bytecodes...
>
> Thanks,
> Ilya.
>
> 2008/3/7, Alexei Fedotov <[EMAIL PROTECTED]>:
>
>
> > Hello,
> > I vote for not using Boolean at all. jboolean is a part of the
> > standard we are implementing [1] while Boolean is not. The same
> > applies to JNI_TRUE/JNI_FALSE macros in favour of TRUE/FALSE.
> >
> > [1] http://java.sun.com/docs/books/jni/html/types.html
> >
> >
> > On Fri, Mar 7, 2008 at 6:49 PM, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> > > Alexey,
> > > there is a problem with this commit.
> > > Some of methods that returns Boolean (that is 'unsigned') are
> described as
> > > 'bool' in vm_interface.h
> > > It's not the same and causes problems. For example I found that H2092
> fails
> >
> > [...]
> >
> > --
> > With best regards,
> >
> > Alexei
> >
>
--
With best regards,
Alexei
