On 14/04/2019 22:08, Ryan Joseph wrote:
Per my example, currently we know that GetThing() COULD return nil so unless we
know what the function does by reading the documentation or looking at the
implementation we need to test for nil. Right? I suggest the modifier simply to
enforce that
Dear specialists,
Is it possible to call .so library when I have used Free Pascal
compiler and I have set JVM target and option to create Android
compatible Java classes?
Because when ever I want to call some .so library I Am getting The
following error.
Failed resolution of: .so
OK
Sure,
> On Apr 14, 2019, at 6:30 PM, Martin Frb wrote:
>
> I would actually argue that it is infinitely more important to check for nil
> after MakeThing. (Unless I know for sure it is not needed: proof, docs)
>
> Assuming (taking the danger of doing so) both do what there name indicates,
> then:
Am 15.04.2019 um 03:35 schrieb wkitt...@windstream.net:
On 4/14/19 7:28 AM, Rainer Stratmann wrote:
On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote:
E.g. i have a loop which test each s[i] char for several cases: 'a',
'b', 'c'.
for i:= 1 to length(s) do
if (s[i]='a') or (s[i]='b')
On 14/04/2019 19:53, Ryan Joseph wrote:
On Apr 14, 2019, at 1:38 PM, Sven Barth via fpc-pascal
wrote:
As already said by Martin: the compiler *can not* determine all cases whether
the parameter is Nil or not, so it *must* be done at runtime to ensure this.
Otherwise the feature is just as
> On Apr 14, 2019, at 3:38 PM, Martin Frb wrote:
>
>
> One thing is what checks can be done, to help the programmer not to
> accidentality de-ref nil.
> The other thing is how.
>
> 1) The "optional" is actually the default. If anything towards a deref-warn
> feature was done, then *every*
On 4/14/19 9:08 AM, Anthony Walter wrote:
Someone said:
"You can do a {$i mysettings.inc}"
I give that a +1
FWIW: all of the delphi code that i've worked with trying to port to FPC has had
this... at least one had an include file that IFDEF'd its way through like 4 or
5 other pascal
On 15/04/2019 00:53, Ryan Joseph wrote:
Here’s what I imagine that would look like:
procedure CreateHero (name: string; hp: integer);
requires
name <> '';
(hp > 0) and (hp < 100);
begin
// compilers parses the conditions and inserts as if statements:
// if name <> ‘’ then
//
On 14/04/2019 23:48, Martin Frb wrote:
I admit the contract/assert stuff may have made it seem different. But
that is because this approach does not hold up (IMHO). And therefore
the closest alternative was presented.
In the very end it is to avoid crashing on nil de-ref. And the
On 4/14/19 7:28 AM, Rainer Stratmann wrote:
On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote:
E.g. i have a loop which test each s[i] char for several cases: 'a',
'b', 'c'.
for i:= 1 to length(s) do
if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...
Can FPC optimize it so it only
On 14/04/2019 22:08, Ryan Joseph wrote:
function FindThing: TThing; optional;
means you MUST check for nil. If the value is nil that’s not an error.
“optional” is probably a bad name for this I know.
function MakeThing: TThing;
this means maybe check for nil or maybe not
On 15/04/2019 01:19, Ryan Joseph wrote:
On Apr 14, 2019, at 7:08 PM, Martin Frb wrote:
Almost. assert takes the condition itself
assert(condition_that_must_be_true, 'error message')
so it would be
assert(name<>'', 'requires "name <> " failed for CreateHero');
You can already insert
> On Apr 14, 2019, at 7:08 PM, Martin Frb wrote:
>
> Almost. assert takes the condition itself
>
> assert(condition_that_must_be_true, 'error message')
>
> so it would be
> assert(name<>'', 'requires "name <> " failed for CreateHero');
>
> You can already insert such asserts yourself.
On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote:
> E.g. i have a loop which test each s[i] char for several cases: 'a',
> 'b', 'c'.
>
> for i:= 1 to length(s) do
>
> if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...
>
> Can FPC optimize it so it only reads s[i] once (to register),
Someone said:
"You can do a {$i mysettings.inc}"
I give that a +1
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Am 13.04.2019 um 21:55 schrieb Ralf Quint:
On 4/13/2019 12:30 PM, Alexey Tor. wrote:
E.g. i have a loop which test each s[i] char for several cases: 'a',
'b', 'c'.
for i:= 1 to length(s) do
if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...
Can FPC optimize it so it only reads s[i] once (to
Ryan Joseph schrieb am So., 14. Apr. 2019,
00:17:
>
>
> > On Apr 13, 2019, at 6:01 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Well, there is Oxygene's concept of Class Contracts (see
> > https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
>
Am 14.04.2019 um 04:07 schrieb Ben Grasset:
> I dunno about setting them globally, but generally I do find modeswitches
> rather annoying, as the combination of
> features is pretty arbitrary, and they mostly just *disallow* things that
> couldn't break the code of people who weren't
> using
> On Apr 13, 2019, at 10:07 PM, Ben Grasset wrote:
>
> E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad
> that {$mode ObjFPC} does not allowed advanced records. It would be
> specifically bad if it did!" because it just doesn't matter if they weren't
> using
> On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
> wrote:
>
> Your idea requires exceptions as well. The compiler is not capable checking
> whether valid entries are passed in at compile time except for simple,
> constant cases, so runtime checks are needed and the only way to abort
On 14/04/2019 17:03, Ryan Joseph wrote:
On Apr 13, 2019, at 10:07 PM, Ben Grasset wrote:
E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that
{$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it
did!" because it just doesn't
On 14/04/2019 16:05, Ryan Joseph wrote:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable checking
whether valid entries are passed in at compile time except for simple, constant
cases, so runtime checks are
On 14/04/2019 18:04, Martin Frb wrote:
On 14/04/2019 16:05, Ryan Joseph wrote:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable
checking whether valid entries are passed in at compile time except
for simple,
Am 14.04.2019 um 17:03 schrieb Ryan Joseph:
On Apr 13, 2019, at 10:07 PM, Ben Grasset wrote:
E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that
{$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it
did!" because it just doesn't
Am 14.04.2019 um 04:07 schrieb Ben Grasset:
I dunno about setting them globally, but generally I do find
modeswitches rather annoying, as the combination of features is pretty
arbitrary, and they mostly just *disallow* things that couldn't break
the code of people who weren't using those
Am 14.04.2019 um 16:05 schrieb Ryan Joseph:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable checking
whether valid entries are passed in at compile time except for simple, constant
cases, so runtime checks are
> On Apr 14, 2019, at 1:38 PM, Sven Barth via fpc-pascal
> wrote:
>
> As already said by Martin: the compiler *can not* determine all cases whether
> the parameter is Nil or not, so it *must* be done at runtime to ensure this.
> Otherwise the feature is just as useful as this:
I’ve read
> On Apr 14, 2019, at 1:29 PM, Sven Barth via fpc-pascal
> wrote:
>
>> I like what Jonas did for the ObjC mode switch where he named them with
>> versions. Maybe a {$mode objfpc2} one day.
> My idea was to maybe add a mode ObjFPCExt or ObjFPCAdv which is quite a bit
> less conservative and
28 matches
Mail list logo
