Re: [android-developers] Re: Android preprocessor, //#ifdef...
Hi, You can use antena. Same as J2ME. Best. 2010/7/31 Kostya Vasilyev kmans...@gmail.com The absence of preprocessor has to do with Java, not Android. And tlhere is a lot of Java software out there... -- Kostya Vasilyev -- http://kmansoft.wordpress.com 01.08.2010 0:00 пользователь sblantipodi perini.dav...@dpsoftware.org написал: ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblan... perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understo... TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are su... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Huynh Ngoc Vu Nguyen Add: Duy Xuyên - Quang Nam E-mail: vunguye...@gmail.com Phone: 0935102789 -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Yes, I noticed that. I noticed that while they characterized the relative sizes of the pauses, they didn't put any bounds on them. If you choose not to call this concurrent GC, I'm not about to argue! But is there a concurrent algorithm that doesn't sacrifice overall throughput? There are a lot of factors that affect GC performance -- everything from memory footprint to latency to allocation and mutation patterns, to what clues the running application can give, to memory cache architecture. (That's one reason I say GC benchmarking is hard work!) Concurrent != better for all applications. Sun's VMs have clearly always been compromises, that haven't suited everyone. Perhaps I should experiment with using Sun's concurrent algorithm with Eclipse, since latency is more my complaint than throughput. Or maybe it's already the default. I don't recall, and as you point out, the options are overwhelming :=) But to harken back to the roots of this GC digression -- ever sit and wait for a C++ program to deallocate some huge datastructure? (Firefox has been a common offender). Even a poor GC does better. On Aug 3, 10:35 pm, DanH danhi...@ieee.org wrote: Notice that they call it low pause, not pause free. There are truly pause-free algorithms, and people who need them. Brokerage systems, eg, need response in the 10s of milliseconds, and a single GC can disrupt a thousand transactions. iSeries had the SPECjbb crown for several years running, first with its own JVM and then with the IBM J9 portable JVM. Was finally displaced by J9 running on other hardware (as the iSeries hardware was getting out of date). Sun did eventually build a special IBM killer box to reclaim the crown by throwing hundreds of processors at the problem (and building hundreds of tuning parameters into the JVM), but it was an artificial configuration. On Aug 3, 9:12 pm, Bob Kerns r...@acm.org wrote: Well, perhaps this illustrates your second point, but: http://tinyurl.com/sun-concurrent-gc Or it may be that they're not concurrent enough for you. Concurrency isn't an absolute, and there are various ways of describing the upper bounds on how much delay a concurrent algorithm can impose on other threads. (Your point about stringent response time requirements suggests this may be your issue with calling it concurrent). GC benchmarking is hard work and tricky, and I haven't done it in a long time. I appreciate the anecdotal data; do you have benchmarks behind it? You've aroused my curiosity about the current state. I have generally been more concerned with compatibility in huge code bases rather than performance differences (which can generally be overcome with hardware -- not concurrency, though), so I've mostly avoided non-Sun JVMs when possible. But I like that there are alternatives of increasing quality. Especially given recent corporate history... Thanks. On Aug 3, 6:07 am, DanH danhi...@ieee.org wrote: Well, none of Sun's implementations are concurrent -- they all force the application to stop for a time. They're not generally well- designed for LARGE applications (eg, a fast 8-way running a heavy transaction system), or anything with really stringent response time requirements. The IBM iSeries Java implementation ran rings around Sun's, and the newer IBM portable Java implementation runs rings around the iSeries implementation. One of the problems with Sun's GC scheme is the vast number of parameters -- no one understands them, or how to set them for a given set of circumstances (especially if those circumstances vary dynamically). On Aug 2, 9:57 pm, Bob Kerns r...@acm.org wrote: OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible
[android-developers] Re: Android preprocessor, //#ifdef...
There are other uses besides logging, or at least the kind of logging you're thinking of. For example, let's say you have a large complex server with large complex datastructures with long lifetimes, and a high server availability requirement. Let's say you experience a problem in production, that you have not been able to reproduce in testing. Or, that you can reproduce only with such a low frequency that slowing it down significantly is unacceptable. So you tag a structure with where it is created and/or modified. You may even do this preemptively, so that you CAN log and analyze these post-failure. There are a few other circumstances, even less common. And don't assume that performance is not important for logging. The more efficient logging is, the more you can afford to use it, and the better you can maintain your program while in production. Finally, the usual C/C++ use of __FILE__ and __LINE__ is in a macro that calls a function that takes them as arguments. You can play tricks with this (and #undef) to allow you to not have to rewrite your code when the base function was not designed to take them as arguments, but to redirect the calls to a debug version. Nothing here requiring a preprocessor, of course, just macros and the __FILE__ and __LINE__ directives. On Aug 3, 6:21 am, Kostya Vasilyev kmans...@gmail.com wrote: The main reason to need these is logging / debugging, so runtime overhead is acceptable. Or am I missing something? On the other hand, __FILE__ and __LINE__ are only valid where they are used - there is no way to get the caller's file and line info, so it has to be passed to whatever functions you want to use them in. And that is certainly a maintenance issue - what if you decide to log caller file and line in a function that was not designed for it from the start? It also would be interesting to know why exactly the OP thought he needed the preprocessor. Who knows, maybe he wanted to produce separate versions of his application for different screen sizes / densities? -- Kostya 03.08.2010 17:10, DanH пишет: Right. The compiler knows what the line number is (at least if there's no preprocessor in the way). It can return that from a pseudo- function. Same for class, method, etc. On Aug 2, 10:03 pm, Bob Kernsr...@acm.org wrote: Note that you don't need a preprocessor to do this! Just a bit of language support. On Aug 2, 8:01 pm, Bob Kernsr...@acm.org wrote: Yes, I've seen a few cases like this. There are ways to cache the runtime call, which can be a bit expensive, but they rely a bit much on convention and are a bit more verbose than you'd like. On Aug 2, 7:02 pm, DanHdanhi...@ieee.org wrote: Lots of times it would be nice for logging. Sometimes you'd like to store an I was here indicator in a structure when you modify it. Yes, there are alternatives, but not as nice. -- Kostya Vasilev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Hi DanH, Your luck that this is not a J2EE forum. Their are ton's of 7x24h applications based on sun's vm running day by day for years. The last years I worked mostly with the jrockit vm from bea ( now oracle) in such a highly parallel environment with up to several hundred transaction per second. In our enviroment the parallel GC was never a problem and we need to allocate and free several GB in a short time. Maybe you simply made some bad experiences with IBM stuff ? Good luck ! Frank On 3 Aug., 15:07, DanH danhi...@ieee.org wrote: Well, none of Sun's implementations are concurrent -- they all force the application to stop for a time. They're not generally well- designed for LARGE applications (eg, a fast 8-way running a heavy transaction system), or anything with really stringent response time requirements. The IBM iSeries Java implementation ran rings around Sun's, and the newer IBM portable Java implementation runs rings around the iSeries implementation. One of the problems with Sun's GC scheme is the vast number of parameters -- no one understands them, or how to set them for a given set of circumstances (especially if those circumstances vary dynamically). On Aug 2, 9:57 pm, Bob Kerns r...@acm.org wrote: OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart
[android-developers] Re: Android preprocessor, //#ifdef...
On Aug 3, 10:46 pm, DanH danhi...@ieee.org wrote: Just a few bullet points: -- I've always thought that C #include processing sucked. Why did they never introduce an #includeonce directive that would have eliminated all the #ifndef stuff to prevent double includes?? Even better, go one step further -- call it #import, and put some constraints on it, like the file has to start and end at top-level, and no circular imports, and perhaps even that dependencies will be sorted automatically. -- C macros suck. They obfuscate without really introducing much capability. I've worked on languages that had macros that were their own language -- you could have real variables in them, loop, do most normal programming things. Code was generated via emit statements. With such a macro language you can do some amazing things, and with reasonable use (always a problem, I know) the macros served to clarify rather than obfuscate. Another model, found in Lisp, Scheme, and Bliss-32, is to construct a parsed representation of the code you want, and return it. (I'm not sure if that was in BLISS-16 or not). In Lisp or Scheme, macros are written in Lisp or Scheme -- in BLISS-32, it's its own language. -- Post-processing of Java bytecodes is expensive and error-prone, and again obscures the logic. Not that cost should be a criteria, but post-processing is no panacea. Yes, no panacea, but it needn't be all that expensive or error-prone. And it definitely does NOT need to obscure the logic. In most uses I've seen or done, it simply implements the logic shown in the source. It can obscure the flow somewhat, however. But so do inheritance or delegation. I leave it to you to decide whether things like Aspect-J obscure the logic. -- Yes, one should have to cost-justify including a line-number pseudo-function in javac. But there are a hundred features of Java that don't seem to me to be cost-justified, and several hundred other missing functions that ARE cost-justified. I never have figured out how Sun decided what went into Java and what didn't (though in several cases it appears to have depended on what would hide the deficiencies in their implementation vs expose them). I think I can cost-justify it! It's really easy to do, and it will take a lot of the wind out of the sails of people demanding Java adopt the C/C++ preprocessor! :=) More seriously, I think that datastructure tagging, while not that common, has enough value to justify the low cost. I have my own list of issues with what goes into Java and what doesn't. #1 would be why we need to use 'final' on variables referenced in inner classes? Unless, of course, we really want to make them final. But why should we have to do these stupid tricks to set a variable from an inner function? It's not like Guy Steele couldn't teach them how to compile that by now! (His Rabbit and S1 compilers handled that just fine -- back in the '70's... I spent a lot of time reading that code...) The next few slots would be filled with various generics issues... :=) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
Been there, done that. Didn't use the preprocessor. After the company began switching to Java, the client side was easily ported. Had I been relying on the preprocessor, it would have been difficult. For a system like this, file / line numbers are insufficient anyway. I implemented full stack trace, and this worked well. The system was enabled on all productions servers all the time, with no measurable performance impact. But I think we are getting further and further away from the original topic. The OP's point was that Android tools not supporting preprocessing is a horrible disaster and enough to call Android as a whole a failure. I think we can all agree that this is not the case. -- Kostya 04.08.2010 10:46, Bob Kerns пишет: There are other uses besides logging, or at least the kind of logging you're thinking of. For example, let's say you have a large complex server with large complex datastructures with long lifetimes, and a high server availability requirement. Let's say you experience a problem in production, that you have not been able to reproduce in testing. Or, that you can reproduce only with such a low frequency that slowing it down significantly is unacceptable. So you tag a structure with where it is created and/or modified. You may even do this preemptively, so that you CAN log and analyze these post-failure. There are a few other circumstances, even less common. And don't assume that performance is not important for logging. The more efficient logging is, the more you can afford to use it, and the better you can maintain your program while in production. -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Yep, I know there are a lot of large 24x7 apps out there -- many of the biggest are running on the IBM platforms I mentioned. And a year ago I was offered a lot of money to move to Chicago and help a major player rewrite the Sun GC to be fully concurrent, because the pauses were killing them. (But moving to Chicago was a deal-breaker for me.) This is an outfit that is doing thousands of transactions a second. On Aug 4, 1:48 am, FrankG frankgru...@googlemail.com wrote: Hi DanH, Your luck that this is not a J2EE forum. Their are ton's of 7x24h applications based on sun's vm running day by day for years. The last years I worked mostly with the jrockit vm from bea ( now oracle) in such a highly parallel environment with up to several hundred transaction per second. In our enviroment the parallel GC was never a problem and we need to allocate and free several GB in a short time. Maybe you simply made some bad experiences with IBM stuff ? Good luck ! Frank On 3 Aug., 15:07, DanH danhi...@ieee.org wrote: Well, none of Sun's implementations are concurrent -- they all force the application to stop for a time. They're not generally well- designed for LARGE applications (eg, a fast 8-way running a heavy transaction system), or anything with really stringent response time requirements. The IBM iSeries Java implementation ran rings around Sun's, and the newer IBM portable Java implementation runs rings around the iSeries implementation. One of the problems with Sun's GC scheme is the vast number of parameters -- no one understands them, or how to set them for a given set of circumstances (especially if those circumstances vary dynamically). On Aug 2, 9:57 pm, Bob Kerns r...@acm.org wrote: OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but
[android-developers] Re: Android preprocessor, //#ifdef...
Inner classes are one of several things that were done half-arsed, in order to minimize hits to the JVM. It almost seems like there was a period there when they were afraid to touch the actual JVM so they did obscene stuff in javac instead. Like I said, lots of the decisions don't appear to have been made on a cost/benefits basis, but rather based on someone's prejudices or perhaps working around an intransigent individual. On Aug 4, 2:09 am, Bob Kerns r...@acm.org wrote: On Aug 3, 10:46 pm, DanH danhi...@ieee.org wrote: Just a few bullet points: -- I've always thought that C #include processing sucked. Why did they never introduce an #includeonce directive that would have eliminated all the #ifndef stuff to prevent double includes?? Even better, go one step further -- call it #import, and put some constraints on it, like the file has to start and end at top-level, and no circular imports, and perhaps even that dependencies will be sorted automatically. -- C macros suck. They obfuscate without really introducing much capability. I've worked on languages that had macros that were their own language -- you could have real variables in them, loop, do most normal programming things. Code was generated via emit statements. With such a macro language you can do some amazing things, and with reasonable use (always a problem, I know) the macros served to clarify rather than obfuscate. Another model, found in Lisp, Scheme, and Bliss-32, is to construct a parsed representation of the code you want, and return it. (I'm not sure if that was in BLISS-16 or not). In Lisp or Scheme, macros are written in Lisp or Scheme -- in BLISS-32, it's its own language. -- Post-processing of Java bytecodes is expensive and error-prone, and again obscures the logic. Not that cost should be a criteria, but post-processing is no panacea. Yes, no panacea, but it needn't be all that expensive or error-prone. And it definitely does NOT need to obscure the logic. In most uses I've seen or done, it simply implements the logic shown in the source. It can obscure the flow somewhat, however. But so do inheritance or delegation. I leave it to you to decide whether things like Aspect-J obscure the logic. -- Yes, one should have to cost-justify including a line-number pseudo-function in javac. But there are a hundred features of Java that don't seem to me to be cost-justified, and several hundred other missing functions that ARE cost-justified. I never have figured out how Sun decided what went into Java and what didn't (though in several cases it appears to have depended on what would hide the deficiencies in their implementation vs expose them). I think I can cost-justify it! It's really easy to do, and it will take a lot of the wind out of the sails of people demanding Java adopt the C/C++ preprocessor! :=) More seriously, I think that datastructure tagging, while not that common, has enough value to justify the low cost. I have my own list of issues with what goes into Java and what doesn't. #1 would be why we need to use 'final' on variables referenced in inner classes? Unless, of course, we really want to make them final. But why should we have to do these stupid tricks to set a variable from an inner function? It's not like Guy Steele couldn't teach them how to compile that by now! (His Rabbit and S1 compilers handled that just fine -- back in the '70's... I spent a lot of time reading that code...) The next few slots would be filled with various generics issues... :=) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
The imports is the whole issue. I was not aware of stub classes but my
initial googling shows me it's some kind of remote object and that sure
doesn't sound fast. Anyway thank you for the point and I will look into it.
I for one don't leave anything up to a C compiler when it comes to a hot
spot so there is no way I am putting my life in the hands of a JIT. I
think part of the issue could be the type of projects being written.
For an app that is mainly data entry and isn't constantly requiring
every last cycle from the CPU then I would rather use interfaces or
maybe even these stubs but not for a real-time game.
Every single game project I have worked has had math functions that are
conditionally compiled based on platform.
On 8/3/2010 9:55 PM, dm1973 wrote:
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
--
Leigh McRae
www.lonedwarfgames.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
As I said in my example, I don't want to pay an extra function call when
the code is in a hot spot. Even if the code isn't in a hot spot there
is a much worse case to deal with and that is death by a thousand cuts.
If a real-time game on a phone was written with all these interfaces to
make the Java gods happy then you would have a big problem trying to
fix. Then you would be calling out to the C gods for a preprocessor.
On 8/3/2010 10:01 PM, Bob Kerns wrote:
To take this a bit further: Platform can be an Enum, that implements
an IPlatform interface, and you can attach methods to BLACKBERRY and
friends to do the platform-specific stuff.
Then this becomes:
Platform.OS.doStuff();
And you don't have to touch it when you add a new platform.
On Aug 3, 6:55 pm, dm1973david050...@gmail.com wrote:
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
On Aug 3, 1:39 pm, Leigh McRaeleigh.mc...@lonedwarfgames.com wrote:
On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to list
the faults of the C language, the
preprocessor is very near the top.
Just your opinion.
That's why C++ went to great lengths to mostly remove the need for
using it, with inline functions, constants, and the like.
Now your just talking specifically about macros which still can be
useful and there are somethings that can only be done using a macro. It's too
bad they didn't remove it. It causes all kinds of difficulty
for tools. The tools for Java are generally far better than for C++ --
and the lack of a preprocessor to screw up and ambiguate the
interpretation of any piece of syntax you look at, is a huge part of
the reason.
MS tools destroy what Java has to offer IMHO. Only the re-factoring is
better for Java. It's all opinion either way.
I think you have to realize that preprocesing is just a tool and isn't
to be used to solve all problems. Just because I want a hammer doesn't
mean I regard every issue as being a nail. It's very appropriate to
handle cross platform issues, hardware issue, diagnostic code etc. All
of these issues are very relevant to Android. Sure these issues might
be handled differently for a desktop solution where resources aren't as
big of an issue.
Why force everyone to do it the so called right way? Why does C# have
conditional compile? Just because SUN chose not to support
preprocessing in javac doesn't mean they aren't behind it. Maybe they
chose to support it through tools so that j2me code would still work
with j2se? That would make a lot of sense to me. For something they
aren't behind they sure put a lot of effort into it.
It's also a major compilation performance hit. With a significant
amount of pain, you can get Visual Studio to avoid a lot of the
reparsing it requires, but the language basically says that to compile
any particular program file, you have to parse all the #includes,
recursively, processing the same file over and over and over again --
possibly differently each and every time, because INTEGER may mean int
in one case, unsigned int in another, and unsigned long long in yet
another.
And that's a problem for programmers, too. No, I don't mean a problem
for me, that a good C++ programmer knows how to avoid the problems. I
mean its a problem I've had to help MANY experienced C++ programmers
resolve time and time again -- often in vendor-supplied code, rather
than their own. Or when two different vendor's include files conflict
-- or one vendor's include files conflict with their own.
My long experience is that every time someone tells me they need a
preprocessor -- there turns out to be a better way. Sometimes you
replace that with code generation -- but most of the time, code
generation isn't the ultimate solution, either. Often, proper use of
introspection and metadata (the annotation facility, for example)
provide a superior (more robust, more compact, and more maintainable)
solution.
Solve this one for me. BlackBerry has a version of atan2 that is
fixed-point and is much faster that the Math.atan2. How can I take
advantage of this without an interface or an
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On 8/3/2010 11:23 PM, Bob Kerns wrote: You have a very limited view of the techniques available. For Java that could be true but my C/C++ fu is just fine thank you. On Aug 3, 10:39 am, Leigh McRaeleigh.mc...@lonedwarfgames.com wrote: On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to list the faults of the C language, the preprocessor is very near the top. Just your opinion. False: Preprocessor usage should be eliminated. -Bjarne Stroustrup, An Overview of the C++ Programming Language, page 3, under table Language-technical rules: This concept carried over into the C++ standard committee. Hardly just my opinion. It's not removed, because C compatibility is a higher-priority concern. Not false, just your and Stroustrup's opinions. To be fair there are likely a ton of others that agree just as there are a ton that are happy to have them WHEN they need them. Just because Stroustrup is the father of C++ doesn't mean he is law. Lots of people are still pissed about multi-inheritance but just like the preprocessor it's a tool and people should get over it and either use or don't use it. Also Dennis Ritchie has a longer beard than Stroustrup so that trumpts it :) That's why C++ went to great lengths to mostly remove the need for using it, with inline functions, constants, and the like. Now your just talking specifically about macros which still can be useful and there are somethings that can only be done using a macro. No, I am not. I have nothing against macros -- on the contrary, I met my wife teaching a class on macros. Preprocessors are not the place for them. Lots of languages have macros without preprocessors. Macros are great! I wish Java had them. Me too! So why not just throw in some very simple preroccessing instructions into the mix and make it happen :) (They do have their drawbacks, but no on the scale of a preprocessor. And the power of any macros I'd envision is substantially more than is offered by the C/C++ preprocessor). MS tools destroy what Java has to offer IMHO. Only the re-factoring is better for Java. It's all opinion either way. Are you comparing MS C++ tools to Java tools, or C# and friends? Anyway, it's not all opinion. Such comparisons can be done quite objectively. Which tools you prefer to USE is opinion. I think you have to realize that preprocesing is just a tool and isn't to be used to solve all problems. Just because I want a hammer doesn't mean I regard every issue as being a nail. It's very appropriate to handle cross platform issues, hardware issue, diagnostic code etc. All of these issues are very relevant to Android. Sure these issues might be handled differently for a desktop solution where resources aren't as big of an issue. Nobody has shown me a case where you need a preprocessor because of resource issues. Can use, yes, but need, no. Actually I just showed two real world examples and all answers just skirted around the issue and ignored the performance hit. It is HIGHLY INAPPROPRIATE to handle platform issues and hardware issues -- it makes porting to a new platform a royal nightmare. Your best shot there is diagnostic code -- and there are better ways, involving post-processors rather than preprocessors. Why force everyone to do it the so called right way? Because of the cost to everyone else of the feature you are demanding. Why not put in every hair-brained feature anyone thinks they'd like to use? It's not hair brained. Just more opinion. Because LONG experience shows, that approach makes for major problems with languages, and makes them harder to use. Trust me -- that approach has had its day in the language-design world. Even a poorly- designed API, not part of the language, can have a major adverse impact on the maintainability of a product. I have a good chunk of experience also thank you and I would rather ship than sit around looking for that golden band-aid that will make me feel all warm an fuzzy. And in extreme cases (but only extreme cases), even personal code- formatting idiosyncrasies can have a negative impact. Let people do whatever they want has, after decades of experience, been found to not be a good idea. A more careful balance must be sought. Why does C# have conditional compile? To accommodate the masses of C programmers that Microsoft wanted to attract, of course! I would have thought C# was to compete with Java and fix main of the things that Java got wrong. Don't get me wrong, I am surprised actually how little I hate Java. Just because SUN chose not to support preprocessing in javac doesn't mean they aren't behind it. Maybe they chose to support it through tools so that j2me code would still work with j2se? That would make a lot of sense to me. For something they aren't behind they sure put a lot of effort into it. Or maybe
[android-developers] Re: Android preprocessor, //#ifdef...
I for one don't leave anything up to a C compiler when it comes to a
hot spot so there is no way I am putting my life in the hands of a
JIT.
Then you should quit working with Android and go back to Windows.
Android will be using a JIT soon enough, probably in the next major
turn of the crank.
A good JIT can do a far better job of optimizing performance than you
can in C.
On Aug 4, 8:27 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote:
The imports is the whole issue. I was not aware of stub classes but my
initial googling shows me it's some kind of remote object and that sure
doesn't sound fast. Anyway thank you for the point and I will look into it.
I for one don't leave anything up to a C compiler when it comes to a hot
spot so there is no way I am putting my life in the hands of a JIT. I
think part of the issue could be the type of projects being written.
For an app that is mainly data entry and isn't constantly requiring
every last cycle from the CPU then I would rather use interfaces or
maybe even these stubs but not for a real-time game.
Every single game project I have worked has had math functions that are
conditionally compiled based on platform.
On 8/3/2010 9:55 PM, dm1973 wrote:
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
--
Leigh McRaewww.lonedwarfgames.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
On Aug 4, 6:56 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote:
On 8/3/2010 11:23 PM, Bob Kerns wrote: You have a very limited view of the
techniques available.
For Java that could be true but my C/C++ fu is just fine thank you.
I can't see that I said anything about your C/C++ fu. Seems we were
discussing Java. You might possibly generalize that to languages in
general, but not back-narrow it to C/C++.
On Aug 3, 10:39 am, Leigh McRaeleigh.mc...@lonedwarfgames.com
wrote:
On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to
list the faults of the C language, the
preprocessor is very near the top.
Just your opinion.
False:
Preprocessor usage should be eliminated.
-Bjarne Stroustrup, An Overview of the C++ Programming Language,
page 3, under table Language-technical rules:
This concept carried over into the C++ standard committee. Hardly
just my opinion. It's not removed, because C compatibility is a
higher-priority concern.
Not false, just your and Stroustrup's opinions. To be fair there are
likely a ton of others that agree just as there are a ton that are happy
to have them WHEN they need them. Just because Stroustrup is the father
of C++ doesn't mean he is law. Lots of people are still pissed about
multi-inheritance but just like the preprocessor it's a tool and people
should get over it and either use or don't use it. Also Dennis Ritchie
has a longer beard than Stroustrup so that trumpts it :)
Mine's pretty long, too. But you missed the point. I wasn't just
citing an opinion. I was citing the rationale for why C++ strove to
minimize dependence on the pre-processor, from a list of faults of the
C language they wanted to address.
Me too! So why not just throw in some very simple preroccessing
instructions into the mix and make it happen :)
Because C/C++ preprocessing messes everything up, including (or
especially) macros.
Let me make that a bit more clear. It's not the fact of a pre-
processing step being involved that is the problem.
It is more specifically that C/C++ preprocessing is completely
decoupled from the language syntax. It's that you have to preprocess
to even know whether you have valid syntax or not. It is #ifdef and
the lousy C++ macros that are the problem.
Otherwise, you could just regard macros are part of the language
syntax (as in most any other language macros), and regard the
preprocess step as merely being the first compilation phase.
If you people would stop arguing for specifically C/C++ preprocessor,
and argue for a restrained-and-sane macro facility instead, I think
you'd get a lot further.
For example, you could ask for something like:
if (__compile_time(OS == OS_BLACKBERRY)) {
result = funny_atan2(b, a);
} else {
result = Math.atan2(a, b);
}
which has none of the problems we are discussing.
Nor does:
if (OS == OS_BLACKBERRY) {
@CompileTime
result = funny_atan2(b, a);
} else {
result = Math.atan2(a, b);
}
The compiler can be required to ignore the failing conditional in
either case, and you have exactly the same result as the C/C++
preprocessor, without the headaches.
But for some reason, you people never ask for that. And I've never
thought to point that out before. Strange -- on both sides.
(I hope it's clear that you people is self-defining here as C/C++
people who expect Java to have a preprocessor -- just like C/C++).
Actually I just showed two real world examples and all answers just
skirted around the issue and ignored the performance hit.
Apparently you did not understand my responses. My solutions had ZERO,
yes ZERO performance hit -- resulting in exactly the same sequence of
instructions as your preprocessor would produce. Same result,
different approach. No need to preprocess in Java when there are other
techniques available.
I am not arguing that Java could not be improved. I was offering
solutions with the Java we have today, and tools that exist today
(sometimes in awkward form, that might require some programming on
your part, and extra effort to integrate into the IDE and/or build).
Because of the cost to everyone else of the feature you are demanding.
Why not put in every hair-brained feature anyone thinks they'd like to
use?
It's not hair brained. Just more opinion.
Please read more carefully. I did not call your feature hair-brained.
(It's hair-brained. OK, now I did).
I offered an reductio ad adsurdum argument against the strategy of
putting in everything people ask for just because they want them.
I would have thought C# was to compete with Java and fix main of the
things that Java got wrong. Don't get me wrong, I am surprised
actually how little I hate Java.
Yes, quite right. And one of the things they viewed as wrong was
that C/C++ programmers didn't like it for various comfort reasons, so
they made it more C/C++-like. And then to keep the Java folks happy,
they made a Java-like version, too.
I
[android-developers] Re: Android preprocessor, //#ifdef...
Your initial googling has led you astray. Ignore any reference you find that is discussing stub classes in the context of remote objects; that is a specialized use of the term, and not relevant to your search. It's not a Java term, BTW. The technique can be used in any language with classes. I've used it in C++ for exactly this purpose. And actually, the imports are not the issue at all. You've made it very clear that the issue is the runtime performance. Imports are a compile-time concern. On Aug 4, 6:27 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: The imports is the whole issue. I was not aware of stub classes but my initial googling shows me it's some kind of remote object and that sure doesn't sound fast. Anyway thank you for the point and I will look into it. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On 8/4/2010 1:02 PM, Bob Kerns wrote:
Mine's pretty long, too. But you missed the point. I wasn't just
citing an opinion. I was citing the rationale for why C++ strove to
minimize dependence on the pre-processor, from a list of faults of the
C language they wanted to address.
Me too! So why not just throw in some very simple preroccessing
instructions into the mix and make it happen :)
Because C/C++ preprocessing messes everything up, including (or
especially) macros.
Let me make that a bit more clear. It's not the fact of a pre-
processing step being involved that is the problem.
It is more specifically that C/C++ preprocessing is completely
decoupled from the language syntax. It's that you have to preprocess
to even know whether you have valid syntax or not. It is #ifdef and
the lousy C++ macros that are the problem.
Otherwise, you could just regard macros are part of the language
syntax (as in most any other language macros), and regard the
preprocess step as merely being the first compilation phase.
If you people would stop arguing for specifically C/C++ preprocessor,
and argue for a restrained-and-sane macro facility instead, I think
you'd get a lot further.
For example, you could ask for something like:
if (__compile_time(OS == OS_BLACKBERRY)) {
result = funny_atan2(b, a);
} else {
result = Math.atan2(a, b);
}
which has none of the problems we are discussing.
Nor does:
if (OS == OS_BLACKBERRY) {
@CompileTime
result = funny_atan2(b, a);
} else {
result = Math.atan2(a, b);
}
The compiler can be required to ignore the failing conditional in
either case, and you have exactly the same result as the C/C++
preprocessor, without the headaches.
But for some reason, you people never ask for that. And I've never
thought to point that out before. Strange -- on both sides.
(I hope it's clear that you people is self-defining here as C/C++
people who expect Java to have a preprocessor -- just like C/C++).
I am only talking about Java/j2me and how it's to be used in an
embedded system like a phone. With that said it's far more reasonable
to ask for a simple tool that can be integrated without having to change
anyone's code than to try and change a language. I don't even care care
to debate j2se/ee as I am only using Java because that's what BlackBerry
and Android use.
Oddly enough I was just looking around the android-os code trying to
figure out some opengl stuff and it's riddled with conditional
compiles. Silly rabbits, preprocessing is for kids. Can't they figure
out some golden abstract generic templated foo to fix that?
Actually I just showed two real world examples and all answers just
skirted around the issue and ignored the performance hit.
Apparently you did not understand my responses. My solutions had ZERO,
yes ZERO performance hit -- resulting in exactly the same sequence of
instructions as your preprocessor would produce. Same result,
different approach. No need to preprocess in Java when there are other
techniques available.
I am all for a solution. As far as I can see your enum isn't really and
different than an object with a method call. Plus you still haven't
solved the import issue. On top of that there is more code to
maintain. Sure you can use code generation, which preprocessing is, but
it makes working with the code much harder in eclipse. The preprocessed
solution is 100% guaranteed to cost nothing extra and solves the import
in one shot.
I am not arguing that Java could not be improved. I was offering
solutions with the Java we have today, and tools that exist today
(sometimes in awkward form, that might require some programming on
your part, and extra effort to integrate into the IDE and/or build).
Because of the cost to everyone else of the feature you are demanding.
Why not put in every hair-brained feature anyone thinks they'd like to
use?
It's not hair brained. Just more opinion.
Please read more carefully. I did not call your feature hair-brained.
(It's hair-brained. OK, now I did).
Nice.
I offered an reductio ad adsurdum argument against the strategy of
putting in everything people ask for just because they want them.
I would have thought C# was to compete with Java and fix main of the
things that Java got wrong. Don't get me wrong, I am surprised
actually how little I hate Java.
Yes, quite right. And one of the things they viewed as wrong was
that C/C++ programmers didn't like it for various comfort reasons, so
they made it more C/C++-like. And then to keep the Java folks happy,
they made a Java-like version, too.
I don't hate C#, though I am not sure the world needed another
language or two. The main drawback is that it's proprietary, coupled
to a proprietary API. I haven't targeted that API much since it came
out, but I'm very happy they came up with an alternative to C++ for
targeting that API.
And there is
[android-developers] Re: Android preprocessor, //#ifdef...
Android will generate an Ant build.xml which is fairly easily extended, and the NetBeans Mobility Ant Extensions will run fine outside of NetBeans. So you could insert a target that uses the NetBeans preprocessor to nb- prep the sources prior to compiling. http://wiki.netbeans.org/MobilityAntExtensions So far, however, it hasn't generally been worth the trouble because Android is not as splintered (yet) as J2ME. On Jul 31, 8:25 am, sblantipodi perini.dav...@dpsoftware.org wrote: Hi all, I noticed that there is no way to use preprocessor in android with netbeans using the //#ifdef syntax, is there some sort of preprocessing in eclipse using android? I haven't understood if this is a lack of netbeans or it is a lack of android. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
So much to say about Java except that's just talking religion. So back to the original topic. Sometimes just because you are adding in debug code doesn't mean you want a performance degradation. Java has mechanisms for some of this but just for example, tracing. Doesn't matter what you are tracing/tracking, if you are storing some sort of ownership for easy of debugging, you might just want this is production. Especially, 1.0 products that tend to have many more deficiencies. Whether that fits RichardC's reasons is another story. While not specific to Java, I've had enough failures between xml generation, aidl, etc., that there always seems to be preprocessing of some sort whether it got included in a language or not. Cheers On Aug 3, 10:10 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: I object to the fact the people who write Java are real programmers... Sorry, couldn't help myself, likely should hit send, oh well. On 8/3/2010 1:30 AM, Frank Weiss wrote: This thread is a little like schadenfreude to me. A lot of it is about taste - of which arguing about is of little use. I just saw some Java code where every closing brace is commented with // end of if, // end of for, // end of method, etc. Yech!. That, to me, is worth arguing about! If the OP wants to use preprocessor, nothing's stopping them. Indeed, as Bob Kearns points out, Android SDK generates R.java from several XML files, which is pretty darn close to what a preprocessor does. Would it be that hard for the determined developer to add a preprocessor hook into the SDK build script - even on Eclipse? Come on folks, this is open source code! Even Atlassian lets you modify the Jira and Confluence source code! My $0.02 is that even if javac did have a preprocessor, few real Java programmers would deign to use it. Nonetheless, I'm sure there are a few cases where a preprocessor is Just The Right Way To Program. -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
On Aug 3, 1:39 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote:
On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to list
the faults of the C language, the
preprocessor is very near the top.
Just your opinion.
That's why C++ went to great lengths to mostly remove the need for
using it, with inline functions, constants, and the like.
Now your just talking specifically about macros which still can be
useful and there are somethings that can only be done using a macro. It's
too bad they didn't remove it. It causes all kinds of difficulty
for tools. The tools for Java are generally far better than for C++ --
and the lack of a preprocessor to screw up and ambiguate the
interpretation of any piece of syntax you look at, is a huge part of
the reason.
MS tools destroy what Java has to offer IMHO. Only the re-factoring is
better for Java. It's all opinion either way.
I think you have to realize that preprocesing is just a tool and isn't
to be used to solve all problems. Just because I want a hammer doesn't
mean I regard every issue as being a nail. It's very appropriate to
handle cross platform issues, hardware issue, diagnostic code etc. All
of these issues are very relevant to Android. Sure these issues might
be handled differently for a desktop solution where resources aren't as
big of an issue.
Why force everyone to do it the so called right way? Why does C# have
conditional compile? Just because SUN chose not to support
preprocessing in javac doesn't mean they aren't behind it. Maybe they
chose to support it through tools so that j2me code would still work
with j2se? That would make a lot of sense to me. For something they
aren't behind they sure put a lot of effort into it.
It's also a major compilation performance hit. With a significant
amount of pain, you can get Visual Studio to avoid a lot of the
reparsing it requires, but the language basically says that to compile
any particular program file, you have to parse all the #includes,
recursively, processing the same file over and over and over again --
possibly differently each and every time, because INTEGER may mean int
in one case, unsigned int in another, and unsigned long long in yet
another.
And that's a problem for programmers, too. No, I don't mean a problem
for me, that a good C++ programmer knows how to avoid the problems. I
mean its a problem I've had to help MANY experienced C++ programmers
resolve time and time again -- often in vendor-supplied code, rather
than their own. Or when two different vendor's include files conflict
-- or one vendor's include files conflict with their own.
My long experience is that every time someone tells me they need a
preprocessor -- there turns out to be a better way. Sometimes you
replace that with code generation -- but most of the time, code
generation isn't the ultimate solution, either. Often, proper use of
introspection and metadata (the annotation facility, for example)
provide a superior (more robust, more compact, and more maintainable)
solution.
Solve this one for me. BlackBerry has a version of atan2 that is
fixed-point and is much faster that the Math.atan2. How can I take
advantage of this without an interface or an extra function call?
public static final float VecToHeading( float x, float y )
{
//#if PLATFORM_BLACKBERRY
float fAngle = ((float)Fixed32.atand2( (int)(x * 65536.0f),
(int)(y * 65536.0f) )) / 65536.0f;
//#else
//@ float fAngle = ((float)Math.atan2( x, y )) *
57.295779513082320876798154814105f;
//#endif
if ( fAngle 0.0f )
return fAngle + 360.0f;
return fAngle;
}
Here is another one. The math function is in two different packages.
//#if PLATFORM_BLACKBERRY
omega = (float)net.rim.device.api.util.MathUtilities.acos( cosom );
//#else
//@ omega = (float)java.lang.Math.acos( cosom );
//#endif
And that includes the use here -- of selecting what code to run. For
that, often the solution lies in correct modularity of the program.
Trust me -- littering your code with conditionals does
[android-developers] Re: Android preprocessor, //#ifdef...
To take this a bit further: Platform can be an Enum, that implements
an IPlatform interface, and you can attach methods to BLACKBERRY and
friends to do the platform-specific stuff.
Then this becomes:
Platform.OS.doStuff();
And you don't have to touch it when you add a new platform.
On Aug 3, 6:55 pm, dm1973 david050...@gmail.com wrote:
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
On Aug 3, 1:39 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote:
On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to list
the faults of the C language, the
preprocessor is very near the top.
Just your opinion.
That's why C++ went to great lengths to mostly remove the need for
using it, with inline functions, constants, and the like.
Now your just talking specifically about macros which still can be
useful and there are somethings that can only be done using a macro. It's
too bad they didn't remove it. It causes all kinds of difficulty
for tools. The tools for Java are generally far better than for C++ --
and the lack of a preprocessor to screw up and ambiguate the
interpretation of any piece of syntax you look at, is a huge part of
the reason.
MS tools destroy what Java has to offer IMHO. Only the re-factoring is
better for Java. It's all opinion either way.
I think you have to realize that preprocesing is just a tool and isn't
to be used to solve all problems. Just because I want a hammer doesn't
mean I regard every issue as being a nail. It's very appropriate to
handle cross platform issues, hardware issue, diagnostic code etc. All
of these issues are very relevant to Android. Sure these issues might
be handled differently for a desktop solution where resources aren't as
big of an issue.
Why force everyone to do it the so called right way? Why does C# have
conditional compile? Just because SUN chose not to support
preprocessing in javac doesn't mean they aren't behind it. Maybe they
chose to support it through tools so that j2me code would still work
with j2se? That would make a lot of sense to me. For something they
aren't behind they sure put a lot of effort into it.
It's also a major compilation performance hit. With a significant
amount of pain, you can get Visual Studio to avoid a lot of the
reparsing it requires, but the language basically says that to compile
any particular program file, you have to parse all the #includes,
recursively, processing the same file over and over and over again --
possibly differently each and every time, because INTEGER may mean int
in one case, unsigned int in another, and unsigned long long in yet
another.
And that's a problem for programmers, too. No, I don't mean a problem
for me, that a good C++ programmer knows how to avoid the problems. I
mean its a problem I've had to help MANY experienced C++ programmers
resolve time and time again -- often in vendor-supplied code, rather
than their own. Or when two different vendor's include files conflict
-- or one vendor's include files conflict with their own.
My long experience is that every time someone tells me they need a
preprocessor -- there turns out to be a better way. Sometimes you
replace that with code generation -- but most of the time, code
generation isn't the ultimate solution, either. Often, proper use of
introspection and metadata (the annotation facility, for example)
provide a superior (more robust, more compact, and more maintainable)
solution.
Solve this one for me. BlackBerry has a version of atan2 that is
fixed-point and is much faster that the Math.atan2. How can I take
advantage of this without an interface or an extra function call?
public static final float VecToHeading( float x, float y )
{
//#if PLATFORM_BLACKBERRY
float fAngle = ((float)Fixed32.atand2( (int)(x * 65536.0f),
(int)(y * 65536.0f) )) / 65536.0f;
//#else
//@ float fAngle = ((float)Math.atan2( x, y )) *
57.295779513082320876798154814105f;
//#endif
if ( fAngle 0.0f )
return fAngle + 360.0f;
return fAngle;
}
Here is another one. The math function
[android-developers] Re: Android preprocessor, //#ifdef...
Well, perhaps this illustrates your second point, but: http://tinyurl.com/sun-concurrent-gc Or it may be that they're not concurrent enough for you. Concurrency isn't an absolute, and there are various ways of describing the upper bounds on how much delay a concurrent algorithm can impose on other threads. (Your point about stringent response time requirements suggests this may be your issue with calling it concurrent). GC benchmarking is hard work and tricky, and I haven't done it in a long time. I appreciate the anecdotal data; do you have benchmarks behind it? You've aroused my curiosity about the current state. I have generally been more concerned with compatibility in huge code bases rather than performance differences (which can generally be overcome with hardware -- not concurrency, though), so I've mostly avoided non-Sun JVMs when possible. But I like that there are alternatives of increasing quality. Especially given recent corporate history... Thanks. On Aug 3, 6:07 am, DanH danhi...@ieee.org wrote: Well, none of Sun's implementations are concurrent -- they all force the application to stop for a time. They're not generally well- designed for LARGE applications (eg, a fast 8-way running a heavy transaction system), or anything with really stringent response time requirements. The IBM iSeries Java implementation ran rings around Sun's, and the newer IBM portable Java implementation runs rings around the iSeries implementation. One of the problems with Sun's GC scheme is the vast number of parameters -- no one understands them, or how to set them for a given set of circumstances (especially if those circumstances vary dynamically). On Aug 2, 9:57 pm, Bob Kerns r...@acm.org wrote: OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to
[android-developers] Re: Android preprocessor, //#ifdef...
You have a very limited view of the techniques available. On Aug 3, 10:39 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to list the faults of the C language, the preprocessor is very near the top. Just your opinion. False: Preprocessor usage should be eliminated. -Bjarne Stroustrup, An Overview of the C++ Programming Language, page 3, under table Language-technical rules: This concept carried over into the C++ standard committee. Hardly just my opinion. It's not removed, because C compatibility is a higher-priority concern. That's why C++ went to great lengths to mostly remove the need for using it, with inline functions, constants, and the like. Now your just talking specifically about macros which still can be useful and there are somethings that can only be done using a macro. No, I am not. I have nothing against macros -- on the contrary, I met my wife teaching a class on macros. Preprocessors are not the place for them. Lots of languages have macros without preprocessors. Macros are great! I wish Java had them. (They do have their drawbacks, but no on the scale of a preprocessor. And the power of any macros I'd envision is substantially more than is offered by the C/C++ preprocessor). MS tools destroy what Java has to offer IMHO. Only the re-factoring is better for Java. It's all opinion either way. Are you comparing MS C++ tools to Java tools, or C# and friends? Anyway, it's not all opinion. Such comparisons can be done quite objectively. Which tools you prefer to USE is opinion. I think you have to realize that preprocesing is just a tool and isn't to be used to solve all problems. Just because I want a hammer doesn't mean I regard every issue as being a nail. It's very appropriate to handle cross platform issues, hardware issue, diagnostic code etc. All of these issues are very relevant to Android. Sure these issues might be handled differently for a desktop solution where resources aren't as big of an issue. Nobody has shown me a case where you need a preprocessor because of resource issues. Can use, yes, but need, no. It is HIGHLY INAPPROPRIATE to handle platform issues and hardware issues -- it makes porting to a new platform a royal nightmare. Your best shot there is diagnostic code -- and there are better ways, involving post-processors rather than preprocessors. Why force everyone to do it the so called right way? Because of the cost to everyone else of the feature you are demanding. Why not put in every hair-brained feature anyone thinks they'd like to use? Because LONG experience shows, that approach makes for major problems with languages, and makes them harder to use. Trust me -- that approach has had its day in the language-design world. Even a poorly- designed API, not part of the language, can have a major adverse impact on the maintainability of a product. And in extreme cases (but only extreme cases), even personal code- formatting idiosyncrasies can have a negative impact. Let people do whatever they want has, after decades of experience, been found to not be a good idea. A more careful balance must be sought. Why does C# have conditional compile? To accommodate the masses of C programmers that Microsoft wanted to attract, of course! Just because SUN chose not to support preprocessing in javac doesn't mean they aren't behind it. Maybe they chose to support it through tools so that j2me code would still work with j2se? That would make a lot of sense to me. For something they aren't behind they sure put a lot of effort into it. Or maybe they wanted to attract all those C programmers who are used to solving every problem with a #ifdef, and aren't willing to update their approach? Or maybe because the J2ME people actually WERE former C programmers. Language purity is not the only design constraint. Soustroup makes that point himself. Sometimes you make compromises for acceptance. Computer languages are partly human languages, and human languages are a cultural artifact that change slowly. It's also a major compilation performance hit. With a significant amount of pain, you can get Visual Studio to avoid a lot of the reparsing it requires, but the language basically says that to compile any particular program file, you have to parse all the #includes, recursively, processing the same file over and over and over again -- possibly differently each and every time, because INTEGER may mean int in one case, unsigned int in another, and unsigned long long in yet another. And that's a problem for programmers, too. No, I don't mean a problem for me, that a good C++ programmer knows how to avoid the problems. I mean its a problem I've had to help MANY experienced C++ programmers resolve time and time again -- often in vendor-supplied code, rather than their own. Or when two different vendor's include files conflict -- or
[android-developers] Re: Android preprocessor, //#ifdef...
Notice that they call it low pause, not pause free. There are truly pause-free algorithms, and people who need them. Brokerage systems, eg, need response in the 10s of milliseconds, and a single GC can disrupt a thousand transactions. iSeries had the SPECjbb crown for several years running, first with its own JVM and then with the IBM J9 portable JVM. Was finally displaced by J9 running on other hardware (as the iSeries hardware was getting out of date). Sun did eventually build a special IBM killer box to reclaim the crown by throwing hundreds of processors at the problem (and building hundreds of tuning parameters into the JVM), but it was an artificial configuration. On Aug 3, 9:12 pm, Bob Kerns r...@acm.org wrote: Well, perhaps this illustrates your second point, but: http://tinyurl.com/sun-concurrent-gc Or it may be that they're not concurrent enough for you. Concurrency isn't an absolute, and there are various ways of describing the upper bounds on how much delay a concurrent algorithm can impose on other threads. (Your point about stringent response time requirements suggests this may be your issue with calling it concurrent). GC benchmarking is hard work and tricky, and I haven't done it in a long time. I appreciate the anecdotal data; do you have benchmarks behind it? You've aroused my curiosity about the current state. I have generally been more concerned with compatibility in huge code bases rather than performance differences (which can generally be overcome with hardware -- not concurrency, though), so I've mostly avoided non-Sun JVMs when possible. But I like that there are alternatives of increasing quality. Especially given recent corporate history... Thanks. On Aug 3, 6:07 am, DanH danhi...@ieee.org wrote: Well, none of Sun's implementations are concurrent -- they all force the application to stop for a time. They're not generally well- designed for LARGE applications (eg, a fast 8-way running a heavy transaction system), or anything with really stringent response time requirements. The IBM iSeries Java implementation ran rings around Sun's, and the newer IBM portable Java implementation runs rings around the iSeries implementation. One of the problems with Sun's GC scheme is the vast number of parameters -- no one understands them, or how to set them for a given set of circumstances (especially if those circumstances vary dynamically). On Aug 2, 9:57 pm, Bob Kerns r...@acm.org wrote: OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me
[android-developers] Re: Android preprocessor, //#ifdef...
Just a few bullet points: -- I've always thought that C #include processing sucked. Why did they never introduce an #includeonce directive that would have eliminated all the #ifndef stuff to prevent double includes?? -- C macros suck. They obfuscate without really introducing much capability. I've worked on languages that had macros that were their own language -- you could have real variables in them, loop, do most normal programming things. Code was generated via emit statements. With such a macro language you can do some amazing things, and with reasonable use (always a problem, I know) the macros served to clarify rather than obfuscate. -- Post-processing of Java bytecodes is expensive and error-prone, and again obscures the logic. Not that cost should be a criteria, but post-processing is no panacea. -- Yes, one should have to cost-justify including a line-number pseudo-function in javac. But there are a hundred features of Java that don't seem to me to be cost-justified, and several hundred other missing functions that ARE cost-justified. I never have figured out how Sun decided what went into Java and what didn't (though in several cases it appears to have depended on what would hide the deficiencies in their implementation vs expose them). On Aug 3, 10:23 pm, Bob Kerns r...@acm.org wrote: You have a very limited view of the techniques available. On Aug 3, 10:39 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/2/2010 10:49 PM, Bob Kerns wrote: First of all -- if you want to list the faults of the C language, the preprocessor is very near the top. Just your opinion. False: Preprocessor usage should be eliminated. -Bjarne Stroustrup, An Overview of the C++ Programming Language, page 3, under table Language-technical rules: This concept carried over into the C++ standard committee. Hardly just my opinion. It's not removed, because C compatibility is a higher-priority concern. That's why C++ went to great lengths to mostly remove the need for using it, with inline functions, constants, and the like. Now your just talking specifically about macros which still can be useful and there are somethings that can only be done using a macro. No, I am not. I have nothing against macros -- on the contrary, I met my wife teaching a class on macros. Preprocessors are not the place for them. Lots of languages have macros without preprocessors. Macros are great! I wish Java had them. (They do have their drawbacks, but no on the scale of a preprocessor. And the power of any macros I'd envision is substantially more than is offered by the C/C++ preprocessor). MS tools destroy what Java has to offer IMHO. Only the re-factoring is better for Java. It's all opinion either way. Are you comparing MS C++ tools to Java tools, or C# and friends? Anyway, it's not all opinion. Such comparisons can be done quite objectively. Which tools you prefer to USE is opinion. I think you have to realize that preprocesing is just a tool and isn't to be used to solve all problems. Just because I want a hammer doesn't mean I regard every issue as being a nail. It's very appropriate to handle cross platform issues, hardware issue, diagnostic code etc. All of these issues are very relevant to Android. Sure these issues might be handled differently for a desktop solution where resources aren't as big of an issue. Nobody has shown me a case where you need a preprocessor because of resource issues. Can use, yes, but need, no. It is HIGHLY INAPPROPRIATE to handle platform issues and hardware issues -- it makes porting to a new platform a royal nightmare. Your best shot there is diagnostic code -- and there are better ways, involving post-processors rather than preprocessors. Why force everyone to do it the so called right way? Because of the cost to everyone else of the feature you are demanding. Why not put in every hair-brained feature anyone thinks they'd like to use? Because LONG experience shows, that approach makes for major problems with languages, and makes them harder to use. Trust me -- that approach has had its day in the language-design world. Even a poorly- designed API, not part of the language, can have a major adverse impact on the maintainability of a product. And in extreme cases (but only extreme cases), even personal code- formatting idiosyncrasies can have a negative impact. Let people do whatever they want has, after decades of experience, been found to not be a good idea. A more careful balance must be sought. Why does C# have conditional compile? To accommodate the masses of C programmers that Microsoft wanted to attract, of course! Just because SUN chose not to support preprocessing in javac doesn't mean they aren't behind it. Maybe they chose to support it through tools so that j2me code would still work with j2se? That would make a lot of sense to me. For something they
[android-developers] Re: Android preprocessor, //#ifdef...
On Aug 2, 10:30 pm, Frank Weiss fewe...@gmail.com wrote: This thread is a little like schadenfreude to me. A lot of it is about taste - of which arguing about is of little use. I just saw some Java code where every closing brace is commented with // end of if, // end of for, // end of method, etc. Yech!. That, to me, is worth arguing about! Nah, I prefer this topic. I can kill that one in 30 seconds in Emacs. :=) Or give me a minute, and I could probably get 'find' and 'sed' to do it on an entire tree. Then just teach them to use an editor other than Notepad.exe. Would it be that hard for the determined developer to add a preprocessor hook into the SDK build script - even on Eclipse? Come on folks, this is open source code! Even Atlassian lets you modify the Jira and Confluence source code! It is not hard at all. No need for source code. The techniques aren't even Android-specific. In fact, they'll even work on your NDK C++ code. My $0.02 is that even if javac did have a preprocessor, few real Java programmers would deign to use it. Nonetheless, I'm sure there are a few cases where a preprocessor is Just The Right Way To Program. I don't claim otherwise -- just that in nearly 15 intensive years of Java programming, one has never been demonstrated to me. I don't expect to find one, either, because code generation is a more powerful technique, that allows you to tailor the solution to your problem. Many of the supposed needs that have been presented to my have fallen to code generation as a superior alternative. I'll also add that Java provides an alternative that C++ does not make easy -- post-processing. While it's possible to post-process C/C++, it's no longer in a platform-independent form. Post-processing Java class files is quite feasible. And Android makes use of the technique, in fact, to target a completely different VM with a totally different architecture. A related technique is direct generation of the .class files. Still another is generation of the classes directly at run time -- I have made use of this technique myself. It won't work in Android because it doesn't directly execute .class files, but the technique works quite well. And there's also code that post-process class files at load time. Say, post-processing would work for inserting __LINE__ and __FILE__ and __METHOD and __CLASS values with no runtime method calls! The information is available, so long as it's not been turned off, or removed in a post-processing step. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Well, none of Sun's implementations are concurrent -- they all force the application to stop for a time. They're not generally well- designed for LARGE applications (eg, a fast 8-way running a heavy transaction system), or anything with really stringent response time requirements. The IBM iSeries Java implementation ran rings around Sun's, and the newer IBM portable Java implementation runs rings around the iSeries implementation. One of the problems with Sun's GC scheme is the vast number of parameters -- no one understands them, or how to set them for a given set of circumstances (especially if those circumstances vary dynamically). On Aug 2, 9:57 pm, Bob Kerns r...@acm.org wrote: OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on
[android-developers] Re: Android preprocessor, //#ifdef...
Right. The compiler knows what the line number is (at least if there's no preprocessor in the way). It can return that from a pseudo- function. Same for class, method, etc. On Aug 2, 10:03 pm, Bob Kerns r...@acm.org wrote: Note that you don't need a preprocessor to do this! Just a bit of language support. On Aug 2, 8:01 pm, Bob Kerns r...@acm.org wrote: Yes, I've seen a few cases like this. There are ways to cache the runtime call, which can be a bit expensive, but they rely a bit much on convention and are a bit more verbose than you'd like. On Aug 2, 7:02 pm, DanH danhi...@ieee.org wrote: Lots of times it would be nice for logging. Sometimes you'd like to store an I was here indicator in a structure when you modify it. Yes, there are alternatives, but not as nice. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
The main reason to need these is logging / debugging, so runtime overhead is acceptable. Or am I missing something? On the other hand, __FILE__ and __LINE__ are only valid where they are used - there is no way to get the caller's file and line info, so it has to be passed to whatever functions you want to use them in. And that is certainly a maintenance issue - what if you decide to log caller file and line in a function that was not designed for it from the start? It also would be interesting to know why exactly the OP thought he needed the preprocessor. Who knows, maybe he wanted to produce separate versions of his application for different screen sizes / densities? -- Kostya 03.08.2010 17:10, DanH пишет: Right. The compiler knows what the line number is (at least if there's no preprocessor in the way). It can return that from a pseudo- function. Same for class, method, etc. On Aug 2, 10:03 pm, Bob Kernsr...@acm.org wrote: Note that you don't need a preprocessor to do this! Just a bit of language support. On Aug 2, 8:01 pm, Bob Kernsr...@acm.org wrote: Yes, I've seen a few cases like this. There are ways to cache the runtime call, which can be a bit expensive, but they rely a bit much on convention and are a bit more verbose than you'd like. On Aug 2, 7:02 pm, DanHdanhi...@ieee.org wrote: Lots of times it would be nice for logging. Sometimes you'd like to store an I was here indicator in a structure when you modify it. Yes, there are alternatives, but not as nice. -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
I object to the fact the people who write Java are real programmers... Sorry, couldn't help myself, likely should hit send, oh well. On 8/3/2010 1:30 AM, Frank Weiss wrote: This thread is a little like schadenfreude to me. A lot of it is about taste - of which arguing about is of little use. I just saw some Java code where every closing brace is commented with // end of if, // end of for, // end of method, etc. Yech!. That, to me, is worth arguing about! If the OP wants to use preprocessor, nothing's stopping them. Indeed, as Bob Kearns points out, Android SDK generates R.java from several XML files, which is pretty darn close to what a preprocessor does. Would it be that hard for the determined developer to add a preprocessor hook into the SDK build script - even on Eclipse? Come on folks, this is open source code! Even Atlassian lets you modify the Jira and Confluence source code! My $0.02 is that even if javac did have a preprocessor, few real Java programmers would deign to use it. Nonetheless, I'm sure there are a few cases where a preprocessor is Just The Right Way To Program. -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
@Leigh LOL. I think your amusement is warranted. What I meant to say is that a lot of the really great programming techniques, such as refactoring to patterns, tend to be explained in Java. I would suppose that really good programmers can write flexible Java code without the use of a preprocessor - and - that powerful IDEs can do a lot of refactoring automatically because there are no #define, #ifdef, etc. in the source code. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On 8/2/2010 10:49 PM, Bob Kerns wrote:
First of all -- if you want to list the faults of the C language, the
preprocessor is very near the top.
Just your opinion.
That's why C++ went to great lengths to mostly remove the need for
using it, with inline functions, constants, and the like.
Now your just talking specifically about macros which still can be
useful and there are somethings that can only be done using a macro.
It's too bad they didn't remove it. It causes all kinds of difficulty
for tools. The tools for Java are generally far better than for C++ --
and the lack of a preprocessor to screw up and ambiguate the
interpretation of any piece of syntax you look at, is a huge part of
the reason.
MS tools destroy what Java has to offer IMHO. Only the re-factoring is
better for Java. It's all opinion either way.
I think you have to realize that preprocesing is just a tool and isn't
to be used to solve all problems. Just because I want a hammer doesn't
mean I regard every issue as being a nail. It's very appropriate to
handle cross platform issues, hardware issue, diagnostic code etc. All
of these issues are very relevant to Android. Sure these issues might
be handled differently for a desktop solution where resources aren't as
big of an issue.
Why force everyone to do it the so called right way? Why does C# have
conditional compile? Just because SUN chose not to support
preprocessing in javac doesn't mean they aren't behind it. Maybe they
chose to support it through tools so that j2me code would still work
with j2se? That would make a lot of sense to me. For something they
aren't behind they sure put a lot of effort into it.
It's also a major compilation performance hit. With a significant
amount of pain, you can get Visual Studio to avoid a lot of the
reparsing it requires, but the language basically says that to compile
any particular program file, you have to parse all the #includes,
recursively, processing the same file over and over and over again --
possibly differently each and every time, because INTEGER may mean int
in one case, unsigned int in another, and unsigned long long in yet
another.
And that's a problem for programmers, too. No, I don't mean a problem
for me, that a good C++ programmer knows how to avoid the problems. I
mean its a problem I've had to help MANY experienced C++ programmers
resolve time and time again -- often in vendor-supplied code, rather
than their own. Or when two different vendor's include files conflict
-- or one vendor's include files conflict with their own.
My long experience is that every time someone tells me they need a
preprocessor -- there turns out to be a better way. Sometimes you
replace that with code generation -- but most of the time, code
generation isn't the ultimate solution, either. Often, proper use of
introspection and metadata (the annotation facility, for example)
provide a superior (more robust, more compact, and more maintainable)
solution.
Solve this one for me. BlackBerry has a version of atan2 that is
fixed-point and is much faster that the Math.atan2. How can I take
advantage of this without an interface or an extra function call?
public static final float VecToHeading( float x, float y )
{
//#if PLATFORM_BLACKBERRY
floatfAngle = ((float)Fixed32.atand2( (int)(x * 65536.0f), (int)(y
* 65536.0f) )) / 65536.0f;
//#else
//@floatfAngle = ((float)Math.atan2( x, y )) *
57.295779513082320876798154814105f;
//#endif
if ( fAngle 0.0f )
return fAngle + 360.0f;
return fAngle;
}
Here is another one. The math function is in two different packages.
//#if PLATFORM_BLACKBERRY
omega = (float)net.rim.device.api.util.MathUtilities.acos( cosom );
//#else
//@ omega = (float)java.lang.Math.acos( cosom );
//#endif
And that includes the use here -- of selecting what code to run. For
that, often the solution lies in correct modularity of the program.
Trust me -- littering your code with conditionals does not improve it.
Actually laying down some surgical preprocess strikes within my code has
allowed me to finish the project without having to create more code that
I would have to manage and pay for at run-time.
--
Leigh McRae
www.lonedwarfgames.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I guess a few people who write Java ARE real programmers, though sometimes it's hard to tell. And the Android environment is actually one of the better Java development environments in terms of not dumbing down things (though I do wonder about a few features). On Aug 3, 12:10 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: I object to the fact the people who write Java are real programmers... Sorry, couldn't help myself, likely should hit send, oh well. On 8/3/2010 1:30 AM, Frank Weiss wrote: This thread is a little like schadenfreude to me. A lot of it is about taste - of which arguing about is of little use. I just saw some Java code where every closing brace is commented with // end of if, // end of for, // end of method, etc. Yech!. That, to me, is worth arguing about! If the OP wants to use preprocessor, nothing's stopping them. Indeed, as Bob Kearns points out, Android SDK generates R.java from several XML files, which is pretty darn close to what a preprocessor does. Would it be that hard for the determined developer to add a preprocessor hook into the SDK build script - even on Eclipse? Come on folks, this is open source code! Even Atlassian lets you modify the Jira and Confluence source code! My $0.02 is that even if javac did have a preprocessor, few real Java programmers would deign to use it. Nonetheless, I'm sure there are a few cases where a preprocessor is Just The Right Way To Program. -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. If it were really supported and fully backed by Sun it would be supported in javac. On Aug 1, 9:40 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
(don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on Android. Good luck. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
using __FILE__ or __LINE Actually, it's a bit irritating that javac doesn't implement those and a few others (particularly __CLASS and __METHOD). They would be very easy to implement within the language, without the need for a preprocessor. But certainly the need for them is reduced by the generally good to excellent traceback info available in most environments. Just a little lacking in logging situations. On Aug 1, 2:50 pm, dm1973 david050...@gmail.com wrote: I think most peoples opinion is that it just is not useful in java. There have been numerous discussions about needing/not needing a preprocessor in Java. You are not going to be #defining symbols (use a static class), including files, using __FILE__ or __LINE ( use the logging, no symbols means no ifdefing code (if (false) workes the same as #if 0 ), macros for functions (ie make a class and use static inline function). If you care to tell use the problem you are trying to solve, some could probably suggest a solution that doesn't involve macros. Im 15 years of Java, I have never missed them. Macros in the build system on the other hand... On Aug 1, 10:40 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
It's defined in the language to happen, given the proper circumstances of a simple if testing an expression composed of constants and not exceeding a given complexity. The thing it won't do is ignore syntax errors and undefined symbols in the dead leg. On Aug 1, 3:12 pm, RichardC richard.crit...@googlemail.com wrote: Thank you, that's going to make my life easier. As I am still learning Java, can you tell me if the removal of dead code is a feature of the Java language or is it unique to the Android build chain? On Aug 1, 8:50 pm, Romain Guy romain...@android.com wrote: I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. You can achieve this in Java using static final fields. The compiler is smart enough to remove if block whose condition evaluates to false at compile time (we use this a lot in Android's source code :). -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Getting the file name, line number, class and method are all available in Java today. There is no need for a preprocessor to get them. I haven't checked if they work on android but I imagine they would since all the other stack trace methods do. On Aug 2, 3:57 pm, DanH danhi...@ieee.org wrote: using __FILE__ or __LINE Actually, it's a bit irritating that javac doesn't implement those and a few others (particularly __CLASS and __METHOD). They would be very easy to implement within the language, without the need for a preprocessor. But certainly the need for them is reduced by the generally good to excellent traceback info available in most environments. Just a little lacking in logging situations. On Aug 1, 2:50 pm, dm1973 david050...@gmail.com wrote: I think most peoples opinion is that it just is not useful in java. There have been numerous discussions about needing/not needing a preprocessor in Java. You are not going to be #defining symbols (use a static class), including files, using __FILE__ or __LINE ( use the logging, no symbols means no ifdefing code (if (false) workes the same as #if 0 ), macros for functions (ie make a class and use static inline function). If you care to tell use the problem you are trying to solve, some could probably suggest a solution that doesn't involve macros. Im 15 years of Java, I have never missed them. Macros in the build system on the other hand... On Aug 1, 10:40 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Yes I have the code to get them but it's a runtime call On Aug 2, 9:44 pm, dm1973 david050...@gmail.com wrote: Getting the file name, line number, class and method are all available in Java today. There is no need for a preprocessor to get them. I haven't checked if they work on android but I imagine they would since all the other stack trace methods do. On Aug 2, 3:57 pm, DanH danhi...@ieee.org wrote: using __FILE__ or __LINE Actually, it's a bit irritating that javac doesn't implement those and a few others (particularly __CLASS and __METHOD). They would be very easy to implement within the language, without the need for a preprocessor. But certainly the need for them is reduced by the generally good to excellent traceback info available in most environments. Just a little lacking in logging situations. On Aug 1, 2:50 pm, dm1973 david050...@gmail.com wrote: I think most peoples opinion is that it just is not useful in java. There have been numerous discussions about needing/not needing a preprocessor in Java. You are not going to be #defining symbols (use a static class), including files, using __FILE__ or __LINE ( use the logging, no symbols means no ifdefing code (if (false) workes the same as #if 0 ), macros for functions (ie make a class and use static inline function). If you care to tell use the problem you are trying to solve, some could probably suggest a solution that doesn't involve macros. Im 15 years of Java, I have never missed them. Macros in the build system on the other hand... On Aug 1, 10:40 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
What RichardC said. On Aug 2, 3:44 pm, dm1973 david050...@gmail.com wrote: Getting the file name, line number, class and method are all available in Java today. There is no need for a preprocessor to get them. I haven't checked if they work on android but I imagine they would since all the other stack trace methods do. On Aug 2, 3:57 pm, DanH danhi...@ieee.org wrote: using __FILE__ or __LINE Actually, it's a bit irritating that javac doesn't implement those and a few others (particularly __CLASS and __METHOD). They would be very easy to implement within the language, without the need for a preprocessor. But certainly the need for them is reduced by the generally good to excellent traceback info available in most environments. Just a little lacking in logging situations. On Aug 1, 2:50 pm, dm1973 david050...@gmail.com wrote: I think most peoples opinion is that it just is not useful in java. There have been numerous discussions about needing/not needing a preprocessor in Java. You are not going to be #defining symbols (use a static class), including files, using __FILE__ or __LINE ( use the logging, no symbols means no ifdefing code (if (false) workes the same as #if 0 ), macros for functions (ie make a class and use static inline function). If you care to tell use the problem you are trying to solve, some could probably suggest a solution that doesn't involve macros. Im 15 years of Java, I have never missed them. Macros in the build system on the other hand... On Aug 1, 10:40 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On Mon, Aug 2, 2010 at 2:16 PM, RichardC richard.crit...@googlemail.comwrote: Yes I have the code to get them but it's a runtime call So what? What are you trying to do with the line number where the overhead of a runtime call is significant? Honestly, I spent years programming in C++, and this is not a feature I have *ever* felt I was missing. The ability to get full complete stack crawls at any point more than makes up for it. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Lots of times it would be nice for logging. Sometimes you'd like to store an I was here indicator in a structure when you modify it. Yes, there are alternatives, but not as nice. On Aug 2, 7:53 pm, Dianne Hackborn hack...@android.com wrote: On Mon, Aug 2, 2010 at 2:16 PM, RichardC richard.crit...@googlemail.comwrote: Yes I have the code to get them but it's a runtime call So what? What are you trying to do with the line number where the overhead of a runtime call is significant? Honestly, I spent years programming in C++, and this is not a feature I have *ever* felt I was missing. The ability to get full complete stack crawls at any point more than makes up for it. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
First of all -- if you want to list the faults of the C language, the preprocessor is very near the top. That's why C++ went to great lengths to mostly remove the need for using it, with inline functions, constants, and the like. It's too bad they didn't remove it. It causes all kinds of difficulty for tools. The tools for Java are generally far better than for C++ -- and the lack of a preprocessor to screw up and ambiguate the interpretation of any piece of syntax you look at, is a huge part of the reason. It's also a major compilation performance hit. With a significant amount of pain, you can get Visual Studio to avoid a lot of the reparsing it requires, but the language basically says that to compile any particular program file, you have to parse all the #includes, recursively, processing the same file over and over and over again -- possibly differently each and every time, because INTEGER may mean int in one case, unsigned int in another, and unsigned long long in yet another. And that's a problem for programmers, too. No, I don't mean a problem for me, that a good C++ programmer knows how to avoid the problems. I mean its a problem I've had to help MANY experienced C++ programmers resolve time and time again -- often in vendor-supplied code, rather than their own. Or when two different vendor's include files conflict -- or one vendor's include files conflict with their own. My long experience is that every time someone tells me they need a preprocessor -- there turns out to be a better way. Sometimes you replace that with code generation -- but most of the time, code generation isn't the ultimate solution, either. Often, proper use of introspection and metadata (the annotation facility, for example) provide a superior (more robust, more compact, and more maintainable) solution. And that includes the use here -- of selecting what code to run. For that, often the solution lies in correct modularity of the program. Trust me -- littering your code with conditionals does not improve it. On Jul 31, 3:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on Android. Good luck. --- -- TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I claim this is a good thing. You compile it once, you know it will compile and run everywhere. Introspection and/or moving code to platform-specific subclasses (and often into platform-specific jars compiled only on that platform) handle the undefined symbols problem quite nicely. They also provide the ENORMOUS benefit of locating your platform dependencies in a single place. Simply build a platform-independent abstraction around your platform-dependent layer. On Aug 2, 1:00 pm, DanH danhi...@ieee.org wrote: It's defined in the language to happen, given the proper circumstances of a simple if testing an expression composed of constants and not exceeding a given complexity. The thing it won't do is ignore syntax errors and undefined symbols in the dead leg. On Aug 1, 3:12 pm, RichardC richard.crit...@googlemail.com wrote: Thank you, that's going to make my life easier. As I am still learning Java, can you tell me if the removal of dead code is a feature of the Java language or is it unique to the Android build chain? On Aug 1, 8:50 pm, Romain Guy romain...@android.com wrote: I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. You can achieve this in Java using static final fields. The compiler is smart enough to remove if block whose condition evaluates to false at compile time (we use this a lot in Android's source code :). -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
OT, but I'll bite. What do you consider a really good GC setup? Sun's GC is good enough that I would hesitate to make blanket statements that it is better than X or worse than X. (Though I will say that the newer Sun GC implementations are clearly better than the older ones). There are a lot of different parameters to evaluate a GC by -- and not just CPU overhead. I don't ask in order to dispute your choice, BTW -- just to understand what you're considering a good GC and why -- and perhaps learn of a really good GC I don't know about! (It's been a while, but I've implemented, debugged, and maintained a number of GCs over the years, and worked with many of the true pioneers in the field of GC. So you can see why I'm curious). On Aug 2, 12:53 pm, DanH danhi...@ieee.org wrote: (don't get me started on GC based languages) I know it's off-topic, but I have to say something. Having done large applications in both I much prefer GCed languages (provided the GC is well implemented). More robust and less overhead (yes, faster), with fewer ways for the programmer to shoot himself in the foot. (Unfortunately, Sun's GC implementations are only mediocre, so it's possible you've never seen a really good GC setup.) On Aug 1, 2:33 pm, RichardC richard.crit...@googlemail.com wrote: My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on Android. Good luck. --- -- TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Yes, I've seen a few cases like this. There are ways to cache the runtime call, which can be a bit expensive, but they rely a bit much on convention and are a bit more verbose than you'd like. On Aug 2, 7:02 pm, DanH danhi...@ieee.org wrote: Lots of times it would be nice for logging. Sometimes you'd like to store an I was here indicator in a structure when you modify it. Yes, there are alternatives, but not as nice. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Note that you don't need a preprocessor to do this! Just a bit of language support. On Aug 2, 8:01 pm, Bob Kerns r...@acm.org wrote: Yes, I've seen a few cases like this. There are ways to cache the runtime call, which can be a bit expensive, but they rely a bit much on convention and are a bit more verbose than you'd like. On Aug 2, 7:02 pm, DanH danhi...@ieee.org wrote: Lots of times it would be nice for logging. Sometimes you'd like to store an I was here indicator in a structure when you modify it. Yes, there are alternatives, but not as nice. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I don't normally do this but +1 On Aug 2, 12:46 pm, DanH danhi...@ieee.org wrote: Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. If it were really supported and fully backed by Sun it would be supported in javac. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
This thread is a little like schadenfreude to me. A lot of it is about taste - of which arguing about is of little use. I just saw some Java code where every closing brace is commented with // end of if, // end of for, // end of method, etc. Yech!. That, to me, is worth arguing about! If the OP wants to use preprocessor, nothing's stopping them. Indeed, as Bob Kearns points out, Android SDK generates R.java from several XML files, which is pretty darn close to what a preprocessor does. Would it be that hard for the determined developer to add a preprocessor hook into the SDK build script - even on Eclipse? Come on folks, this is open source code! Even Atlassian lets you modify the Jira and Confluence source code! My $0.02 is that even if javac did have a preprocessor, few real Java programmers would deign to use it. Nonetheless, I'm sure there are a few cases where a preprocessor is Just The Right Way To Program. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Hi king, yes I do it since I'm a mercenary, I develop for money, and I develop on the platform that people like. The discussions about Java hasn't got any sense to me... Android ISN'T Java, it has no rights to be called java and if you not agree with it you should learn some basic java guidelines and understand what is java. Anyway Android is the ONLY programming language that doesn't support preprocessor on mobile phones, if you like it, ok :) We are but don't justify a real bad lack. On Aug 1, 4:11 am, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 5:09 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. Why so surprised? The main Android SDK is Java-based, which does not have preprocessor. Whatever you've used with other platforms are exceptions, not the norm. I would actually be surprised if it DID have one. I can't think on mobile programming without preprocessor, Well you better learn real fast =) too many different configurations, Too many configurations of what? think only to LVL and android market and preprocessor could be useful... Haven't played with LVL yet, so don't know about that. Useful? Maybe. Necessary? Doubtful. Ok we can live without it, but codes becomes really unelegant... One could argue that preprocessor macros makes code much worse. Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) Do you always do what the masses tell you? =P - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On Sun, Aug 1, 2010 at 4:05 AM, sblantipodi perini.dav...@dpsoftware.org wrote: Android ISN'T Java, it has no rights to be called java and if you not agree with it you should learn some basic java guidelines and understand what is java. Android uses Java source code and Java build tools (notably javac, keytool, and jarsigner) as part of creating Android applications that run on the Dalvik VM. For shorthand, many people involved in Android will say that Android runs Java or Android Java applications or the like. You are welcome to disagree with the shorthand, but the more you irritate people providing assistance on groups like this, the less likely it is you will get assistance on your questions. Therefore, you need to decide whether your oft-repeated Android ISN'T Java statements are in your best interests. Anyway Android is the ONLY programming language that doesn't support preprocessor on mobile phones, Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android 2.2 Programming Books: http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
Android ISN'T Java, it has no rights to be called java and if you not agree with it you should learn some basic java guidelines and understand what is java. Please stop whinning. If you do not like Android just drop it. Simple as that.Go develop for anything else and stay happy with preprocessors. For clarification this is android (whatever it really is) support list, not anything else and people discuss programming on Android, usually in the programming-language-that-looks-like-java-but-some-says-it-is-not-but-who-cares. Anyway Android is the ONLY programming language that doesn't support preprocessor on mobile phones, Android is a platform, not a language. Strange, you got problems noticing the difference. finish(); -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I'm sorry, I don't want to irritate no one, but I have different thinking on the topic. To say that something is Java or Java Powered you need to pay and pass intensive test. Google hasn't payed nothing to Sun, nor Oracle and neither passed any JCP test so you can't call it java. Why Google folks use this statement? Android applications are written in the Java programming language.. How Dalvik is supposed to be considered Java? It has a different bytecode, it uses different package systems, its API does not even reflect tha actual Java API's, it doesn't have any compatibility with CLDC or CDC ... How they can call Android Java? Calling Android Java is like saying Microsoft J++ is Java, this is only my opinion, you can disagree, don't irritate it's not my intention and please sorry if I made you irritating. Regards, Davide. On Aug 1, 10:29 am, Mark Murphy mmur...@commonsware.com wrote: On Sun, Aug 1, 2010 at 4:05 AM, sblantipodi perini.dav...@dpsoftware.org wrote: Android ISN'T Java, it has no rights to be called java and if you not agree with it you should learn some basic java guidelines and understand what is java. Android uses Java source code and Java build tools (notably javac, keytool, and jarsigner) as part of creating Android applications that run on the Dalvik VM. For shorthand, many people involved in Android will say that Android runs Java or Android Java applications or the like. You are welcome to disagree with the shorthand, but the more you irritate people providing assistance on groups like this, the less likely it is you will get assistance on your questions. Therefore, you need to decide whether your oft-repeated Android ISN'T Java statements are in your best interests. Anyway Android is the ONLY programming language that doesn't support preprocessor on mobile phones, Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 2.2 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
You are confusing Java the language and platforms that use Java. There are in fact serveral platforms where Java is used - J2ME, Servlets, Java Beans (and more). These platforms have one thing in common - applications are written in Java the language. But other than that, they have little on common, and a J2ME application will not run inside WebSphere (for example). Each of these platforms defines its own framework and its own runtime environment. Android applications are written in Java the language, Android provides an implementation of basic Java library, but beyond that - it's a platform just like the platforms mentioned above. It has its own Java framework, and its own runtime environment. The framework doesn't include parts of Java platform that don't make sense for a phone app - like AWT or Swing. But the same is true for a Web Servlet container. Since application source is Java, Android team was able to leverage work already done by other people: Eclipse, the Java compiler, keytool, etc. Dalvik and .apk / .dex bytecode format is completely irrelevant - you don't create applications by entering bytecodes directly on the phone. From a purist point of view, even Sun's own Java VM with JIT can be considered not Java since it doesn't directly execute Java bytecodes - but that would be really absurd. Finally, here is James Gosling's own take on preprocessing in Java: http://java.sun.com/docs/white/langenv/Simple.doc2.html#4078 -- Kostya 01.08.2010 14:55, sblantipodi пишет: I'm sorry, I don't want to irritate no one, but I have different thinking on the topic. To say that something is Java or Java Powered you need to pay and pass intensive test. Google hasn't payed nothing to Sun, nor Oracle and neither passed any JCP test so you can't call it java. Why Google folks use this statement? Android applications are written in the Java programming language.. How Dalvik is supposed to be considered Java? It has a different bytecode, it uses different package systems, its API does not even reflect tha actual Java API's, it doesn't have any compatibility with CLDC or CDC ... How they can call Android Java? Calling Android Java is like saying Microsoft J++ is Java, this is only my opinion, you can disagree, don't irritate it's not my intention and please sorry if I made you irritating. Regards, Davide. On Aug 1, 10:29 am, Mark Murphymmur...@commonsware.com wrote: On Sun, Aug 1, 2010 at 4:05 AM, sblantipodi perini.dav...@dpsoftware.org wrote: Android ISN'T Java, it has no rights to be called java and if you not agree with it you should learn some basic java guidelines and understand what is java. Android uses Java source code and Java build tools (notably javac, keytool, and jarsigner) as part of creating Android applications that run on the Dalvik VM. For shorthand, many people involved in Android will say that Android runs Java or Android Java applications or the like. You are welcome to disagree with the shorthand, but the more you irritate people providing assistance on groups like this, the less likely it is you will get assistance on your questions. Therefore, you need to decide whether your oft-repeated Android ISN'T Java statements are in your best interests. Anyway Android is the ONLY programming language that doesn't support preprocessor on mobile phones, Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 2.2 Programming Books:http://commonsware.com/books -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
Leigh, I don't think anyone is against it. There happens to be no support for it in Eclipse, the development environment chosen by the Android team. It just doesn't seem like a show-stopper (see Android Market), and it's certainly an overstatement to say (or imply) that Android is a complete disaster to develop for because there is no Java preprocessing. -- Kostya 01.08.2010 18:40, Leigh McRae пишет: What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On 8/1/2010 11:14 AM, Kostya Vasilyev wrote: Leigh, I don't think anyone is against it. There happens to be no support for it in Eclipse, the development environment chosen by the Android team. It just doesn't seem like a show-stopper (see Android Market), and it's certainly an overstatement to say (or imply) that Android is a complete disaster to develop for because there is no Java preprocessing. -- Kostya 01.08.2010 18:40, Leigh McRae пишет: What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... Sure it's not a show-stopper and the OP is really off side in their attitude. The Android team does seem to be against it since there was a request for it and it was denied without comment. http://code.google.com/p/android/issues/detail?id=2659 RIM has also chosen Eclipse as the IDE that they are going to support. They simply added some entry fields for the defines and passes it along to rapc. For the record you can use antenna along with an ant script to get something going. -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Get your facts straight, and the fog of your confusion will lift. Google did not release the first buggy SDK. Every vendor's first SDK was buggy. As for why no #ifdef, when they designed Java, they realized the main applications of #ifdef were 1) accommodating hardware differences and 2) debugging. The former was expected to be handled with implementation of different Interfaces, the latter with Java's debugging capabilities INSTEAD of using #ifdef. On Jul 31, 1:00 pm, sblantipodi perini.dav...@dpsoftware.org wrote: ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblantipodi perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understood if this is a lack of netbeans or it is a lack of android. It's a lack of Java. Preprocessing, specifically the #ifndef notation you mention, is a C/C++ thing. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Wrong. If it had no right to be called Java, then Sun (now Oracle) would be suing Google, since they protect the name zealously. Remember what happened when Microsoft tried polluting the name. Sun did not sue even before the Oracle acquisition, they didn't even complain; so they must have been content that Android's use of the name Java is correct -- at least for the language, not the platform (http://blogoscoped.com/archive/2007-11-13-n83.html). On Aug 1, 1:05 am, sblantipodi perini.dav...@dpsoftware.org wrote: Hi king, yes I do it since I'm a mercenary, I develop for money, and I develop on the platform that people like. The discussions about Java hasn't got any sense to me... Android ISN'T Java, it has no rights to be called java and if you not agree with it you should learn some basic java guidelines and understand what is java. Anyway Android is the ONLY programming language that doesn't support preprocessor on mobile phones, if you like it, ok :) We are but don't justify a real bad lack. On Aug 1, 4:11 am, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 5:09 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. Why so surprised? The main Android SDK is Java-based, which does not have preprocessor. Whatever you've used with other platforms are exceptions, not the norm. I would actually be surprised if it DID have one. I can't think on mobile programming without preprocessor, Well you better learn real fast =) too many different configurations, Too many configurations of what? think only to LVL and android market and preprocessor could be useful... Haven't played with LVL yet, so don't know about that. Useful? Maybe. Necessary? Doubtful. Ok we can live without it, but codes becomes really unelegant... One could argue that preprocessor macros makes code much worse. Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) Do you always do what the masses tell you? =P - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
But why bother when there is already an open source preprocessor for Java in Eclipse? It is called 'prebop' and there is an article on it at http://www.boldinventions.com/index.php?option=com_contentview=articleid=81:javapreprocessorusingeclipsecatid=34:category-electronics-articlesItemid=53 including a link to the SourceForge project. So if the OP and others -r-e-a-l-l-y- want preprocessing, they can have it. But I still have to question the wisdom of the choice. Sure, there are the famous tight spots that only preprocessing looks good for, but more often, those who insist on it really are still thinking the C or C++ way rather than the Java way. On Aug 1, 8:48 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 11:14 AM, Kostya Vasilyev wrote: Leigh, I don't think anyone is against it. There happens to be no support for it in Eclipse, the development environment chosen by the Android team. It just doesn't seem like a show-stopper (see Android Market), and it's certainly an overstatement to say (or imply) that Android is a complete disaster to develop for because there is no Java preprocessing. -- Kostya 01.08.2010 18:40, Leigh McRae пишет: What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... Sure it's not a show-stopper and the OP is really off side in their attitude. The Android team does seem to be against it since there was a request for it and it was denied without comment. http://code.google.com/p/android/issues/detail?id=2659 RIM has also chosen Eclipse as the IDE that they are going to support. They simply added some entry fields for the defines and passes it along to rapc. For the record you can use antenna along with an ant script to get something going. -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
My background is C and C++ ... 25 years and no longer counting :) So I had some ingrained expectations when I started learning Java; amongst them was the expectation that the Java language would support conditional compliation. I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. I now write less of this type of code and try to remember to mark what I do wite with a remove me comment, which gets picked up by the Eclipse to-do list. I then remove it during my pre-QA code review. I have yet to feel the need to use conditional compilation to deal with the often quoted platform fragmentation as the differences in the platforms mostly impacts the amout of time I spend testing and I have yet to write ANY code that differs by supported hardware. Using the resource qualifiers has been all I have needed to do so far. I still don't like some aspects of the Java language (don't get me started on GC based languages) but Android is much more than just a language and writing off a complete platform for one feature you consider missing is very strange position to take. On Jul 31, 11:09 pm, sblantipodi perini.dav...@dpsoftware.org wrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on Android. Good luck. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I think most peoples opinion is that it just is not useful in java. There have been numerous discussions about needing/not needing a preprocessor in Java. You are not going to be #defining symbols (use a static class), including files, using __FILE__ or __LINE ( use the logging, no symbols means no ifdefing code (if (false) workes the same as #if 0 ), macros for functions (ie make a class and use static inline function). If you care to tell use the problem you are trying to solve, some could probably suggest a solution that doesn't involve macros. Im 15 years of Java, I have never missed them. Macros in the build system on the other hand... On Aug 1, 10:40 am, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 8/1/2010 4:29 AM, Mark Murphy wrote: Java (J2ME, Blackberry, Android) does not have a native preprocessor. Neither does Javascript for WebOS/HTML5 applications, nor Actionscript for Flash/Flex/AIR applications. Neither do some languages drifting into the mobile space (e.g., Ruby, and Perl AFAICT) for Android, Meego, and Symbian. It is probably more accurate to say that C and its derivatives (e.g., C++, Objective-C, C#) and .NET languages (VB, C#) have an integrated preprocessor, and that those languages are widespread in mobile platforms today. Preprocessing for j2me is supported by SUN via NetBeans. It's pretty clear that SUN fully backs preprocessing for j2me if you look at all the support provided. BlackBerry preprocessing is fully supported via their compiler, rapc. What I don't understand is why so many people are against it. It's just a tool and one that can get you out of a tight spot. Give people the tools and let them cut their own toes or feet off. Oh and yes I know what the reply will be. Write it yourself, it's open source... We aren't Java or we are Java depending on what we are debating... -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. You can achieve this in Java using static final fields. The compiler is smart enough to remove if block whose condition evaluates to false at compile time (we use this a lot in Android's source code :). -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Thank you, that's going to make my life easier. As I am still learning Java, can you tell me if the removal of dead code is a feature of the Java language or is it unique to the Android build chain? On Aug 1, 8:50 pm, Romain Guy romain...@android.com wrote: I have had to learn to live without conditional compliation. The only area where I really miss having a lanugage constuct like #ifdef is when I need to remove instrumentation and/or debugging code. You can achieve this in Java using static final fields. The compiler is smart enough to remove if block whose condition evaluates to false at compile time (we use this a lot in Android's source code :). -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
It's not a feature of the language, nor of Android, it's just part of
any sane Java compiler. I have yet to come across one that doesn't do
it. The Sun (Oracle) Java compiler in particular does it. The Eclipse
compiler does it as well. You can test for yourself with your compiler
by compiling a simple class like this one:
class Test {
private static final boolean DEBUG = false;
public void foo() {
if (DEBUG) System.out.println(Debug mode);
System.out.println(Normal mode);
}
}
Then decompile it using javap -c Test:
class Test extends java.lang.Object{
Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object.init:()V
4: return
public void foo();
Code:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3; //String Normal mode
5: invokevirtual #4; //Method
java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
}
You can see that the if (DEBUG) statement was not compiled in the
foo() method. If you were to compile with DEBUG set to true, you'd see
that the call to System.out.println is compiled, but the if is not.
On Sun, Aug 1, 2010 at 1:12 PM, RichardC richard.crit...@googlemail.com wrote:
Thank you, that's going to make my life easier.
As I am still learning Java, can you tell me if the removal of dead
code is a feature of the Java language or is it unique to the Android
build chain?
On Aug 1, 8:50 pm, Romain Guy romain...@android.com wrote:
I have had to learn to live without conditional compliation. The only
area where I really miss having a lanugage constuct like #ifdef is
when I need to remove instrumentation and/or debugging code.
You can achieve this in Java using static final fields. The compiler
is smart enough to remove if block whose condition evaluates to false
at compile time (we use this a lot in Android's source code :).
--
Romain Guy
Android framework engineer
romain...@android.com
Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Romain Guy
Android framework engineer
romain...@android.com
Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblantipodi perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understood if this is a lack of netbeans or it is a lack of android. It's a lack of Java. Preprocessing, specifically the #ifndef notation you mention, is a C/C++ thing. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
The absence of preprocessor has to do with Java, not Android. And tlhere is a lot of Java software out there... -- Kostya Vasilyev -- http://kmansoft.wordpress.com 01.08.2010 0:00 пользователь sblantipodi perini.dav...@dpsoftware.org написал: ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblan... perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understo... TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are su... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
Ok but other java software/platform supports preprocessor on both Eclipse/Netbeans/IntelliJ/JDE ecc. ecc... On Jul 31, 10:15 pm, Kostya Vasilyev kmans...@gmail.com wrote: The absence of preprocessor has to do with Java, not Android. And tlhere is a lot of Java software out there... -- Kostya Vasilyev --http://kmansoft.wordpress.com 01.08.2010 0:00 пользователь sblantipodi perini.dav...@dpsoftware.org написал: ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblan... perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understo... TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are su... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
Here is a long thread on the subject: http://groups.google.com/group/android-developers/browse_thread/thread/1c9078176b172e1a/235bae6530ee7e74?show_docid=235bae6530ee7e74 There are Java projects that use various preprocessors. The lack of a standard one is a problem. AFAIK Sun's WORA ideology ran against the need for a preprocessor, although many developers think that mobile platforms have taken a big bite out of WORA. Modern software development methodologies, such as refactoring to patterns, tend to use other approaches for making software flexible and reusable. Personally, I'm glad Java does not have a preprocessor. It just seems a much cleaner language that way, that is, I have never yet seen Java code with ifdefs. But I can understand that it can be very useful under certain circumstances. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on Android. Good luck. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. I can't think on mobile programming without preprocessor, too many different configurations, think only to LVL and android market and preprocessor could be useful... Ok we can live without it, but codes becomes really unelegant... Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) On Jul 31, 10:58 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 3:00 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: How can you develop on a mobile without preprocessing? Quite easily, actually. Sure android is really good for fart app, but what else? Is this is a serious question? Have you browsed through the Android Market (as painful as that is)? There's a lot more out there than fart apps. I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. Probably simply because it's an alternative to iPhone. Now, someone with your experience developing for so many devices can surely adapt to not having a preprocessor. It's good for many things but definitely not a necessity and will certainly not cripple you when making an Android App. If you're personally that attached to having a preprocessor, no one is forcing you to develop on Android. Good luck. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
I'm glad to not have to use pre-processors and hash-defines. I hated them when i worked in C (and C++) (they tended to get over- used, made code unreadable and difficult to debug) and for the last decade of Java programming i really never ever needed them. How can you develop on a mobile without preprocessing? Easily, no problem. On Jul 31, 4:00 pm, sblantipodi perini.dav...@dpsoftware.org wrote: ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblantipodi perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understood if this is a lack of netbeans or it is a lack of android. It's a lack of Java. Preprocessing, specifically the #ifndef notation you mention, is a C/C++ thing. ----- TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
On Sat, Jul 31, 2010 at 5:09 PM, sblantipodi perini.dav...@dpsoftware.orgwrote: I'm sorry for my rude and really not too much kind speaking, but I can't belive that android doesn't support preprocessor. Why so surprised? The main Android SDK is Java-based, which does not have preprocessor. Whatever you've used with other platforms are exceptions, not the norm. I would actually be surprised if it DID have one. I can't think on mobile programming without preprocessor, Well you better learn real fast =) too many different configurations, Too many configurations of what? think only to LVL and android market and preprocessor could be useful... Haven't played with LVL yet, so don't know about that. Useful? Maybe. Necessary? Doubtful. Ok we can live without it, but codes becomes really unelegant... One could argue that preprocessor macros makes code much worse. Sincerely I really don't like the non preprocessor way but unfortunantly, masses told that android is good and I need to develop on it :) Do you always do what the masses tell you? =P - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android preprocessor, //#ifdef...
On some development systems a C preprocessor has been hijacked to
preprocess Java code. It's not standard, though.
You can use final constants in Java to select pieces of code. Eg, if
(MY_CONSTANT) { ... } where MY_CONSTANT is a final boolean value.
The Java compiler is defined to compile these on or off at compile
time, eliminating any runtime checks. However, the code in a
deactivated if leg still needs to be legal Java with variables that
exist, etc.
On Jul 31, 3:00 pm, sblantipodi perini.dav...@dpsoftware.org wrote:
ah ah... it's incredible...
I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian.
I can use preprocessing on every platform...
How can you develop on a mobile without preprocessing? Sure android is
really good for fart app,
but what else?
I don't want to troll but I really can't understand why I heard many
developers saying viva android when
google released the first buggy SDK.
On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote:
On Sat, Jul 31, 2010 at 10:25 AM, sblantipodi
perini.dav...@dpsoftware.orgwrote:
is there some sort of preprocessing in eclipse using android?
No.
I haven't understood if this is a lack of netbeans or it is a lack of
android.
It's a lack of Java. Preprocessing, specifically the #ifndef notation you
mention, is a C/C++ thing.
-
TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago
transit tracking app for Android-powered devices
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Android preprocessor, //#ifdef...
I have post already .May be it not approved by moderator,.. so plz help me Dear ALL, I have window based machine.I want to learn Android Development. I have read tutorial. i have installed eclipse-jee-helios-win32-x86_64 .but i have not found Android Plug in. so can anybody tell which version of Eclipse i need to start Android Development Environment? Just tell me Eclipse verison.. after that i will download Android SDK. Muhammad Bilal Ilyas Software Engineer From: sblantipodi perini.dav...@dpsoftware.org To: Android Developers android-developers@googlegroups.com Sent: Sun, August 1, 2010 1:27:39 AM Subject: [android-developers] Re: Android preprocessor, //#ifdef... Ok but other java software/platform supports preprocessor on both Eclipse/Netbeans/IntelliJ/JDE ecc. ecc... On Jul 31, 10:15 pm, Kostya Vasilyev kmans...@gmail.com wrote: The absence of preprocessor has to do with Java, not Android. And tlhere is a lot of Java software out there... -- Kostya Vasilyev --http://kmansoft.wordpress.com 01.08.2010 0:00 пользователь sblantipodi perini.dav...@dpsoftware.org написал: ah ah... it's incredible... I develop on Windows Mobile, JavaME, Bada, Blackberry, Symbian. I can use preprocessing on every platform... How can you develop on a mobile without preprocessing? Sure android is really good for fart app, but what else? I don't want to troll but I really can't understand why I heard many developers saying viva android when google released the first buggy SDK. On Jul 31, 8:22 pm, TreKing treking...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:25 AM, sblan... perini.dav...@dpsoftware.orgwrote: is there some sort of preprocessing in eclipse using android? No. I haven't understo... TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are su... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
