Live data from Hacker News

Android++: Native development and debugging extension for Visual Studio

android-plus-plus.com

31–40 of 55 posts

Re: Android++: Native development and debugging extension for Visual Studio

#31

This is certainly good for games and similar multimedia heavy type apps. However, if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles, and would be better off with JavaScript (no, really) and/or platform specific code to leverage the class libraries of the respective platforms. C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious…

> if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles

Maybe if you're starting from absolutely nothing. If I had non-trivial functionality already written in native code then I suspect I'd rather write JNI bindings than do a complete rewrite in Java.

I'm also skeptical of 'use more memory' and 'load less quickly'. Even the GNU C++ standard library on an x86-64 desktop is a less than a megabyte. I can't imagine that being significant in either of those problem areas.

Re: Android++: Native development and debugging extension for Visual Studio

#32

This is certainly good for games and similar multimedia heavy type apps. However, if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles, and would be better off with JavaScript (no, really) and/or platform specific code to leverage the class libraries of the respective platforms. C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious…

It's my understanding that this counter-intuitive performance problem with Dalvik is what crippled the original UI for Android Firefox - they were using their native C++ UI stack (the one used on Windows, Mac and Linux) to implement the whole browser UI, but they found that in practice a UI stack written in Java running on Dalvik performed better because it wasn't subject to all the weird performance penalties from i…

I don't think that's entirely correct (yes, XKCD #386 applies):

First, I'd hesitate to use the phrase "native C++ UI stack". Mozilla's UI framework is XUL, which is a mixture of JS and XML. Presumably there's C++ underneath, but based on my reading it's a mixture of web-based technologies.

Second, because the original Firefox for Android UI was written in XUL, they had to load the entire Gecko architecture in order to render any UI. That was ultimately the performance issue, not "interacting with android frameworks".

Because of that, the goal of the rewrite was to be able to show the UI immediately, while loading the Gecko stack in the background.

There's some good info on this at http://starkravingfinkle.org/blog/2011/11/firefox-for-androi... and http://www.mozilla.jp/static/docs/events/vision/2012/04-mark... .

Re: Android++: Native development and debugging extension for Visual Studio

#33

I am curious, what are the benefits of VS over other IDEs? Obviously, there is the case where the code shop may have other project assets tied into the VS ecology-dev system but is that the only case?

IntelliSense is the best C++ code completion/"jump to definition"/"find all callers" feature available on any platform. The Visual Studio debugger is the best C++ debugger I've used. That's pretty much it, but it's enough.

Code completion and jump to definition isn't unique to VS. Pretty much any modern IDE offers it. GDB is an extremely powerful debugging tool that has a feature set that is really hard to match. It just has an extremely step learning curve. I can't really see much of an advantage of this besides getting to use tools you already know, which no doubt is a huge advantage.

Re: Android++: Native development and debugging extension for Visual Studio

#34

I am curious, what are the benefits of VS over other IDEs? Obviously, there is the case where the code shop may have other project assets tied into the VS ecology-dev system but is that the only case?

At least one clear advantage is that Eclipse is horribly slow in debugging when compared to VS. I don't know how does IntelliJ compare to it because I haven't used that.

Eclipse (at least for Android, I don't know how the platform-specific plugins affect this) is painfully slow period. My workstation is not new, but it is a decent quad core and it does have 8GB of RAM... yet even with nothing but openbox, a browser, and a text editor to contend with, it still manages to bog and lag consistently.

Re: Android++: Native development and debugging extension for Visual Studio

#35
post #6

Earlier quoted context omitted.

What is like working with the NDK? C++ is the one language that can work on both iOS and Android (and Windows phone?) Personally, I'd like to get some reuse out of my iOS code. I'd do more C++ if I knew that I could reuse it. Of course, Objective C could actually be portable too.

> C++ is the one language that can work on both iOS and Android (and Windows phone?) C# can do that too, using Xamarin.

C++'s benefit is that it is common to all SDKs.

With Xamarin you must buy it, which may not be an option for hobby developers.

Re: Android++: Native development and debugging extension for Visual Studio

#36
post #21
post #4

Earlier quoted context omitted.

Don't forget games, the vast majority of popular games are likely running native code. I don't have any stats on that, but you can check out the following games made using the open-source C++ framework Cocos2d-x that the developers asked to be featured: http://www.cocos2d-x.org/games/all?p=8&page=1

Yeah, nobody wants to have a GC pause just as they're about to do something tricky.

So maybe AAA studios shouldn't be using Unity. Oh wait...

Re: Android++: Native development and debugging extension for Visual Studio

#37
post #2

Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.

They also say: In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. Which continues to annoy me even now. I recall the fireside android team chat one time (two years ago?) that went something like: Question: So what about the NDK? You can't beat native for performance... Android team member: *laughs* ... well, you can't beat java for portability C…

Yeah, right.

However,

- Google has managed to fragment the Java world

- Pushes Renderscript instead of OpenCL

- Forces everyone to go via JNI to access Android APIs in C and C++ land

They are no better than the other players.

I am actually curious to find out what are their plans in regard to ART. Only replace Dalvik, or go further in terms of what will be the set of supported languages.

Re: Android++: Native development and debugging extension for Visual Studio

#38

Earlier quoted context omitted.

IntelliSense is the best C++ code completion/"jump to definition"/"find all callers" feature available on any platform. The Visual Studio debugger is the best C++ debugger I've used. That's pretty much it, but it's enough.

Code completion and jump to definition isn't unique to VS. Pretty much any modern IDE offers it. GDB is an extremely powerful debugging tool that has a feature set that is really hard to match. It just has an extremely step learning curve. I can't really see much of an advantage of this besides getting to use tools you already know, which no doubt is a huge advantage.

No other code completion tool for C++ comes close to what VS offers, especially in speed. GDB is "powerful" but its UI is no comparison to VS, and when I say that I don't mean "GUI is better than CLI", I mean GDB's UI sucks. And UI does matter.

Re: Android++: Native development and debugging extension for Visual Studio

#39

This is certainly good for games and similar multimedia heavy type apps. However, if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles, and would be better off with JavaScript (no, really) and/or platform specific code to leverage the class libraries of the respective platforms. C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious…

C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious if you're used to other worlds, but it is a side effect of how pervasive Dalvik is on the system.

Citation required, as this is entirely the opposite of every experience I've had actually building apps that use significant native code. What are you basing this claim on?

There really isn't anything magical about Dalvik (or ART) -- it is a per instance runtime. C++ code doesn't suddenly become heavier or slower to load because of Dalvik.

And of course the overwhelming majority of games are mostly built using the NDK.

Re: Android++: Native development and debugging extension for Visual Studio

#40

Earlier quoted context omitted.

IntelliSense is the best C++ code completion/"jump to definition"/"find all callers" feature available on any platform. The Visual Studio debugger is the best C++ debugger I've used. That's pretty much it, but it's enough.

Code completion and jump to definition isn't unique to VS. Pretty much any modern IDE offers it. GDB is an extremely powerful debugging tool that has a feature set that is really hard to match. It just has an extremely step learning curve. I can't really see much of an advantage of this besides getting to use tools you already know, which no doubt is a huge advantage.

Code completion and jump to definition isn't unique to VS

of course not. But that is not the point, instead the point is those tools in VS are better than anything else out there. Having used a bunch of them I tend to agree. Definitely usability-wise the debugging experience just beats everything else.

Post reply on HN