On Wednesday 18 July 2018 23:30:19 Ben Grasset wrote:
>
> For example, does *anyone *actually think the strange "lowercase
> everything" capitalization style the compiler uses is "readable" nowadays?
Yes.
Martin
___
fpc-pascal maillist - fpc-pascal@li
On Wed, 18 Jul 2018 21:26:05 -0400
Ben Grasset wrote:
> This is a massive oversimplification. Many *modern* game engines do not
> even have the kind of loop you're thinking of.
Please tell me where I can read up about those engines without cyclic executive?
Are those engines interrupt driven or h
Hello everybody,
The discussion in this thread seems to be endless and arguments are
repeating over and over. Moreover, some of the words and statements having
appeared in certain posts are better avoided in polite communication.
Everybody, please, think twice whether your post adds value (repetit
Yawn, more F.U.D.
On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski wrote:
> On Wed, 18 Jul 2018 16:12:41 -0600
> Ryan Joseph wrote:
>
> > Personally for my taste I would like to just add a little keyword to the
> end of the variable so I don’t have to worry about it later.
>
> 1) little, innoc
> For high performance in a game engine you should not allocate/deallocate
memory in the game loop at all (can be done, have done it*, so no arguing
there).
This is a massive oversimplification. Many *modern* game engines do not
even have the kind of loop you're thinking of.
> Outside the game
On Wed, 18 Jul 2018 16:12:41 -0600
Ryan Joseph wrote:
> Personally for my taste I would like to just add a little keyword to the end
> of the variable so I don’t have to worry about it later.
1) little, innocent deallocation feature A
2) other user comes along: "We already have A, can it be imp
On Wed, 18 Jul 2018 15:39:58 -0600
Ryan Joseph wrote:
> 1) For high performance situations it really does matter... I was
> doing a game engine recently and doing the create/free thing when I knew I
> didn’t have to was painful.
For high performance in a game engine you should not allocate/de
On Wed, 18 Jul 2018 14:33:51 -0600
Ryan Joseph wrote:
> They probably wanted something like this:
>
> n := if x <> 0 then 10 else 20;
>
> Not too crazy in my opinion.
Only if you think that changing a statement to an expression is not 'too crazy'.
Btw in Kotlin if is an expression:
val n = if
> On Jul 18, 2018, at 4:01 PM, Ben Grasset wrote:
>
> Well, the array TFPGList uses for storage would still be allocated on the
> heap in any case no matter what…
That’s true but the other part remains true.
Here’s from the FPC compiler itself. sc is declared at the top and ~400 lines
later
> On Jul 18, 2018, at 3:05 PM, Sven Barth via fpc-pascal
> wrote:
>
> You have to keep in mind the history here. The "object" type is from Turbo
> Pascal times and back then it already showed its weaknesses. Then along came
> Delphi and Borland decided to introduce a brand new object model b
Well, the array TFPGList uses for storage would still be allocated on the
heap in any case no matter what...
On Wed, Jul 18, 2018 at 3:10 PM, Ryan Joseph
wrote:
>
>
> > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > A point against sta
Ironically, type safety is a good argument for the further development of
various generics related things. Yet unfortunately I don't think anyone is
going to stop using the Contnrs unit in new code anytime soon...
___
fpc-pascal maillist - fpc-pascal@li
The "I might have to read code I don't like" argument people seem to keep
resorting to comes off as rather childish, frankly. It's entirely
subjective and specific to each person.
For example, does *anyone *actually think the strange "lowercase
everything" capitalization style the compiler uses is
On Wed, Jul 18, 2018 at 4:08 PM, Sven Barth via fpc-pascal
wrote:
> R0b0t1 schrieb am Mi., 18. Juli 2018, 21:46:
>>
>> On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph
>> wrote:
>> >
>> >
>> >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal
>> >> wrote:
>> >>
>> >> And to give you a slight
On Wed, Jul 18, 2018 at 3:57 PM, Sven Barth via fpc-pascal
wrote:
> Ryan Joseph schrieb am Mi., 18. Juli 2018,
> 21:37:
>>
>>
>>
>> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal
>> > wrote:
>> >
>> > And to give you a slightly different example: around a year ago or so I
>> > impleme
R0b0t1 schrieb am Mi., 18. Juli 2018, 21:46:
> On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph
> wrote:
> >
> >
> >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >>
> >> And to give you a slightly different example: around a year ago or so I
Ryan Joseph schrieb am Mi., 18. Juli 2018,
21:41:
>
>
> > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > A point against stack based classes is that Object Pascal's object model
> is highly geared towards polymorphism (with things like
Ryan Joseph schrieb am Mi., 18. Juli 2018,
21:37:
>
>
> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > And to give you a slightly different example: around a year ago or so I
> implemented a IfThen() intrinsic that works like the if-s
> On Jul 18, 2018, at 1:46 PM, R0b0t1 wrote:
>
> You can make the function yourself. That you may have problems with
> typing are indicative that the language could use a more expressive
> type system, not that it was a good idea to create an intrinsic that
> could (potentially) ignore types.
On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph wrote:
>
>
>> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal
>> wrote:
>>
>> And to give you a slightly different example: around a year ago or so I
>> implemented a IfThen() intrinsic that works like the if-statement, but as an
>> expressi
> On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal
> wrote:
>
> A point against stack based classes is that Object Pascal's object model is
> highly geared towards polymorphism (with things like virtual class methods
> and constructors that C++ does not support). You can't make use of
> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal
> wrote:
>
> And to give you a slightly different example: around a year ago or so I
> implemented a IfThen() intrinsic that works like the if-statement, but as an
> expression (like C's trinary ?: operator including not evaluating th
Am 17.07.2018 um 12:07 schrieb Michael Van Canneyt:
If of course you write routines of several hundreds of lines (or
thousands),
then you probably would need to have such a feature.
But I would fire any programmer that writes such code anyway, since it
indicates he cannot think structured.
Ryan Joseph schrieb am Mi., 18. Juli 2018,
19:00:
>
>
> > On Jul 18, 2018, at 7:14 AM, Ben Grasset wrote:
> >
> > Classes are unsuitable performance-wise for many use cases, and TP
> objects lack important features such as variant parts. Advanced records are
> a great lightweight in-between poin
Ryan Joseph schrieb am Mi., 18. Juli 2018,
19:15:
>
>
> > On Jul 17, 2018, at 2:41 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > There is a more important difference: the developers and the users. Only
> because the latters think an idea is good or probable the
Dennis schrieb am Mi., 18. Juli 2018, 19:01:
> Thanks.
>
> So the following will give an address+frame of the calling routine ?
> get_caller_addr(get_frame), get_caller_frame(get_frame)
>
As long as you pass it to the "raise ... at", yes.
Regards,
Sven
>
_
> On Jul 17, 2018, at 2:41 PM, Sven Barth via fpc-pascal
> wrote:
>
> There is a more important difference: the developers and the users. Only
> because the latters think an idea is good or probable the former do not
> necessarily need to agree. And don't forget that we, the developers work
Thanks.
So the following will give an address+frame of the calling routine ?
get_caller_addr(get_frame), get_caller_frame(get_frame)
Dennis
Sven Barth via fpc-pascal wrote:
Dennis mailto:de...@avidsoft.com.hk>> schrieb
am Mi., 18. Juli 2018, 17:19:
The following delphi code when com
> On Jul 18, 2018, at 7:14 AM, Ben Grasset wrote:
>
> Classes are unsuitable performance-wise for many use cases, and TP objects
> lack important features such as variant parts. Advanced records are a great
> lightweight in-between point.
Yes indeed. Not being able to allocate classes on the
> On Jul 18, 2018, at 5:08 AM, Giuliano Colla
> wrote:
>
> I have not yet seen the proposal to get rid of begin/end and replace it with
> indentation level, but it appears to be just a matter of time!
I’ve never heard of a single proposal to change the fundamentals of Pascal,
only to extend
Il 18/07/2018 17:19, Dennis ha scritto:
The following delphi code when compiled by FPC, raised these errors:
Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
Errors: 10, Warnings: 2
StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
StrBuffer.pas(100,23) Error: Assemble
Dennis schrieb am Mi., 18. Juli 2018, 17:19:
> The following delphi code when compiled by FPC, raised these errors:
> Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
> Errors: 10, Warnings: 2
> StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
> StrBuffer.pas(100,23) Erro
The following delphi code when compiled by FPC, raised these errors:
Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
Errors: 10, Warnings: 2
StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
StrBuffer.pas(100,23) Error: Assembler syntax error in operand
StrBuffer.pas(100
They observably *are* good though, now that they've been implemented,
especially in combination with management operators. These are features
that objectively make FPC better. I'm unsure what the original concern
could have even possibly been, other than some vague notion of "well,
records didn't h
Il 17/07/2018 23:40, Tomas Hajny ha
scritto:
Indeed - please, everybody make sure to keep the discussion on this list
on topic, this thread doesn't belong to this list.
You are perfectly right that the discussions on this list should
be kept on topic
35 matches
Mail list logo
