Stack size

[Jonathan Olson]

On Monday, December 10, 2001, at 12:27  AM, Steen Jansdal wrote:

> Thanks for your responses and advices to my
> questions, its much appreciated.
>
> Jonathan, your are right that a mix of C, C++ and
> java is not desired, and if the C/C++ part gets too
> big I will drop java completely. I hope that I can
> keep the C/C++ modules to an absolute minimum.
> Hopefully in a few device drivers.
>
> I'm hoping that it would be possible to run the program
> on a normal windows box, a real linux box and the
> new embedded box. You know: WORA.
>

The C++ code I write runs on MacOS X, WIndows, Linux, and
Solaris.  If you start with appropriate abstractions to Thread
libraries, network libraries, etc, you really don't have problems
supporting the code on all architectures.  In fact, C++ is easier in
many ways to support systems code on multiple architectures
because it provides conditional compilation.  Java's assumption
that all machines are identical just doesn't hold water when you're
doing systems programming.

> Is it really true that a gcj program is approximately
> twice as big as a C/C++ program? If thats true I
> definitely have to have that in my mind when I do
> my decisions.
>
> Why are all these metadata stored in the program?
> Is it for reflection?
>

Yes, we do alot of embedded work with both Java and C++.  Java modules
are at least twice the size as C++ modules which perform the same 
function.
Metadata isn't optional in Java, since the Java reflection support 
requires it.
Unfortunately, you'll probably never use more than 1% of that metadata 
but
there's no way for the compiler to know which 1% you'll need.

> The reason I'm prefering java is that's its much
> easier to maintain than C++ programs filled with
> macroes, operator overloading and so on.
>

Just because a feature exists doesn't mean you have to abuse it.  Macros 
are
incredibly useful for many purposes like conditional compilation where 
they're
just plain better than anything Java provides.  Templates and multiple 
inheritance
seem complicated until you discover many situations in which they 
provide the
best way to solve a problem.  Even operator overloading has cases in 
which
it makes the API more readable and useful.  Say, for example, you're 
implementing
an Object data base and want to create a DBReference class.  In C++ it's 
really
nice to overload the operator->() operator.  Yeah, it's syntactic sugar 
but it makes
APIs more readable if it's used correctly.

Every feature in a language can be abused.  One shouldn't condemn a 
language
because of bad programmers.

> Who hasn't downloaded a C++ program from
> sourceforge, just to discover that's it completely
> impossible to understand the program. If you aren't
> careful you end up with a program thats Write Once,
> Never Read. But then again it's just my oppinion.
>

Agreed.  But I've seen just as much badly written Java code as C++ 
code.  Java
has it's place.  It's great as a internet/web-site language, for 
downloadable code
in which binary compatibility is the most important attribute.  However 
as a systems
programming language in which you compile architecture specific binaries 
for
the target system, and especially in embedded systems with both memory 
and
processor speed constraints I contend that Java is just plain the WRONG 
solution.

About 2 years ago I thought that Java would be God's gift to embedded 
programmers.
After 2 projects using Java on embedded 32-bit processors I now think 
differently.
Java is just too inefficient, too bloated, and is missing too many 
necessary systems
programming features to be good for embedded devices.  Have you ever 
tried to
subset the JDK APIs to make it fit into 2-4 megs of flash?  It's not 
fun.  Turns out that
the JDK is a forest of references between every class, not the nice 
layered APIs that
you want for embedded use.  Many of the methods in Java classes need to 
get stubbed
out on different architectures, but without conditional compilation this 
requires separate
source files for each architecture.

> Another reason is that java is now a language thats
> learnt in school. When I hire new people almost all
> candidates have java skills.
>
> Steen Jansdal
>