Talk:Comparison of Pascal and C

message: This page needs to be separated into more specific pages. 
Page 1: Comparison of Original C and Standard Pascal.
Page 2: Comparison of Modern C/C++ and Modern Pascal 
The word "Pascal" is extremely vague. The Pascal that is in major use today such as freepascal and delphi are more comparable to modern C and modern C++ compilers. One cannot compare modern C to standard pascal unless explicitly stating so. Nor can one compare modern pascal to B language if the comparison is between pascal and C. Nor can we bounce back and forth comparing both standard pascal to old C and new C to standard Pascal since it is inconsistent, confusing, and chronologically disorganized.
: The page, as restated, specifically defines what Pascal it is talking about, which is original Pascal as defined by Wirth and standardized by the ISO 7185 standard. These languages are virtually identical and form the Basis of unextended Pascal.
Please distinguish Modern Pascal from Standard Pascal.  In order to obtain a chronological reference, one would have to state the "current Pascal in use in freepascal 2.0.4 and in Delphi 7 compared to the current C used in GCC and Visual Studio". Also, neither current C++/C nor current Pascal compilers are standards compliant. Define what "standard pascal" is and what year it is you are talking about, and define what "modern pascal" is by referencing the year and compiler versions, and define what C and C++ is since no C compiler or C++ compiler implements any "pure standard C". --LFiveZeroFive
: Not even close to being true, there are several completely standard compliant compilers available, from GCC to IP Pascal, Dr Pascal, Irie Pascal and others. The same goes for C/C++, for which standards compliance is the rule. Honestly, I don't know where you are getting this information from. It would be more productive to list compilers that are NOT compliant than to list those that are, since virtually all compilers outside of Delphi are compliant, and on the C/C++ side it is hard to find ANY that aren't.
-- Yes, this page may be separated into more specific pages:
1) Comparison of Original C and Standard Pascal.
2) Comparison of Original C and Extended Pascal (Standard: ISO/IEC 10206; ANSI/IEEE 770X3.160:1989).
3) Comparison of Original C and Turbo Pascal 5.0.
4) Comparison of C++ and OO Pascal/Delphi.
5) Comparison of Original C and C++.
6) Comparison of C++ and C#.
(5,6): See, book Andrew Troelsen, C# and the .NET platform, Chapter 1, Apress, 2001.
Tim32 21:09, 11 October 2007 (UTC)
replies: text: I certainly agree, but will list a few points.
1. The continuous characterisation of Delphi and Turbo Pascal languages as "modern" and other versions of Pascal as, by implication "outdated" is unnecessary and serves you no purpose here other than starting a petty fight with users who otherwise might agree with you and help you. Borland created a dialect of Pascal (an incompatible one). If that dialect is good or bad is not the subject here. Borland is Pascal as far as it is compatible with the language Pascal, which Niklaus Wirth created. There are plenty of implementations of Pascal outside of the Borland family, including GCC, IP Pascal, Dr Pascal, Ire Pascal and others (and that is only counting implementations that are still actively supported). In short, we could be in complete agreement here, if you (and others) would simply knock off the namecalling.
2. C and C++ are different languages, so certainly any page involving Delphi or Turbo should consider the object oriented features separately. To do otherwise is to treat C improperly, ie., to compare apples to oranges.
3. Are the Turbo and Delphi dialects so different that they require different pages? I would suggest that if you believe they do, then you are comparing not just the language, but the libraries and external interfaces it supports, since the biggest difference between Turbo and Delphi is Delphi's extensive class library. I think the library that the implementation supports and its language are different issues.
In short, I think a "delphi vs C++" page is the best place to start, since it compares two fairly equivalent, and currently supported languages. After this is created, then folks here can decide if they need more. Right now, we don't see anyone volunteering to create even one page, much less the six different pages you are avocating!  —Preceding unsigned comment added by 66.28.253.185 (talk) 20:21, 26 December 2007 (UTC)
thread_title:  Modern C and Modern Pascal 

message: Hi, I wrote this page, because of a request by another user. I don't work on this page anymore. I looked  it over briefly, and in the year that I have left it, it now has several factual errors inserted in it. I don't fight over Wikipedia issues anymore, I don't have the time or inclination. Simply be aware that this article is no longer very factual, and is quite likely degenerating into being mostly fiction.
Scott A. Moore
Can you give us a few examples of such factual errors, so I, or someone else, can fix them? /HenkeB 03:12, 7 September 2006 (UTC)
replies: text: In theory yes, but in practice one usually has to accept some low level conventions to enable compiled code to efficiently fulfill the semantics of a particular language on real computers. There were no standard documents for K&R C (other than the informal white book) but in most K&R C compilers the caller was responsible for removing pushed parameters from the stack, and parameters were pushed right to left so the first (such as the format-string in printf) was accessible on a known fixed offset off the stack pointer; this was (and probably still is) the de facto standard method for permitting variable and/or runtime-sized parameter-lists in C. /HenkeB 09:33, 25 June 2007 (UTC)
replies: text:  In fact, no it isn't. I don't really have time to lecture you on compilers, pick up a book. In fact, stack based passing was popular in the 1980s and early 1990s, and even then, mainly on low performace microprocessors. It is inherently NOT a register based calling convention (hence the name "stack"), and virtually all modern operating systems and languages use register based calling conventions (you have perhaps heard of Windows, or GCC?). —Preceding unsigned comment added by 66.28.253.185 (talk) 00:23, 17 October 2007 (UTC)
replies: text:  You are rude and appear quite angry, but I will try to explain some basic things for you anyhow: A C or Pascal compiler can only pass a few parameters directly in registers, typically around 1-3 on x86 machines (Windows), before it simply runs out of free registers. For calls with more parameters, it must either dynamically (to allow multi-level calls) allocate a data area in which to store the rest of the actual parameters, or use the stack (which is inherently dynamic - albeit in a rigid manner). There are CPU architectures with enough registers to use register-allocated parameters in almost every case, but x86 is certainly not one of them (and not a "low performace microprocessor"). Also bear in mind that, even when parameters are passed 100% in registers, the registers must sometimes themselfs be preserved (on a stack) to allow for multi-level and recursive calls. HenkeB 02:39, 20 October 2007 (UTC)

text: again, NONE of this has any bearing on the language as seen by the user, which is why neither the standards for C nor Pascal includes such information.  —Preceding unsigned comment added by 66.28.253.185 (talk) 20:34, 26 December 2007 (UTC)

text: I and others have fixed the above complaints and consider the issue closed.  —Preceding unsigned comment added by 66.28.253.185 (talk) 20:32, 26 December 2007 (UTC)
thread_title:  "needs to be looked over by a expert" 

message: 1.
"
Some newer pascal compilers allow arrays to be declared in a way more similar to C
var x = array [0..9] of integer
"
The above statement is valid Pascal and has always been valid Pascal.
2.
Certain newer Pascal compilers have a predefined string type, which works as a NULL terminated string similar to a char array in C.
I think you are talking about UCSD/Borland strings, in which case the statement is not correct. Those strings don't use a zero terminator.
(I think he talks about Delphi, which has a null (and double null since D4) terminated string type for easy passing to C. However it is only #0#0 terminated for C's sake, since there is still a separate length, and the type can contain #0's too. IOW, proper pascal code shouldn't loop with a check for #0.
88.159.87.12 10:00, 23 July 2006 (UTC)
thread_title:  J7 changes 

message: I have to admit, this page has generated much less argument that I would have guessed, based on previous wars between C and Pascal users.
I really appreciate that most readers and editors only want a balanced view of both languages.
Thank you.
--Samiam95124 22:01, 22 November 2005 (UTC)
replies: text: Indeed! It was a very nice read. Thank you and greetings from a nostalgic Pascal fanatic. -- ActiveSelective 07:24, 25 March 2006 (UTC)
thread_title:  A complement for you 

message: The elided material was:
"The ability to both have arrays of any length, and be able to check them under language control, is often termed "dynamic arrays"."
Mr. Burroughs says:
Removed irrelevant / misleading / inaccurate refererence to dynamic arrays. 'Dynamic arrays' usually refers to arrays that can be resized at runtime.
Not sure I see the problem here. Many implementations of Pascal have varying ways to do this, and pretty much all of them qualify as "arrays that can be resized at runtime".
I would prefer if you are going to remove material like this, if you would instead reword it to your idea of "correct". We are trying to add information here, not remove it.--Samiam95124 04:00, 6 October 2005 (UTC)
thread_title:  Dynamic arrays 

message: I don't have much time to spend on this right now, but I gave it a quick read, and cleaned up a few things. There are a lot more wiki links to add, for example, and the code samples should be presented in a fixed-width font.
Overall, I think it does a good job of illustrating the differences between the languages. I like it better as a separate article than as part of the C or Pascal pages. 209.193.109.10 23:40, 4 Jun 2005 (UTC)
replies: text: Sorry - I wasn't logged in. Those comments are from: Gary D Robson 23:41, 4 Jun 2005 (UTC)
thread_title:  General comments 

message: In the section "Identifiers", the author first talks about "identifiers", and then about "labels". I was under the impression that identifiers and labels are the same thing. If so, the word "identifier" should be used exclusively to avoid ambiguity. --Silver hr 09:28, 21 Jun 2005 (UTC)
thread_title:  Identifiers 

message: Shouldn't this article be titled Comparison of Pascal and C to conform with standards?  Also, I believe MirrorVax was correct in his category changes -- this is not an article on a programming language, its an article comparing two languages and should be labelled as such. .:.Jareth.:. babelfish 05:18, 18 December 2005 (UTC)
thread_title:  Title 

message: I don't think it should exist. The two languages are at best loosely related, and one didn't really evolve from the other. This article explains an inexistent "bond". Siddharthagandhi 03:00, 11 November 2006 (UTC)
replies: text: I agree that comparing modern dialects of C and Delphi is not very useful, but a comparison of "Standard Pascal" with K&R or K&R 2 has historical value.  C and Pascal were the main systems programming languages for many years.  How the features they had at the time interacted with the needs of programmers at the time and the nature of the hardware they were using at the time had a noteworthy historical impact.  Kleg 00:16, 6 March 2007 (UTC)
replies: text:  I agree, that was what I thought it was when I made my contributions — a comparison of Wirth's and Richie's original design aims. Quite soon some people started to claim that C = C99 (to be able to say that C has boolean typed variables and such) and that made me feel I was wasting my time. However, I certainly support the idea to make it into two separate articles, such as Pascal versus K&R C (1978, when C had become fairly stable) and Delphi/FreePascal versus C99/C++ (today) /HenkeB 09:02, 25 June 2007 (UTC)

text: I found this article to be interesting enough to read, but while the main outline of the article is fine, the comparing detail get's kind of 'fuzzy' in the text itself. I vote to remove this page unless this 'fuzzy' is taken out. (Lines run from C to Pascal without a real border, this makes it harder to read and get a conclusive feel for the differences.) Coen Leermakers 21:03, 6 March 2007 (UTC)
thread_title:  Whether Article Should Exist? 

message: 1. ad semicolon - transforming C expression into statement. i believe it is misleading. true. but not generally true. see
if(0) { } else { }
2. ad semicolon use - i really hate unstructured writing, which involves lot of parsing. it is not the best but i feel whole page should be made similar.  —Preceding unsigned comment added by 84.16.123.194 (talk) 17:03, 25 February 2008 (UTC)
thread_title:  Semicolon use 

message: A source that might be useful to cite is http://portal.acm.org/citation.cfm?id=14947.14950&coll=GUIDE&dl=GUIDE&CFID=606445&CFTOKEN=44901229  —Preceding unsigned comment added by 137.222.107.22 (talk) 15:32, 9 November 2008 (UTC)
thread_title:  Source 

message: A fundamental difference between Original C and Original Pascal is that Original Pascal did not define or envisage linking of external source or objects or libraries. Niklaus Wirth addressed this in his next language (Modula), and compilers addressed it in various different ways. There was considerable debate about this aspect of language design at the time.
C, "a small language of only 32 keywords" is a null language without the C library, which was the system library, which was the operating system. (The POSIX definition still includes a complete definition of the "C" library). This means you can implement C without implementing the library, you can replace the library and you have explicit control of which parts of the library you wish to use or implement. This made C particularly suitable for situations where you do not have the library, or were you do not wish to use the library: in particular, for writing OS or parts of an OS or OS drivers.
By default, all C functions are public, that is, exposed for external linking. And the standard way to write C programs was a series of independent source objects, which were compiled, then linked in the same way the System Library was linked.
However, the separate objects and the standard linking interface each impose a fundamental limit on an optimising compiler.
Wirt consciously adopted a different approach with Pascal. The language definition already include Read and Write. You don't need an external library to write programs. By definition, all Pascal functions are private, and there was no way to link in external source code.
This made for unwieldy programs, but removed the inefficiency of the linking interface and the separate objects.
The need to include functions like Read and Write meant that every compiler had to include the library: this was balanced by the fact that the language itself was explicitly designed to make it easy to write a small, efficient, correct compiler.
Since Pascal was explicitly designed to make it easy to write a small efficient compiler, it was also easy to write a correct optimising compiler, something that was very difficult in C: (hence the long standing advice that if you wanted your C program to be correct, you should compile with optimisations turned off).
The short term result was that Pascal Compilers generated small, fast, correct programs, but were unsuitable for system programming. C was more suitable for system programming, but C compilers generated applications that were small and fast only when compared to Lisp, not when compared to FORTRAN or Pascal.
The long term result is that C is used much more widely than Pascal, but the code is still large by default. 
The way to get small, fast C code is the same way they got small fast Pascal code: put all of your code into a single file, declare all of your functions as static (ie local, private), and avoid using (external) library functions. Back in the day, programmers used .INC and .DEF files and included code in .H files. Embedded C compilers and linkers now have non-standard language extensions to help you do this, like -fWhole-Program in GCC.
Note, writing small programs and avoiding library functions was reasonable for the OS and for drivers: most of the library is unsafe and isn't relevant anyway in that situation.
The point of this is not to compare executables from Pascal and C (who cares?) The point is there was an original design decision (stand-alone program vs linked objects), which had front-end and back-end effects.  —Preceding unsigned comment added by 203.206.162.148 (talk) 05:44, 9 December 2009 (UTC)
thread_title:  Linking, Epilogue 

message: Anyone that whishes to compare C to old historical versions of Pascal which are no longer used by anyone, please create a new page: Comparison of C and historical Pascal.
Noone uses that old Pascal anymore, therefore it is ridiculous to say that it is "Pascal". Pascal is the modern implementation in Free Pascal and Delphi which are the de-facto standard. --Felipe Monteiro de Carvalho (talk) 10:47, 6 November 2010 (UTC)
thread_title: Ridiculously out-dated Pascal in the article

message: Some of the features of WEB allow you to use some C-like features in Pascal programs. Some of these features are as follows:
* Preprocessor macros
* Conditional compilation (implemented using preprocessor macros)
* Hexadecimal numbers and octal numbers
* Character constants converted to the ASCII number of that character
* Constant expressions in place of numbers
Not all features of C can be used in WEB. There is still no bitwise operations. --zzo38(✉) 06:11, 7 November 2010 (UTC)
thread_title: WEB and C

message: The "strings" section directly implies that C does not have any support or definition for strings at all, yet when revising the C99 standard draft (ISO/IEC 9899:TC3, n1256.pdf) section 7.1.1 Definitions of terms:
:A string is a contiguous sequence of characters terminated by and including the first null character. The term multibyte string is sometimes used instead to emphasize special processing given to multibyte characters contained in the string or to avoid confusion with a wide string. A pointer to a string is a pointer to its initial (lowest addressed) character. The length of a string is the number of bytes preceding the null character and the value of a string is the sequence of the values of the contained characters, in order.
I suggest this statement be reworded to state that C does not have a string type, however it does have an official definition for "string" as a representation.  — Preceding unsigned comment added by Plebbeh (talk • contribs) 07:48, 19 December 2010 (UTC)
thread_title:  Strings in C 

message: The section Implementation issues is a copyvio from Let's Build a Compiler from 1988 (search for "When Niklaus Wirth designed Pascal"). It was added on May 30 2007. Caesar (talk) 21:28, 19 June 2011 (UTC)
thread_title:  Copyvio 

message: C does not have pass by reference mechanism. Passing parameters through pointers is still pass by value. So that needs to be fixed in the article.
Akhwaja (talk) 00:54, 30 September 2011 (UTC)
thread_title:  Pass by Reference in C 

message: The article should mention the significant exception in C: Arrays are effectively passed by reference as they are effectively always pointers. I.e. arrays, unlike structs and simple variables, are not copied when transfered in and out of functions. One should also mention that arrays in function arguments are unsized and it is therefore customary to add a separate size argument to get around this.
78.82.155.234 (talk) 17:33, 29 March 2020 (UTC)
thread_title:  Arrays by reference 

message: Can anyone show that this subject meets WP:GNG? ButOnMethItIs (talk) 10:57, 17 October 2011 (UTC)
thread_title:  Notability 

message: Hello fellow Wikipedians,
I have just modified one external link on Comparison of Pascal and C. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20050314152247/http://www.cs.inf.ethz.ch/~wirth/books/Pascal/ to http://www.cs.inf.ethz.ch/~wirth/books/Pascal/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 16:35, 11 August 2017 (UTC)
thread_title:  External links modified 

message: The remark "Pascal has neither array initialization (outside of the case of strings) nor a means of determining arbitrary array sizes at compile time" is only halfway true.
Arbitray array size at compile time ar unknown, but it is perfectly possible to initialize an array at compile time, in my opinion.
My Pascal compiler does not object to constructs like: data: array[0..9] of integer = (10,20,30,40,50,60,71,80,90,91);. Am I right, or do I miss some point?
--Bloksma (talk) 08:40, 26 October 2018 (UTC)
thread_title:  Array initialization 

message: In the lede : "The reason is that these versions both represent the mature version of the language,".
Pascal in 1982 and C in 1989 were the mature versions of each language???
Based on what? Also, C in this description is almost twice as old in 1989 as Pascal was in 1982. Yet even for C, in 1989, it seems it still had not yet reached its mature age. This kind of feels like comparing the skill level of an 8 year old to a 16 year old. And why are we comparing outdated versions of each language that nobody uses (this coming from someone who still uses an assembler from the early-mid 1990s, A386, and writes modern programs as if it still needs to fit within 640K memory)? In Pascal's case, nobody has ever used that ""standard"". — al-Shimoni (talk) 01:14, 12 April 2024 (UTC)
thread_title:  Mature version?