harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: svn commit: r634547 [2/2] - in /harmony/enhanced/drlvm/trunk/vm: em/src/ include/open/ interpreter/src/ jitrino/src/codegenerator/ia32/ jitrino/src/codegenerator/ipf/ jitrino/src/jet/ jitrino/src/shared/ jitrino/src/vm/ vmcore/build/ vmcore/src/c
Date Fri, 07 Mar 2008 21:57:23 GMT
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()) {
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?

On Fri, Mar 7, 2008 at 7:08 PM, Ilya Berezhniuk
<ilya.berezhniuk@gmail.com> 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 <alexei.fedotov@gmail.com>:
> > 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 <mike.fursov@gmail.com> wrote:
>  >  > Alexey,
>  >  >  there is a problem with this commit.
>  >  >  Some of methods that returns Boolean (that is 'unsigned') are described
>  >  >  '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,

View raw message