#16
  1. Banned ;)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Nov 2001
    Location
    Woodland Hills, Los Angeles County, California, USA
    Posts
    9,625
    Rep Power
    4247
    I've been working with C for a long time, with a variety of compilers, but I've never seen one pass a struct as a pointer. However, I can guess where M.Hirsch has come across a compiler like that --- a Delphi compiler! Delphi does obscure the difference between a normal variable type and a pointer type and it is very hard to tell if the class is passed as a pointer or not. In the beginning, this notation confused me to no end, but now I'm used to it :).

    >>Why C chooses to have an alias for the name of the array is beyond me.
    C was designed as a language meant for efficiency and part of its philosophy was a very terse syntax and verbiage. There's only ONE way to pass an array in C, to another function. That is via a pointer -- coincidentally, this is also the MOST efficient way to do it. Since C is a language full of terse syntax, my guess is that this influenced the idea of making array a synonym for &array[0]. Once you get used to the fact that all arrays are passed as pointers (i.e. the most efficient way possible), it becomes second nature to expect the same behaviour in other languages!

    >>It really blows my mind that there are so many things wrong with this language.
    All languages have their quirks. Personally I like C -- it's terse and does NO handholding and that's 100% fine with me :) If you really want to see what's wrong with some other languages, see this paper by Brian W. Kernighan
    http://www.lysator.liu.se/c/bwk-on-pascal.html

    I've heard at least one rumor about the Borland team incorporating features in Delphi to account for his criticisms. :)
  2. #17
  3. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Right Coast
    Posts
    25
    Rep Power
    0

    in C++....


    In C++ the name of an array is the memory address of the first element of that array. Ergo, it is more or less a pointer. However, unlike a pointer, there is no re-assigning a new memory location for the array name.

    However this sort of thing is cool.

    int mya[] = {1,2,3,4,5};
    int* p = mya;

    cout << p[2];

    Not sure if that helps, but I just wanted to say that an array name IS a memory address for the beginning of that array.

    J :)
  4. #18
  5. jasondoucette.com
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Canada
    Posts
    378
    Rep Power
    12
    Scorpions4ever:

    While, I do not wish to turn this into C vs Pascal debate, I do enjoy comparing languages, because I truly believe that each has their strengths and weaknesses. Also, it makes no sense for a person to compare languages that they have not used. Typically, anyone screaming 'C is better' or 'Pascal is better' has only used that particular language. I have used both for a significant amount of time (Pascal for since '93 and C since '95). Here's my personal opinions:

    1. I understand 100% why arrays are handled like pointers in C. It does make total sense to handle them in this way, since accessing elements is like dereferencing a newly create pointer to that element - which is something EASY to do. However, I see no reason why the arrays name acts like a pointer. It is fine to hide the fact that a[3] is really a dereference of pointer to a (with 3 added to it), but if you really WANT the pointer to a, why not just ask for it in the same manner that you would ask for it with every other variable? It keeps things consistent. Someone can always say, well, it's already really a pointer, but that's the same for all other variables, as well. Pascal doesn't have this inconsistancy.

    2. I have read the paper by Brian W. Kernighan http://www.lysator.liu.se/c/bwk-on-pascal.html. This paper was made in 1981. The pascal compiler I have used was Turbo Pascal 5.5 - 7.0, and I have not used any future versions of Borland's Pascals (such as Delphi), but I assume that have kept the fixes they have made to the language (at least, I assume they are the ones who made the changes, perhaps they were following some standard). Borland's Pascal (since version 5.5, that was back in the early 90's or earlier) doesn't have almost any of the mentioned problems that Brian is speaking about. Allow me to elaborate:

    you cannot pass in a float to a function requiring an integer: C and Pascal do not allow this, but have type cast functions to make sure this is possible if you wish to do this. The fact that Fortran allowed it just wasn't right, but was there to make programming easier. The type-checking of C and Pascal ensure less errors occur. I think most would agree that this is NOT a problem with pascal

    size of the array is part of the type: Borland's pascal allows assignment of strings regardless of the size of the array to store the string. This is something C doesn't allow without a function call. I think Pascal is one up here. Although, sometimes NULL ended strings are better than Pascals for certain programs. I believe Pascal allows NULL ended strings, if you wish to use them. Most people don't - I never did. But I probably would have if I had used them as often as I use them in C, as I do now. I don't see this being a fault - Pascal allows both types, and the problems Brian mentions no longer exist with the Pascal-type of string.

    There are no static variables and no initialization: Pascal allows initialization, and it does not have static vars... very true. I have never used one, but I understand why people do. They declare them in the function in which they are used, yet they have outside scope. I personally never found a problem with declaring a global variable in the place where global vars are supposed to be declared. But, I understand that adding this functionality is not a problem. Just like in C++ I regularly declare vars right before I use them, which neither C nor pascal allows.

    Related program components must be kept separate: Although you must type label, const, type, var, I thought there was nothing stopping you from doing this multiple times. If this is not possible, then I agree that this stops you from grouping common things together.

    There is no separate compilation: Borland allowed precompiled units that were not changed to NOT be re-compiled. Also, Borland had the fastest compiler on the planet http://info.borland.com/pascal/tp7fact.html (85,000 lines per minute on a Compaq DeskPro 386/33). I miss the days in which I could type a bunch of periods (i.e. ......... ) to 'mark' my place in the source code, so that I could go elsewhere to change a variable, and press the short-cut to compile the program so that I could instantly be returned to my place of coding. And I mean instantly - I would do it even if it were a few pages to scroll up and down, since once I got back to the page, it took longer to reposition the cursor than it did to wait for the compiler to complain and repositoon the cursor for me. I did this on my 286.

    Some miscellaneous problems of type and scope: I agree that it can be annoying to have to make up a type. But it never really bothered me. I thought this was 'proper' programming, to begin with. But, it would be better if the programmer had the choice.

    There is no escape: pascal has type casting just like C. this is not a problem.

    Control Flow: I have ran into this before, and I am sure that the manuals in borland's pascal explain exact what happens in a statement like:
    [i]while (i <= XMAX) and (x > 0) do ...
    and I have used it sucessfully.

    There is no 'break' statement for exiting loops: pascal has break and continue just like C.

    The Environment: the keypress function solves ALL problems mentioned here.

    Cosmetic Issues: I agree that the semicolon before 'end' doesn't make sense.

    There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote embedded in a string : Pascal uses " for strings and ' for a single character (one element of a string). So, "" is a NULL string, you don't use ''. This is not a problem.

    Conclusion of Brian's article: 95+% of everything he mentioned has been fixed. There are still a few things that are a little annoying, I agree.

    My personal opinion of C vs Pascal (derived from my own experience):

    - C uses an include directive for .c / .cpp and .h header files. This is to have the implementation and interface separated, and the include allows multiple files to be a part of one program. Turbo Pascal, in v4.0 fixed this extremely major flaw with C and Pascal by introducing units. I first programmed with units, and later found out that they replace the 'include' directive, and I was shocked to find out people used to program this way. Then I learned C and found out that people are still putting up with ancient method. Units allow the programmer to avoid 'setting up' the code to allow structured programming with implementation and interface in clearly defined places. It boggles my mind that Pascal has evolved so well in such a short period of time, but C has not. Pascal had, as you can see from Brian's article, many problems, but they have been fixed as it evolved. C has not evolved (with the exception of handling OOP, another thing with Pascal evolved into better). It would be hard to explain until you used OOP yourself in borland pascal, but similar to the way units fix the implementation/interface problem with includes and .cpp and .h files, pascal's OOP has 'fixed' the annoyances of OOP.

    - C has incosistentancies such as array names are pointers, but to get a pointer to another variable, you must use &. This is unnecessary. If you want the pointer, ask for it, like you do with every other variable. Consistentancy allows for less debugging, and makes it easier to learn.

    I believe that most of C's problems is in the way in which it is taught, since so many people are confused with what happens. Some of the things mentioned earlier in this thread is an example.

    - Pascal's only major flaws are the fact that you cannot use such statements as:
    if (a = (--b * c) + (d++ * e)) f = a+2
    Someone would have to let me know if Borland has fixed this or not.

    - Pascal has range checking, which most people say makes the language useful for only learning. But, this is just a debug switch. Turn it off once your program is ready to be released. This has caught many bugs in my pascal programs. Without it, developement time would have been greatly increased.

    I wish Pascal had caught on as much as C. I also wish my current project was being made in Pascal, but I am using C for portability purposes only. This is C's biggest strength. It is big enough to overcome all of the problems with C. I understand that people have preferences from what they have used, and most are loyal only to their first language (I used Basic since '82, but I have given that up! :) ), but I do not wish to argue. I like to discuss things with people who are knowledgable about both languages. I find most people don't understand that 99% of the problems people bring up with Pascal no longer exist (or never existed).
    Last edited by Jason Doucette; February 23rd, 2003 at 11:59 AM.
  6. #19
  7. Banned ;)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Nov 2001
    Location
    Woodland Hills, Los Angeles County, California, USA
    Posts
    9,625
    Rep Power
    4247
    Don't get me wrong either Jason, I've been using Pascal since Turbo Pascal 3.0 and I like it very much (I still program in Delphi these days and I prefer it to C++ Builder!) :). Frankly, I'd rather not get in a my fav. language vs. everyone's else fav. language myself. I was just pointing out someone else's point of view and saying that everyone has an opinion about their favourite languages. Anyways Borland did make a lot of modifications to their Pascal compiler, that made it a real pleasure to use. I should have said that Borland fixed a lot of things in that article in Turbo Pascal, not Delphi -- my mistake :).

    You're right about teaching methods though -- incidentally I have an interesting story to relate. A few years ago, a friend of mine was taking an introductory programming course in a community college and I was helping him with his homework. I think the book used for the course was "Oh! Pascal". Believe it or not, my friend hated the language and I found out why --- he had a lot of string handling and file I/O assignments! So I said, "Why not just use the string type to handle strings? Your compiler has lots of nice functions to handle strings". Guess what?? He was not aware that there was a string type in Turbo Pascal because it's not standard to pascal and therefore wasn't mentioned in his book early on. Not only that, his teacher didn't want to grade anyone who used the string type in their code. It had to be 100% standard portable pascal or you got a lower grade. I guess I was luckier in that I picked up Pascal straight from a book and the Turbo Pascal help manuals, so I wasn't corrupted that way :)

    >> I like to discuss things with people who are knowledgable about both languages.
    I'd say I'm fairly knowledgeable in both languages, having used Turbo Pascal since something like 1988 and C since 90 or 91 (and when I say used, I mean used on a very regular basis). In fact, I really liked Turbo Pascal for its incredible compilation speed and used it a lot more than any other language :) BTW just about all your replies to Brian Kernighan's article are specific to Turbo Pascal and are non-standard to the actual language. For example - pascal does not have type-casting as per ISO 7185 Pascal standard. Most of his arguments still hold true to this day for STANDARD pascal. I was pretty surprised myself, when I read the article, because I thought I could do most of the things that he talked about in Turbo Pascal. When helping my friend out with his homework, I found out how much more Borland had added to their implementation (thank goodness for that :)). I guess I got lucky starting my pascal training with a Borland compiler (Turbo Pascal 3.0) and their manual. With that, I'd like to say I have no desire to argue about favourite languages and this thread appears to have deviated away from it's original topic!
    Last edited by Scorpions4ever; February 23rd, 2003 at 01:57 PM.
  8. #20
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2002
    Posts
    272
    Rep Power
    19
    C uses an include directive for .c / .cpp and .h header files. This is to have the implementation and interface separated, and the include allows multiple files to be a part of one program. Turbo Pascal, in v4.0 fixed this extremely major flaw with C and Pascal by introducing units.
    Can you explain just what you mean by flawed?
  10. #21
  11. jasondoucette.com
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Canada
    Posts
    378
    Rep Power
    12
    Scorpions4ever:

    When I stated "I like to discuss things with people who are knowledgable about both languages." - I did not mean to imply that you did not belong to this group; you're very knowledgable. I hope that I didn't make you think otherwise. :) It was said only in attempt to stop this discussion (which I enjoy, which makes everyone learn a little) from becoming an argument.

    If all thoes fixes to Pascal are all just Borland extensions, then Borland is smart. Perhaps they should be on the ANSI commitee for all languages, since they know what they are doing. Anyone who has used Turbo Pascal to its full potential can attest to this. If standard pascal still has all of the flaws from that 1981 paper, than that version of pascal is no better than C.

    Also, I assumed that borland has kept all of the fixes to pascal in Turbo Pascal in their Delphi product... I would be a shame if they did not, and I see no reason why they should not.

    Regarding your teaching story: That is terrible. It is the reason languages are difficult to learn, which helps no one. String types were made for a reason - because strings are used so often. No one should have to program without them.
  12. #22
  13. jasondoucette.com
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Canada
    Posts
    378
    Rep Power
    12
    3dfxMM, To explain it in as simple words as possible:

    People realized that modularity was a good thing, so they separated their code into more than one source file. Using an include directive, we can compile these multiple files into one program.

    The problem is that this is handled in a primative way. The include directive is essentially (not quite, but almost) the same thing as just copying/pasting all of the source code into where it is included into another file. Very basic, and it gets the job done. So, what's wrong with it?

    The problem is that you have to work extra to make it get the job done properly. You must define defines at the top of header files to ensure that they are not included more than once, you have make 'proper code' so that the .cpp and .h files make sense (i.e. it is up to you that things are put where they belong). You have to worry about multiple variables/functions with the same name in different files. It's all work that you yourself has to take care of. Yes, proper programming ensures there will be no problems, but why do this when the compiler can worry about it?

    Pascal's units take care of ALL of this. You don't have to do any extra work. It's all defined within the language. When you create a .cpp and .h file in C++, you are making the .h file the interface, and the .cpp file the implementation. You constuct the files knowing that this is what each of them mean, and it is up to you to keep them correct. It's almost like C programmers designed their own way to have structured programming from within the language constraints. Turbo Pascal's units have an interface and implementation section. You 'include' nothing. You state that you 'use' a unit, and it becomes part of the program. Units take care of what they need themselves. They even have code that is run on start up, and can run code on exit, like an object (without even getting into OOP). You need no 'defines' to make sure it works, or that one does not get included twice. It also has a very simple way of avoiding multiple functions/variables of the same name but in different units without having to work to program to make sure that this doesn't happen.

    In simple terms, this is stuff the compiler can take care of, and Turbo Pascal takes care of it. C and C++ do not. Apparantly standard Pascal does not either. They all use primative methods that have been improved over a decade ago. I wish the standards would be upgraded to have these fixes that Borland created. Each time I create a .h file, it boggles my mind that I am still using includes. It makes turning to Delphi very desirable.
  14. #23
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2002
    Posts
    272
    Rep Power
    19
    I realize that I am just an old dinosaur when it comes to this stuff but I happen to like having the control that I do with C. Your description of how include files are used is a little odd. You make it sound as though you are actually putting code in the include files. This is not normally how it is done. The way include files work is actually very similar to how you describe units. One thing that C really screwed up is defaulting functions and data to having external scope and having to explicitly make them static. That is completely backwards and is what causes some of the pain you mention with name collisions.

    Good or bad, we are stuck with C and its derivatives for now and a long time to come I suspect. Pascal has just never made it as a widely used language. In twenty years in the business I have yet to run across a shop that uses it. Given that the "improvements" that you mention are specific to one company's implementation of Pascal I don't foresee things changing much.
  16. #24
  17. jasondoucette.com
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Canada
    Posts
    378
    Rep Power
    12
    Being an 'old dinosaur' is not a problem. Experience is very helpful, as long as people have open minds to new things at the same time, which I think you do.

    For include files, I am not under the impression that what I have mentioned is odd. Putting code in the include files is exactly what I meant - and, as far as I know, it is the only way to handle included files properly (i.e. to ensure things flows smoothly). I agree that include files work similarly to the why I describe units, but my point is that the extra work you must do to make them work like units is exactly what the compiler should do for you (i.e. using static, namespace, defines, etc), and is exactly what units do do for you.

    Having the control the C allows is great, but not in the case of units/.cpp & .h for implementation/interface parts of a program. Have you used units in Turbo Pascal? I have seen from other posts of yours that you use Delphi for some applications. I assume that it would also use units. Does it? (I would be greatly surprised if it does not). If not, how does it implement such things? Or do you simply use the include directive (for backwards compatibility) just like you do in C? I wish I could sit down and show you the differences between the two, since I think you may not truly understand what units fix with the use of include directive. I could compare its benefits to that of using an IDE for developement as opposed to a text editor - some things should just be taken care of by the system.

    I agree that, given the improvements are only with one company, that Pascal is doomed to be a bad language. But, for the same reason that standard pascal will never be improved, C/C++ is also doomed to the same fate. Also, since Borland seems to be the only big Pascal compiler supplier, they sort of 'own' the language, and are running free with it - maybe that's a good thing. I think they've done a great job.
  18. #25
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2002
    Posts
    272
    Rep Power
    19
    Putting executable code in a header file is universally considered a bad practice. In twenty years I have never worked on a project that would allow it without some severe extenuating circumstances. Defines, typedefs, and function definitions are all that belong in a header. Even data should not be declared in a header. The compiler doesn't need to know where a function lives. It only needs to know its definition and the definitions of any data types that it requires. I am not sure where you learned that program flow is dependent on how functions are placed in header files. It is certainly not a "normal" practice in any language that I have used. The reason I said that the C/C++ paradigm is similar to Pascal's units is that functions are defined once in a .h file, implemented once in a .c/.cpp file, and to "use" them you just need to #include the .h file. The compiler and linker take care of the rest much like with Pascal.

    I still agree that C/C++'s "everything is a global by default" model is exactly backwards. I was brought up on a language that required that any data or code that needed to be accessed outside the module in which it lived had to be declared as an entry point. All other items were automatically static. Much better model.
  20. #26
  21. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2002
    Location
    London
    Posts
    349
    Rep Power
    13
    Originally posted by 3dfxMM
    Putting executable code in a header file is universally considered a bad practice. In twenty years I have never worked on a project that would allow it without some severe extenuating circumstances.
    What about inline functions in C++. You declare the function body in the same file as the specification (generally the header file).
  22. #27
  23. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2002
    Posts
    272
    Rep Power
    19
    Originally posted by rendy
    What about inline functions in C++. You declare the function body in the same file as the specification (generally the header file).
    Still not a great practice but less bothersome in that it is part of a class definition and as such its scope is limited. It is not the same as just including lines of code. It really should only be done with simple assignments and very small amounts of code.
  24. #28
  25. jasondoucette.com
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Canada
    Posts
    378
    Rep Power
    12
    3dfxMM, I understand better where you are coming from. Allow me to refine my explanation:

    Normally, proper coding has an interface and an implementation section. In C/C++, the interface is the .h file, so when you state "Defines, typedefs, and function definitions are all that belong in a header", you are quite correct. The .cpp/.c file is the implementation. This is where the code goes. If this is a class (or even if it is not), there can be 'init' and 'exit' code associated with that 'subsystem' or 'class' or 'unit', as Pascal calls it. This does not mean the code is within the interface - it is not. Pascal just hanldes a single 'unit' in one file, not a .cpp/.h pair of files. The language very clearly defines what goes where. In fact 'interface' and 'implementation' are keywords of turbo pascal. Please don't think I am stating that code should be in the interface - it should not, by any means. You can't do this in pascal (you can accidentally do this in C/C++, since the you are handling this, and not the compiler). I believe our coding practices are very similar and very proper - we are on the same page, here.

    I am not sure what you mean by "I am not sure where you learned that program flow is dependent on how functions are placed in header files", but I believe this comment was based on your misunderstanding of something I stated. Please confirm if this is the case. I certainly do not believe that program flow depends on any function placement in header files, as I have no code in header files.

    You state: "The reason I said that the C/C++ paradigm is similar to Pascal's units is that functions are defined once in a .h file, implemented once in a .c/.cpp file, and to "use" them you just need to #include the .h file. The compiler and linker take care of the rest much like with Pascal." which I agree with...

    ...but, the point is that you don't 'just' need to include the .h file. You have code defines and namespaces, and place includes in the proper places to make sure it all flows together, and so you don't include things more than once, or that you don't have access to things you shouldn't. All the stuff you have to do to make this work in C/C++ should be handled by the compiler. Yes, I know it is not difficult, and most C programmers probably think 'so what?'. But it is work that the compiler should do. Just how I do not worry about compiling and linking unchanged code, I just click 'build'. The IDE handles what I should not have to worry about. Units in pascal handle what I should not have to worry about with structured programming. With units, there's no extra work, and no chances for errors. Being a Delphi programmer, I thought you would know all about units and their benefits (perhaps Delphi doesn't have them?).
  26. #29
  27. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,158
    Rep Power
    2222
    Originally posted by Jason Doucette
    ...but, the point is that you don't 'just' need to include the .h file. You have code defines and namespaces, and place includes in the proper places to make sure it all flows together, and so you don't include things more than once, or that you don't have access to things you shouldn't.
    To keep from having to worry about including something more than once, which could lead to multiple-definitions errors, use "guard defines" in every header file; e.g., in foobar.h:

    Code:
    #ifndef _FOOBAR_H_
    #define _FOOBAR_H_
    
    // place body of header file here
    
    #endif
    If you look at the header files created by VC++6, you will see guard defines in use, only theirs take up nearly the entire line.

    But another thing to worry about while including header files is to place the #include statement before any header files that depend on that header file.
  28. #30
  29. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,158
    Rep Power
    2222

    My Own Two Cents


    Just want to throw my few cents in concerning Pascal vs C, FWIW.

    I used to be a Blaise'r, but now I'm a C'er. I took the very first Pascal class our university offered in 1980, with an unforgiving compiler they had smuggled in from Canada. That was standard Pascal. Then I worked professionally with a Data General Pascal, a BSO Pascal, VAX-11 Pascal, and then finally Turbo Pascal before moving on to C++.

    Pascal was created by academics as an academic language to be used in teaching structured programming. The standard works well enough, but can only handle sequential files and teletype displays. Therefore, every single industrial-strength compiler had to be extended and every single compiler added their own proprietary extensions. That means that a program written for the Data General would not compile on the VAX-11, but rather had to be rewritten. The same goes for trying to run a QuickPascal program under Turbo Pascal. Pascal source code is just not portable between different platforms.

    Standard Pascal kind of foresaw that problem and solved it with p-code -- pseudo-code for a pseudo-machine. Actually, the problem being addressed was the standard one about different platforms not being able to run each other's executables -- the native code problem. The plan was that a Pascal compiler would compile to the machine language of this pseudo-machine and then each platform that would run it would have an interpreter that would interpret that p-code. An added benefit would be/should have been that extensions would also be encoded as p-code and so could also be run. The idea never caught on at the time, but was resurrected in Java and its virtual machine. Just think, if they had brought Pascal out just 15 years later, it would have been the wave of the future.

    OTOH, C was created from the start by practicing programmers as a working language that had to deal with the entire range of practical problems that they had to work with and solve. And it evolved as a working language to include features that would handle higher-level and lower-level (eg, including assembly instructions, bit-fiddling, and accessing specific memory locations and hardware registers). It has a full toolbelt, which maybe sometimes causes you to see a butt-crack as it's bent down working, but it's a good worker and it gets the job done. Elegance has its place, but the job still needs to get done.

    Because of C's standard library, standard C is already industrial strength. Except for OS or hardware-specific code, you can take any standard C program written on one platform and compile and run it on any other platform. And additional libraries written for C can also -- barring OS and hardware-specific code -- be compiled and used on any platform that has a C compiler. That was even the basic reason why UNIX was written in C, so that UNIX could be easily ported to any hardware platform that had a C compiler.

    That's the bottom line: C is portable, whereas Pascal is not. Turbo Pascal was beautifully extended. With Turbo Pascal, I could do almost anything possible on that DOS PC and I couldn't find anything that Turbo C could do that Turbo Pascal couldn't also do. Turbo Pascal was just as powerful as C was on the PC. But my Turbo Pascal code could only run on a DOS machine. If someone had a UNIX or a Mac box, my code would have to be rewritten. It was not portable and if/when I move on to other systems that body of code will be useless. But my C code IS portable and I can take it with me to whatever systems I will go and I can share it with almost anyone.

    C is the closest thing we have to a universal computer language.

IMN logo majestic logo threadwatch logo seochat tools logo