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 features to begin with if they were allowed.
E.G, I s
Perhaps there could be the opposite modifier, so the function cannot be called
with nil. Like
Interesting idea but I’d have to think about it more to know if this is a real
problem I’ve ever experienced.
for example, I store some interfaces in a list, and just replaced the
default list with
On 14/04/2019 00:01, Sven Barth via fpc-pascal wrote:
Well, there is Oxygene's concept of Class Contracts (see
https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
anything in that direction would be done I'd be inclined towards their
syntax (and I've played with the idea to imple
Hi,
Or perhaps it is better to use gvector rather than TInterfaceList?
If you only store a specific interface type then using one of the
generic containers specialized to that type would indeed be best.
and on a closer look TInterfaceList does a lot of locking.
guess TInterfaceList
> On Apr 13, 2019, at 6:01 PM, Sven Barth via fpc-pascal
> wrote:
>
> Well, there is Oxygene's concept of Class Contracts (see
> https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
> anything in that direction would be done I'd be inclined towards their
> syntax (and I've playe
On 4/13/19 11:39 PM, Martin Frb wrote:
> On 13/04/2019 23:17, Ryan Joseph wrote:
>> If there was any other way the compiler could make this contract more
>> concrete and reliable then comments I’d be happy to hear it.
>
> I don't know what others think of it, but
> https://en.wikipedia.org/wiki/De
On 13/04/2019 23:17, Ryan Joseph wrote:
If there was any other way the compiler could make this contract more
concrete and reliable then comments I’d be happy to hear it.
I don't know what others think of it, but
https://en.wikipedia.org/wiki/Design_by_contract
look at pre/post-conditions.
It
> On Apr 13, 2019, at 5:11 PM, Martin Frb wrote:
>
> Were it only the documentation of nil-ability then comments would do the job.
> When it is about a more generic approach then see the wikipage about
> contracts. (I did mail a link)
If there was any other way the compiler could make this co
On 13/04/2019 22:34, Ryan Joseph wrote:
I can find many hundreds of examples like the one above in the Cocoa frameworks
since Apple retroactively added them in. I don’t understand why you think this
is a minor subset of cases.
That "minor set" referred to compiler warnings you get, inside a
f
> On Apr 13, 2019, at 3:58 PM, Martin Frb wrote:
>
> You misread me. I am sure inadvertently, but still. You advertised that this
> feature you desire was to fulfil two purposes. One of which you named to be
> documentation. Or as you described, the elimination of the need to look
> through
On 13/04/2019 21:07, Ryan Joseph wrote:
Already today the author could add a comment (even pasdoc) to the declaration.
And it serves the same effect.
Sure, if it’s not used then it’s not very helpful. :) Comments are the same
effect? Then why not prefer comments for “const” params or even pu
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 register), not 3
times?
How about writin
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), not 3 times?
--
Regards,
Alexey
__
> On Apr 13, 2019, at 2:45 PM, Martin Frb wrote:
>
> Well that doesn't work. Unless you wrote pthread_create (or whatever other
> function).
> Because the "opitonal" parameter (which really only serves as documentation
> hint) is itself optional.
> So if the author of the code that you intend
On 13/04/2019 19:04, Ryan Joseph wrote:
Ok, here’s a historic real work example which is all too common:
int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void
*(*start_routine) (void *), void *arg);
Can you pass null for attr? Well you need to read the man page and read th
> On Apr 13, 2019, at 12:40 PM, Benito van der Zander
> wrote:
>
> Hi,
>
> the parameter is already optional without any modifier, since you can always
> pass nil for it.
Sorry I must be doing a bad job explaining this and the naming of “optional”
seems to be confusing since it conflicts w
On 13/04/2019 18:40, Benito van der Zander wrote:
Hi,
the parameter is already optional without any modifier, since you can
always pass nil for it.
Perhaps there could be the opposite modifier, so the function cannot
be called with nil. Like
procedure DoThis(nonnil var obj: TObject);
and t
Hi,
the parameter is already optional without any modifier, since you can
always pass nil for it.
Perhaps there could be the opposite modifier, so the function cannot be
called with nil. Like
procedure DoThis(nonnil var obj: TObject);
and then you need to check if it is nil, before calling
> On Apr 13, 2019, at 11:37 AM, Anthony Walter wrote:
>
> What's wrong with ...
>
> procedure FreeThis; overload;
> begin
> end;
>
> procedure FreeThis(var obj: TObject); overload;
> begin
> end;
>
> There, now you have an optional argument with a var reference.
>
Maybe my example wasn’t ve
What's wrong with ...
procedure FreeThis; overload;
begin
end;
procedure FreeThis(var obj: TObject); overload;
begin
end;
There, now you have an optional argument with a var reference.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://
Marco van de Voort schrieb am Fr., 12. Apr.
2019, 20:56:
>
> Op 2019-04-12 om 17:23 schreef Ryan Joseph:
> >
> > What do you think of that? Sounds like an easy way to get some support
> for nil pointers deref’s and provides self documenting code.
>
> I think the same as when I read the suggestion
21 matches
Mail list logo
