Re: Meego vs Android apps (C or Java?)
 

Totally agreed. I use C myself, and don't know much about Java, but what I really like is Python! =) And I must say I code in Python always very much aware of where all inner pointers and gotos are pointing at. I try to keep in mind that programming languages are illusions over the real bit flipping operations, and all these seemingly important debates lose importance to me.

But I am really replying just to share this quote here with you guys:

Re: Meego vs Android apps (C or Java?)
 

Just to add a tiny nuance: C# offers pointers if you agree to be on your own, taking full responsibility for it all.

And when you do, optimizing the code gets harder (for the more interesting cases than just slipping a pointer to a native library call).

If you stay away from such endeavours, C# is not offering any pointers for the programmer to use.

With the usual AFAIK disclaimer. ;)

Re: Meego vs Android apps (C or Java?)
 

I really can't blindly accept what the post says. A long time ago, in a version far far away, glibc started using mmap() on /dev/zero instead of brk() to allocate memory. This has the advantage that memory that is freed returns to the OS immediately and Linux is able to handle memory fragmentation better than Firefox itself (memory fragmentation on OS level is a very different thing). This means that there needs to be no free memory handling in any application, unless the app chooses to re-use its freed memory. But even in that case, fragmentation could be reduced by just freeing fragmented memory.

So, no. When judging languages leave the memory fragmentation out of the conversation and surely don't compare the memory handling of Java with the memory handling of Firefox. I'm 100% sure that the Llinux kernel can do much better than JVM since it has actual view of the physical ram and the actual page allocation.

Re: Meego vs Android apps (C or Java?)
 

This whole thread is moot now.
Should you change topic to "WP7 vs Android apps (C# or Java?)"

When I have time, I try to prove that slowing down of my Firefox is due to heap memory fragmentation. No *malloc can remove fragmentation totally, because alive objects cannot be moved in the heap if pointers are allowed in the code (C/C++). I could point to some studies done for GC+memory management, but you guys can find them yourselves also with google.

And yes, Java also kind of still have pointers, via JNI kinda, but as with C#, optimizations go down the drain then on that basic block of the code where the pointers are used.

Re: Meego vs Android apps (C or Java?)
 

In what way is that different from C++ ? :) Admittedly the 'usual C++ way' is heavy with pointer use, but that's not a requirement by any means.

Just make sure Flash and javascript are disabled as those might prevent the release of memory.

That is sort-of true for *unmanaged* pointers, but for example if you use Qt, most of your objects would be QObjects or wrapped in smart pointer classes which allow Qt to do whatever it wants memory-wise as it 'knows' about what is where.

This is a fairly difficult question for several reasons. One reason that you do not know the link between the heap and the physical memory (swap, virtualization, etc). Thus, if suddenly your memory manager decides 'hey if I move this there might be space for that new object' it might actually cause a performance decrease depending on what needs to be done in heapspace. If a VM tries to take over the OS's memory management function, that's always a dubious outcome.

Re: Meego vs Android apps (C or Java?)
 

C++
C#
The interesting difference, in this context, is that in C#, you must to be in an unsafe context/scope to be able to use pointers. In C++ it's just another construct, needing no special handling to be used.

Re: Meego vs Android apps (C or Java?)
 

Yes, I understand that, but IMO that's more syntactic sugar/policy question than a technical differentiation. The choice is still yours, it's just that you have less 'are you sure' dialogs :)

Re: Meego vs Android apps (C or Java?)
 

Huh? If there is something it isn't, it's syntactical sugar.

By declaring an unsafe context/scope you bypass the strict typing checks (not totally, but almost) and if you use fixed pointers you bypass the GC, not letting it move the pointed at memory.

This isn't sugar in any way, shape or form. This is affecting the compiler and the runtime behaviour.

Sure, you can stay away from it, but if you use it, you need to use these special constructs, bypassing things and affecting others. Which was my point.

C# offers pointers, but not in the same way as C++, or C. If you use them, you're letting go of some fundamental features of the language along the way.

Re: Meego vs Android apps (C or Java?)
 

Sorry to drag this conversation from the depths, but..

Wouldn't it be possible to create a object/class that emulates pointer memory modification in a safe way?

It could potentially use the array primitive as the heap object to avoid the costly method call per pointer op and provide the mechanisms to do basic [pointer] arithmetic. It could also contain handy functionality to automatically re-size the object as memory needs increase/decrease to more closely emulate C's malloc.

Since all objects are passed as references in method calls, this could give different aspects of an application access to the same structures in a safe way -- and very little computational penalty. Also data structures would be totally isolated from one another, which is a definite plus.

While I appreciate that for a great many cases, objects and references are a fine substitute for the pointer, I also recognize that more exotic structures can use pointers to great effect. Perhaps this is a way to do it in the modern VM space.

Re: Meego vs Android apps (C or Java?)
 

I was referring to it more in a policy context - a 'friendly' compiler could generate warnings on such code which you could 'declare' right by definint adequate pragmas (=you can achieve the same effect). Yes, syntactic sugar is not the most matching term, but I know no better how to describe this 'more than one way to do it' thing :)

QPointer and friends *sort of* do this. My code is mostly devoid of class* thingies because it's easier and safer to use Qt's smart pointer classes. While this does not do object movement in memory (*now* - as said above, benefits of that can be ambiguous), it does affect memory management, as it provides reference counting, CoW operations, shared data, etc.

Which brings things us to the (repeated) bottom line - C++ as such does not *require* a certain type of memory management, it's not part of the language, so if you have a fancier, smarter way of dealing with allocated memory, give it a go.