I'm working with a PascalScript innosetup installer, and I fail to see where the control of the following block is flowing.
function Foo(): String;
begin
Result := 'foo';
RaiseException('...');
end;
procedure Test();
var
Z : String;
begin
Z := '';
try
Z := Foo();
except
Log(Z);
end
end;
My installer seems to indicate Z is being set with the Result of the Foo function. My understanding of exceptions in 'most' programming languages tells me the assignment Z := Foo() should not happen in case of exception.
When the Foo function raises, should Z still be assigned to?
Probably it handles result values by reference as implicit first argument. But then this can happen. It could be considered a legal of certain codegeneration/optimization, since it is quite a common way of handling return values.
However what is exactly defined in Object Pascal outside testing what Delphi does is murky territory, since there is only a x86 and x86_64 implementation. And Delphi will return the value in eax, so if you follow that logic this is illegal.
added later:
I tested Delphi with structured types, and while it passes a reference, it creates a copy on the stack to pass it.
This could make it hard to optimize code with structured types though, but a modifier/attribute to declare the return type const could fix that if ever needed.
In Delphi, strings as result values are treated like var parameters. In other words, a function like Foo is in fact compiled as:
procedure Foo(var Result: string);
begin
Result := 'Foo';
RaiseException(...);
end;
This means that Z (through the reference parameter) is assigned the value 'Foo' immediately, i.e. before the exception is raised.
In other words, the function result is not just kept in a local variable called Result and then returned when the function ends -- which would be prevented by the exception -- it is assigned immediately.
I assume this is exactly what happens in PascalScript as well.
Related
In Delphi is there a way to declare a procedure as an alias of another?
Something like:
function AnAliasToUpperCase(const S: AnsiString): AnsiString = system.AnsiStrings.UpperCase;
and later in the program calling AnAliasToUpperCase or UpperCase must be exactly the same.
Defining it e.g. like a constant declaration:
const
AliasToUpperCase: function(const S: AnsiString): AnsiString = System.AnsiStrings.UpperCase;
might work for your needs.
The proper answer to the question "How to make an alias to a function/procedure" is "You can't".
But there are two workarounds to simulate this which both might introduce a bit of overhead - the first is the const as shown in the other answer.
Additionally to declaring it as const you can also declare it as new inline routine:
function AliasToUpperCase(const S: AnsiString): AnsiString; inline;
begin
Result := System.AnsiStrings.UpperCase(S);
end;
But then you are depending on the compiler settings for inlining and need to also add the AnsiStrings unit to wherever you are calling AliasToUpperCase or you will get the H2443 Inline function has not been expanded because unit is not specified in USES list warning.
For this function signature it works but for other return types you might suffer from missing return value optimization and have extra value copies.
So I'm just starting to learn Eiffel. One of the first exercises in the book I'm using says to make a function that does base^exp without using ^. I've copied my code below.
class
APPLICATION
inherit
ARGUMENTS
create
make
feature {NONE} -- Initialization
make
-- Run application.
do
create power(2;3)
printf("2 to the power of 3 is " + answer)
end
power(base : REAL; exp : INTEGER) : REAL
-- computers base raised to the bower of exp without using ^
local
remain : INTEGER
do
remain := exp
if remain = 0 then
result := 1
else
from
until
remain = 0
loop
result := result * result
remain := remain -1
end
end
end
end
How do I use this? Do I need it on the same level as feature{NONE}'s make? I know how I'm calling it is wrong, and I can't find anything in the chapter I just read, or online on how to pass parameters into it or how to use it's results.
There are several issues with the original code:
create is used to create an object, but you are not going to create anything, but to get a result of a computation of the function power by calling it. Therefore the keyword create is not needed.
You are using an entity answer to report the result of evaluation on a screen. However it is not declared anywhere. I believe the proper place would be a local variable declaration section.
The entity answer is not initialized to the result of the function power. This is usually done by an assignment instruction.
Feature arguments are separated by a comma, not by a semicolon.
From the original code it's unclear what is the type of the variable answer. Assuming it matches the type of the function power, before adding it to a string, it needs to be converted to a string. This is done by calling the feature out.
The standard feature for printing a string to a console is print, not printf.
Combining the critical points above, we get
make
-- Run application.
local
answer: REAL
do
answer := power(2, 3)
print ("2 to the power of 3 is " + answer.out)
end
After that the code can be compiled. Now less critical points:
It is a good style to put features to a dedicated feature clauses, so I would add a line like feature -- Basic operations before the feature power.
The implementation of the feature power has at least two problems. I'm not going to detail them here, but would give two hints instead:
by default numeric Result is initialized to 0, this needs to be taken into account for operations that use it without first assigning any other value
even though an argument base is passed to the function power it remains unused in the original version of the code
I'm new to Free Pascal and Lazarus. I'm testing out the new "advanced records" feature and getting what looks to be an unnecessary compiler warning.
The code is very simple, just a record with a single method to initialize the data fields. Something like:
{$mode delphi}
type TTest =
record
a,b: double;
procedure Init(x,y: double);
end
procedure TTest.Init(x,y: double);
begin
test.a := x;
test.b := y;
end;
var t: TTest;
begin
t.Init(0.1,0.2);
That last line shown, "t.Init()", always generates a compiler warning that 'variable "t" does not seem to have been initialized'.
Ok it's only warning, so obviously I can live with it, but I just want to make sure it's not due to some underlying misunderstanding on my part.
EDIT to add new information.
Re the Method verus Constructor point.
Looking into this some more I'm kind of glad that FPC doesn't allow constructors for records. Delphi has constructors but no destructors, and as far as I can tell constructors (for records) do absolutely nothing that a method couldn't do. I'm a minimalist, so to me there is no point to have extra syntax that does nothing more than some existing syntax does.
Particularly for a simple record like this, the very act of declaring it (var t: TTest) does all the "constructing" that this record needs. Anything else (like my Init) is just setting values, it's not constructing anything anyway. So as far as I can see constructors are not the answer, the compiler just needs to drop the warning.
Researching the issue I have come across one other technique that is often used, the so called "factory function". That is, a function outside of the record such as:
function InitTTest(x,y: double): TTest;
begin
Result.a := x;
Result.b := y;
end;
This technique does indeed work, and gets rid of the warning message. I don't like this method however and I wont use it. Advanced records don't have inheritance and other features of classes, encapsulation is all they've got going for them. So I really dislike having to make a "factory function" outside of the record like this.
Please bear in mind the the above is just the opinion of a "noob", after doing just a little research to answer my own question here. So if I'm wrong about anything above I'm quite happy to be corrected. :)
Yes, that is what constructors are for, the following compiles with FPC trunk and produces no warnings:
{$mode delphi}
type TTest =
record
a,b: double;
constructor Init(x,y: double);
end;
constructor TTest.Init(x,y: double);
begin
a := x;
b := y;
end;
var t: TTest;
begin
t.Init(0.1,0.2);
end.
Learning Ada and trying to make a stack ADT and I'm using this webpage to figure it out.
http://www.functionx.com/ada/Lesson06.htm
eightqueens.adb
with Ada.Text_IO;
use Ada.Text_IO;
with Stack;
use Stack;
procedure EightQueens is
begin
put_line ("awd");
end EightQueens;
stack.ads
package Stack is
function awd () return Integer;
end Stack;
stack.adb
package body Stack is
function awd () return integer is
begin
return 1;
end awd;
end Stack;
Error is
stack.ads:2:19: identifier expected
I'm most certain I did everything correctly.
Ada doesn't use empty parentheses, either for defining or for calling functions or procedures.
And for future reference, the phrase "I'm most certain I did everything correctly." is a red flag indicating that you've almost certainly done something wrong.
Just to elaborate, there are some syntactic decisions that Ada made that IMHO are superior to what you may be used to from C-syntax languages.
Functions with no parameters don't use empty parenthesis in their calls. This allows you to change a contant to a function call without having to recode any of the clients.
Arrays use parentheses like function calls do, rather than some unique syntax. This allows you to change an array constant to a function call without having to recode any of the clients.
To look at it another way, a constant is just a simplified version of a parameterless function, for when you can get away with always returning the same value. Likewise, a constant array is a simplified version of a parametered function call, for when you can get away with always returning the same value. If you later discover you need a more complex implementation, that's not the client's concern, and should not affect their code.
I assume this question is language agnostic, and apologies if it's quite rudimentary, but say we have (PHP in this example)
function myFunc() {
return 4;
}
Now when this function is called, usually the result will be used in an expression or be assigned to a variable. But if it's not assigned to a variable, where does the return value "live" when it's been called? Is there an internal structure that keeps it in memory for the purpose of the current statement, and when that statement is executed, it removes it again?
If you just do something like:
var foo = bar();
myFunc();
var wibble = baz();
Then a Number 4 will be created for the return statement, then immediately will be discarded as there aren't any references to it.
(Note: C++ specific) In most cases compiler will user Return Value Optimisation and store value in the variable that gets the result of the function assigned to.
For example:
int myInt = myFunc();
will cause the pointer to myInt varaible to by passed to myFunc on the stack so myFunc will work directly with myInt without creating a new variable.
Otherwise the function returns by placing the return value on the stack.
I think in .NET it's called Name Return Value Optimization.
Other compilers probably have similar features in place.
so say we had a more complex statement like myFunc() + ComplexFunction()
I think this one depends on the compiler and it's register allocation scheme.
The compiler could store the result for myFunc() in a register, then jump to execute ComplexFunction(). On entering ComplexFunction(), the registers would be saved on the stack and the restored when returning.