Re: [fpc-devel] encoding for file names in fpc messages
Am 28.12.2011 15:55, schrieb Mattias Gaertner: Hi, What encoding does fpc use for file names in messages? System encoding for 8 bit strings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] JVM: Question regarding converted Java code
On 28 Dec 2011, at 23:28, Sven Barth wrote: 1) as it seems to be a rather usual practice in Java, would it be possible to disable the Constructor should be public warnings if the target cpu is the JVM? Yes. 2) in the code I converted the classes often seem to reintroduce methods that are available in parent classes or implemented interfaces with different result types without declaring the original method though. === Pascal source begin === OBLocation = class external 'org.bukkit' name 'Location' (JLObject, JLCloneable) public ... function clone(): OBLocation; overload; virtual; ... // = other functions between function clone(): JLObject; overload; virtual; // throws java.lang.CloneNotSupportedException end; === Pascal source end === Is this indeed correct? Does the compiler (or the JVM) indeed call the correct function in the end (in this case org.bukkit.Location.clone)? The Java language does not support overloading based on result type, just like FPC. The JVM bytecode specs do allow it though, which enabled Sun to allow overriding an inherited method with a method that returns a child type of the original result type. They do this by automatically also generating a method with the original return type, which simply calls the newly added method (since the child type can be implicitly converted to the original type, this is no problem). That way, regardless of which method is called, the correct code is always executed. This is required for correct operation because if, in your example, you would assign the OBLocation instance to a JLObject variable and then call its clone method (assuming for a moment that clone would be public in JLObject), javacc would generate code to call the clone-variant that returns JLObject rather than OBLocation (since JLObject does not declare clone with an OBLocation result type). The warning in this case should probably be demoted to a hint in case of external classes, because for simplicity reasons javapp does not check for each method whether it is overriding method in a parent class or not. That is already done in most cases, but not for this particular case, apparently. It's strange that the clone():JLObject method apparently does not get a synthetic attribute in the class file (otherwise javapp would skip it), because that's normal for compiler-generated routines. Jonas PS: There's currently a bug in the JVM compiler in that it also allows you to override functions with ones that have a different return type, but it doesn't automatically generate overridden methods using the original return type to redirect them to the new one.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] JVM: Question regarding converted Java code
On Thu, Dec 29, 2011 at 10:49 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 28 Dec 2011, at 23:28, Sven Barth wrote: 1) as it seems to be a rather usual practice in Java, would it be possible to disable the Constructor should be public warnings if the target cpu is the JVM? Yes. BTW, is there anything you dislike about Java constructor model? ;-) (i.e. must call some inherited constrcutor, constructor can be - enforced - private, default public constructor if none declared, etc) Best regards, Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] JVM: Question regarding converted Java code
On 29.12.2011 13:49, Jonas Maebe wrote: On 28 Dec 2011, at 23:28, Sven Barth wrote: 1) as it seems to be a rather usual practice in Java, would it be possible to disable the Constructor should be public warnings if the target cpu is the JVM? Yes. This would be nice :) 2) in the code I converted the classes often seem to reintroduce methods that are available in parent classes or implemented interfaces with different result types without declaring the original method though. === Pascal source begin === OBLocation = class external 'org.bukkit' name 'Location' (JLObject, JLCloneable) public ... function clone(): OBLocation; overload; virtual; ... //= other functions between function clone(): JLObject; overload; virtual; // throws java.lang.CloneNotSupportedException end; === Pascal source end === Is this indeed correct? Does the compiler (or the JVM) indeed call the correct function in the end (in this case org.bukkit.Location.clone)? The Java language does not support overloading based on result type, just like FPC. The JVM bytecode specs do allow it though, which enabled Sun to allow overriding an inherited method with a method that returns a child type of the original result type. They do this by automatically also generating a method with the original return type, which simply calls the newly added method (since the child type can be implicitly converted to the original type, this is no problem). That way, regardless of which method is called, the correct code is always executed. This is required for correct operation because if, in your example, you would assign the OBLocation instance to a JLObject variable and then call its clone method (assuming for a moment that clone would be public in JLObject), javacc would generate code to call the clone-variant that returns JLObject rather than OBLocation (since JLObject does not declare clone with an OBLocation result type). Thank you for explaining this. The warning in this case should probably be demoted to a hint in case of external classes, because for simplicity reasons javapp does not check for each method whether it is overriding method in a parent class or not. That is already done in most cases, but not for this particular case, apparently. It's strange that the clone():JLObject method apparently does not get a synthetic attribute in the class file (otherwise javapp would skip it), because that's normal for compiler-generated routines. According to http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#80128 it should be rather easy to see whether a class file contains a synthetic method, right? So a cat classfile | grep -i synthetic should be sufficient? If so then there is indeed no such synthetic attribute used in that class... PS: There's currently a bug in the JVM compiler in that it also allows you to override functions with ones that have a different return type, but it doesn't automatically generate overridden methods using the original return type to redirect them to the new one. Thank you for the warning. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] -Oodfa
Florian wrote at http://bugs.freepascal.org/view.php?id=20907 FPC has a good enough dfa, however it is only activated when compiling with -Oodfa: c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa Is that documented somewhere ? Is that production read or beta? fpc -i only lists: Supported Optimizations: REGVAR UNCERTAIN STACKFRAME PEEPHOLE ASMCSE LOOPUNROLL TAILREC CSE Supported Whole Program Optimizations: All DEVIRTCALLS OPTVMTS SYMBOLLIVENESS ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
