indexind pointer

[Laur]

@Laur:
As already shown you can do exactly the same in/with pascal as you can do in c. Since that is not landing properly that can only mean one thing. So stop bothering us and stay using c/c++ or whatever language that is faster and easier to use according to your believes because quite frankly we (or at least I) am not in the habit of wasting time convincing someone that does not want to be convinced that his/her believes are wrong.

All the brave talks but still not a single line of code from your hands for comparison... thus yet another hot air balloon..

Make the test.:
my pointers vs your dynamics arrays.

I provide very big lost of pas, why?
simply, because fp is for beginers mainly/only.

Def: a beginner in programming is someone who has no idea how computers work.

[Martin_fr]

I don't see code of these 'dynamic' arrays, then I can't say how big is overhead..
probably very big - 10 times slower than pointers?

Make test.

You picked the wrong part of my message to reply to, or at least if you care how I perceive your answer.

I offered you (by implication) advice on speed, when I told you that your approach of indexing pointers may be slower than other methods (and that actually could be big time slower). Though as I indicated, it depends on the use case.
Naturally, I am now wondering why you don't take up the part of my reply that actually is about writing fast code. But you will have your reasons...

==========
About "make a test": That depends a lot on the code surrounding the index access. How many blocks of memory, how many pointers and arrays, how often do they change? Or just the index access?

Even then, tests are never accurate. Modern CPU have optimization that can change speed depending on seemingly unrelated code.

=========

Btw, you original question didn't mention speed, but to answer it quite simple and brief: yes indexing pointers is allowed (using the right compiler settings)

Do you want to know if it is advisable, or when and in which cases it is or isn't?
Do you want to know if there are even faster methods?

[TRon]

Make the test.:

You are questioning the results that FPC produces against some unwritten c code that i have to make up. So, no thank you.

my pointers vs your dynamics arrays.

Good luck with your safe programming on multidimensional arrays 

I provide very big lost of pas, why?

Then I must have missed it. Where exactly are the benchmarks posted together with their code that produced the results ?

simply, because fp is for beginers mainly/only.

And somehow that has to convince me that you are .... not a beginner ?

Def: a beginner in programming is someone who has no idea how computers work.

A beginner is someone that makes all sort of claims without actually testing those claims especially when at the same time not understanding anything about the concept of the language. et all.

The balloon is deflating very quickly now.

[jamie]

I use builder or MSVC to maintain a C DLL that has a shared page in it.

The rest of the code is PASCAL. I would do it in fpc/Delphi If I knew how to create a shared page.

It caused lots of stir! 

https://forum.lazarus.freepascal.org/index.php?topic=47294.0
https://devblogs.microsoft.com/oldnewthing/20040804-00/?p=38253

[TRon]

@Laur:
So now that you haven't convinced me that c is the superior language with your magnificent safe programming skills let's change the subject to the real world instead of some hypothetical examples.

So now that you have used those unquestionable skills in the corporate business sharing those with your colleagues because you work on some real big cojones software suite and need to maintain some hundreds of thousands lines of code and need to explain how your perfectly safe code actually works or fits in the existing pipeline then how do you think you are going to do that ?

And we have yet another hot air balloon that is crashing down (pretty fast).

But I am guessing you are going to inflate yet more of those while I haven't even begun to start shooting the other ones down. Please go get a hobby and start bugging someone else. Trust me when I say that I am far better versed in the divide and conquer game you're trying to pull here.

[Laur]

@Laur:
So now that you haven't convinced me that c is the superior language with your magnificent safe programming skills let's change the subject to the real world instead of some hypothetical examples.

So now that you have used those unquestionable skills in the corporate business sharing those with your colleagues because you work on some real big cojones software suite and need to maintain some hundreds of thousands lines of code and need to explain how your perfectly safe code actually works or fits in the existing pipeline then how do you think you are going to do that ?

And we have yet another hot air balloon that is crashing down (pretty fast).

But I am guessing you are going to inflate yet more of those while I haven't even begun to start shooting the other ones down. Please go get a hobby and start bugging someone else. Trust me when I say that I am far better versed in the divide and conquer game you're trying to pull here.

1. I don't use and never used any safe programing methodology, but just optimal programming

2. I projected and build several programms - say ten or less... with about 1MB of sources (say: 20 files for 50-100kB)
 I don't know what number of lines - probably 10 times less than bytes... per average.

for example a full advanced crossword maker: still the best in the world.


3. In corporation I don't work, because it's... folclor rather - stupid bissnes, not a real programming

OK. I can make test of these dynamic arrays and show results soon.

C is faster because this's low lewel lang... too hard for beginners - inadmissible, in fact forbidden. 

[VisualLab]

1. I don't use and never used any safe programing methodology, but just optimal programming

2. I projected and build several programms - say ten or less... with about 1MB of sources (say: 20 files for 50-100kB)
 I don't know what number of lines - probably 10 times less than bytes... per average.

for example a full advanced crossword maker: still the best in the world.


3. In corporation I don't work, because it's... folclor rather - stupid bissnes, not a real programming

OK. I can make test of these dynamic arrays and show results soon.

C is faster because this's low lewel lang... too hard for beginners - inadmissible, in fact forbidden. 

As I suspected, it's a typical troll. These boasts may (but do not have to) indicate that he used to program a little - as a hobby. If someone wants to prove something (an ordinary fan of a given language), he or she does a lot of tests and presents them - usually on a blog, because then a lot of people will read it. And on the forum it only provides links to the blog. But such tests and descriptions must be carefully performed. Nowadays it is easy because there are enough examples on the Internet, for example in Rosetta Code. He has no idea how computers work these days (he tries to guess). He probably only has some rudimentary knowledge. An experienced troll would give some fancy examples in his favorite programming language. And here: – null

It's a waste of time to waste on him. Of course, he doesn't work in a corporation, because no one would hire an amateur without knowledge and experience there - that's obvious. Crosswords! The world's most advanced scientific and engineering software

This self-presenting troll is trying to give the impression of an aged programmer. But the way the sentences are formulated and the fragments of content presented (naive boasts) suggest that he is some youngster. Aged trolls are much more refined and clever in the art of trolling (which is a matter of experience).

This thread contributes nothing - it should be closed.

[Thaddy]

laur is not a troll, he simply does not understand the basics and does not know what a compiler (a good compiler ) actually does.
That gives me the pleasure to show that in a plain comparison with, say, GNU C and FPC there is no difference in speed.
I am more of a troll than he is  and still not banned, although I came close several times...
Then again, using programming languages, any two languages, can give the impression that one of them is faster or slower and that depends on the quality of compilers and also on platform. What he should do is look at the generated assembler code between languages and shiver that FPC by now is even faster than C (gnu) on major platforms like x86_64-win64 for that specific platform. Only the MS and Intel compilers are still slightly faster but they use higher optimization levels as default.
As I wrote many times before: it is not the language, it is the implementation.
Many people just can not make that difference.
Writing fast code is an art, not science, in any programming language.
But that is an opinion, not fact.

Focus on what syntactically can be expressed and how it translates...
That is the ONLY fair comparison.

[Laur]

OK amateurs: I see everyday what these super-hiper optimized compilers produces.

100 times slower than any normality provides... and programms are 1000 times bigger
than in ancient ages of programing science - in 1990 or so, so it was almost 40 years ago.

Why it is so badlly with this and still worse?
Because now amateurs are programming (mainly workers in corporation of course), no profesionalists what has been eariel.
//////////////
And you can - should delete this thread... it's nonsense to talking over ages - a barrier of time is impenetrable.

[Thaddy]

Focus on what syntactically can be expressed and how it translates...
That is the ONLY fair comparison, Laur.
Any language that is Turing complete can be just as fast as any other, that is why they are Turing complete...If you can follow that. Some people call it computer science...( which I don't agree with, it is logic )
If a language is Turing complete, it follows by inference there is never a speed difference in the language itself, it can only be the implementation.

Show me a counter example? You can't.

[MarkMLl]

If a language is Turing complete, it follows by inference there is never a speed difference in the language itself, it can only be the implementation.

I admit to having been brutally dismissive of OP when- at the start of the thread- he was equally dismissive of Pascal's type declarations and demanded that the language be changed to ease pointer manipulation.

However by now I feel he is making a good point: by no means an original point, but one which is perennially good.

Modern compiler implementations suck when it comes to generating small binaries in their default setup.

This is not a language issue, unless either the language mandates inefficient data representation or the language mandates that inefficient runtime checks cannot be disabled.

It's more often caused by a combination of factors, including:

* The user is failing to distinguish binary file size and size in memory.

* The user has inadvertently left debugging information attached to the binary.

* The user has inadvertently left unneeded runtime checks in the memory image.

* The user is referring to language extensions, which the implementation (not the language itself) implements inefficiently.

* The user has left the optimisation level at an inefficient default and the compiler is not attempting to eliminate code from at least some of the above.

* The language implementation's standard library contains a substantial number of "hooks" etc. to try to accommodate every use case conceived over the last 40 years.

Plus- and this is borderline between language definition and implementation-

* The core language has become excessively large due to a focus on adding application- and OS-specific feature support rather than abstracting such things into an expressive core plus extension libraries.

So to summarise, OP got off to a bad start by expressing himself in a way that appeared to be trolling ** . However we all know that binary size and in-core footprint is a problem for all current languages, and while he has directed his frustration towards FPC's dynamic arrays and structured types, this sort of thing is a problem with just about all current languages that try to express higher-level concepts to "enhance the programming experience": and I don't believe he is denying that:

100 times slower than any normality provides... and programms are 1000 times bigger
than in ancient ages of programing science - in 1990 or so, so it was almost 40 years ago.

Why it is so badlly with this and still worse?
Because now amateurs are programming (mainly workers in corporation of course), no profesionalists what has been eariel.

** OP: I suggest you think about how you're phrasing something before posting. That's particularly the case if English is not your native language.

MarkMLl

[Martin_fr]

While it is correct that the points made exist, and that they may be more easily to notice or demonstrate with some compilers....

The initial question of LAUR was very direct, which in some way is good. But as no one could know he was aiming for execution speed, he received other advice (and unfortunately rough reactions, as for others it looked like an ignorance of how Pascal is designed).

Anyway, he later pointed out is goal "speed".

I offered him advice on it: Twice
Even, how to get more speed, than indexed pointers would give him.

He has ignored that, both times. So what are we to infer about his goals? (rhetorical, don't answer)

[VisualLab]

* The core language has become excessively large due to a focus on adding application- and OS-specific feature support rather than abstracting such things into an expressive core plus extension libraries.

This is true when it comes to programming for microcontrollers. In the case of computers running an OS, the language must somehow cooperate with the OS. And OSes have become more complicated, not now, but already in the mid-1990s (although the last 10-15 years have seen OS stagnation or very slow evolution, with temporary partial regressions). Hence the increase in the complexity of languages.

So to summarise, OP got off to a bad start by expressing himself in a way that appeared to be trolling ** . However we all know that binary size and in-core footprint is a problem for all current languages, and while he has directed his frustration towards FPC's dynamic arrays and structured types, this sort of thing is a problem with just about all current languages that try to express higher-level concepts to "enhance the programming experience": and I don't believe he is denying that:

100 times slower than any normality provides... and programms are 1000 times bigger
than in ancient ages of programing science - in 1990 or so, so it was almost 40 years ago.

Why it is so badlly with this and still worse?
Because now amateurs are programming (mainly workers in corporation of course), no profesionalists what has been eariel.

OP is talking nonsense. His last statement shows his total lack of understanding of the complexity of modern processors and computers. This forced the development of languages. It is true that 50-40 years ago you could juggle the indicators as much as you wanted. Back then, both processors and OSes were simple (from today's point of view, even primitive). You could easily program 6502 or 8086 in assembly language because they had few instructions, few registers and a simple structure. How many instructions and registers does today's AMD64 CPU have? And today's ARM CPUs used in smartphones?

This is the result of technical progress and also applies to other fields, e.g. electronics. Maybe the OP will start lamenting that today's inept electronics engineers should design computers using TTL 74xx series chips or CPU 6502? Should we regress in our development because some maladjusted person can't cope? Another "grandfather of the forest" who has been sitting in the basement for the last 30 years?

If there is a problem with modern software (e.g. OSs), it is probably because it was written in C. Maybe 40 years ago, speed alone was enough. But today this is only one of many factors that is important. I remind you that 40 years ago, the global network was just beginning. This changed everything. And that's why today "speed" is far from enough. But to realize and understand this, you didn't have to spend the last 40 years in an isolated basement!


P.S. Yes, there are crap solutions fashionable today, such as the mania for overusing scripting languages. But that's a separate issue.

[MarkMLl]

* The core language has become excessively large due to a focus on adding application- and OS-specific feature support rather than abstracting such things into an expressive core plus extension libraries.

This is true when it comes to programming for microcontrollers. In the case of computers running an OS, the language must somehow cooperate with the OS. And OSes have become more complicated, not now, but already in the mid-1990s (although the last 10-15 years have seen OS stagnation or very slow evolution, with temporary partial regressions). Hence the increase in the complexity of languages.

That doesn't have to be in the core language, it's a library issue.

If something that /has/ to be in a library can't be expressed in the core language, then it becomes a core language issue... but not before.

Why it is so badlly with this and still worse?
Because now amateurs are programming (mainly workers in corporation of course), no profesionalists what has been eariel.

OP is talking nonsense. His last statement shows his total lack of understanding of the complexity of modern processors and computers. This forced the development of languages. It is true that 50-40 years ago you could juggle the indicators as much as you wanted. Back then, both processors and OSes were simple (from today's point of view, even primitive). You could easily program 6502 or 8086 in assembly language because they had few instructions, few registers and a simple structure. How many instructions and registers does today's AMD64 CPU have? And today's ARM CPUs used in smartphones?

This is the result of technical progress and also applies to other fields, e.g. electronics. Maybe the OP will start lamenting that today's inept electronics engineers should design computers using TTL 74xx series chips or CPU 6502? Should we regress in our development because some maladjusted person can't cope? Another "grandfather of the forest" who has been sitting in the basement for the last 30 years?

If there is a problem with modern software (e.g. OSs), it is probably because it was written in C. Maybe 40 years ago, speed alone was enough. But today this is only one of many factors that is important. I remind you that 40 years ago, the global network was just beginning. This changed everything. And that's why today "speed" is far from enough. But to realize and understand this, you didn't have to spend the last 40 years in an isolated basement!

Disagree. Compared with Dijkstra, Knuth, Wirth, Iverson and the rest the vast majority of modern "experts in their field" are ignorant amateurs whose ability to write code exceeds their ability to understand the implications of what they've written.

The place where Laur and I (quite obviously) disagree is that he assumes that robust code can be written by a minimal compiler provided that the user is sufficiently skilled, while I ascribe far more importance to the ability of the compiler to highlight unsafe behaviour: which generally demands a somewhat more detailed description of what the programmer is trying to do than you got in C and Assembler.

Pascal, under Wirth's control, was responsible for introducing much of our current ideas relating to data structures (i.e. records in Pascal terminology), and also responsible for the concept of fairly strong type checking (tightened up further in Wirth's Modula-2 and in Ada). Later languages have done their best to take those principles on board, even though the more thoughtful members of the C community recognise that the necessity of source-level compatibility with older system and application code limits the extent to which they can enforce that.

MarkMLl

[VisualLab]

If something that /has/ to be in a library can't be expressed in the core language, then it becomes a core language issue... but not before.

In part, definitely. But this simple example comes to mind: String and PChar. The latter exists in Pascal only because the program being created needs to use the operating system or some external libraries written in C. And the conventions for calling functions/procedures: cdecl, safecall, stdcall, etc.? Can this be placed in libraries? Or does it have to be in the compiler? I agree that the more that is included in the libraries, the simpler (clearer?) the core of the language will be. Only this isn't always possible. It all depends on what we analyze. Certain features can be addressed by libraries, but some must be included in the language (compiler?).

The place where Laur and I (quite obviously) disagree is that he assumes that robust code can be written by a minimal compiler provided that the user is sufficiently skilled, while I ascribe far more importance to the ability of the compiler to highlight unsafe behaviour: which generally demands a somewhat more detailed description of what the programmer is trying to do than you got in C and Assembler.

Pascal, under Wirth's control, was responsible for introducing much of our current ideas relating to data structures (i.e. records in Pascal terminology), and also responsible for the concept of fairly strong type checking (tightened up further in Wirth's Modula-2 and in Ada). Later languages have done their best to take those principles on board, even though the more thoughtful members of the C community recognise that the necessity of source-level compatibility with older system and application code limits the extent to which they can enforce that.

The problem with C is that when it was created, it was basically a makeshift, hacker solution: "Does it work? Works! If anything more is needed, we'll see in the future. Something will be added, patched and it will be nice.” C was created in a hurry for short-term purposes (not the only language). And then it stayed like that, according to the maxim: "makeshifts are the most durable." Subsequent users added a "halo" to it in the form of an explanation that it was a supposedly well-thought-out, well-designed language. But it was self-deception. By the time some admirers came to their senses, it was too late because too much code had been produced. Years later, these paeans to C have become an urban legend - that C can do anything, even: "ties tie and terminate pregnancies." These nonsense are repeated to this day.

C's speed came at the expense of all other factors/features of the language. Once upon a time, 50-40 years ago, this was enough. But for at least 20 years now - it is not enough. Yes, there have been attempts to improve C over the years (see: the complexity of C compilers). But not much has changed because people have become hostages of the old code. What was once the advantage of C for some time will one day become the nail in the coffin of this language. You can't powder a corpse indefinitely. This is probably the largest and most spectacular technological debt in IT. What about costs in an economic sense?