Page 5 of 9 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 84

Thread: C/C++ vs Pascal

  1. #41

    C/C++ vs Pascal

    True.

    Nevertheless it is an important point regarding the languages. Therefore might I suggest we compare certain mostly used compilers of C, C++ and Pascal and Object Pascal? I am myself not too knowledgeable regarding the compilers but with a wild guess I would say those mostly used are the following (please correct or add if required):

    For (Object) Pascal:
    * FreePascal
    * "Delphi"

    For C/C++ :
    * GCC / G++
    * Microsoft Visual C++



    EDIT:
    http://www.kuro5hin.org/story/2004/2/7/144019/8872
    This article was residing among my bookmarks. Perhaps it will prove useful to anybody here.

  2. #42

    C/C++ vs Pascal

    Compilation time for pascal is great because most compilers are one-pass. This disallows funny/unfunny stuff like macros. As a uC programmer, this is a must have. If there ain't macros the compiler will need hardcoded syntax extensions
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  3. #43

    C/C++ vs Pascal

    So what exactly IS a macro? That's something I'm not sure about, but i think it is something that does repetitive work for you.
    --MagicRPG--

  4. #44

    C/C++ vs Pascal

    {$define <identifier> := <some complex expression>}

    After that, every time the compiler sees that identifier it treats it as that complex expression. Not a much by itself, but when combined with conditional compiler directives macro can become a very powerful tool.

    I, for example, built with their help something akin to generics in FPC 1.1 (there wasn't even 1.9 yet!) . Of course, handling it all is a pain, compiler (at least its earlier versions) could not pinpoint the error location properly if macros are involved, the code completion in Lazarus died trying to parse that stuff... But it worked, and helped me a lot.

  5. #45

    C/C++ vs Pascal

    Quote Originally Posted by Chebmaster
    {$define <identifier> := <some>}
    isn't that just a compiletime variable? I define a macro as either a compiletime variable or compiletime inline function.

    {$define <identifier>(parameters) := <some>}
    {$define <identifier> := <some>}
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  6. #46

    C/C++ vs Pascal

    Quote Originally Posted by JSoftware
    Quote Originally Posted by Chebmaster
    {$define <identifier> := <some>}
    isn't that just a compiletime variable? I define a macro as either a compiletime variable or compiletime inline function.

    {$define <identifier>(parameters) := <some>}
    {$define <identifier> := <some>}
    AFAIK fpc does not allow parameters (in libnds conversion I had to change a lot of defines to inline functions). Maybe do you mean in Delphi?
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

  7. #47

    C/C++ vs Pascal

    Quote Originally Posted by Legolas
    Quote Originally Posted by JSoftware
    Quote Originally Posted by Chebmaster
    {$define <identifier> := <some>}
    isn't that just a compiletime variable? I define a macro as either a compiletime variable or compiletime inline function.

    {$define <identifier>(parameters) := <some>}
    {$define <identifier> := <some>}
    AFAIK fpc does not allow parameters (in libnds conversion I had to change a lot of defines to inline functions). Maybe do you mean in Delphi?
    No, I mean I could use something like that
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  8. #48
    I generally avoid discussions like this, but at least this is in the right forum for avoiding stupid pro C++ arguments like comparing C++ to Pascal of the 70's. They always do that because they don't know Pascal, they just want to flame it and giving themselves a reason to forget the question.

    But I have a special reason to wake up this old thread. We teach OpenGL in C (not because I like it but because it is the closest to a common denominator language for students with no nice teaching language in their background). I chose that simply because I need to fight one battle at a time. I feel that it could work so much better if we used FPC, and a decent IDE, but the rest of the university seems to hate my ideas. They seem to prefer Emacs + Unix terminal, students that can't debug, Java and C++.

    But the other day some students questioned the choice. Well, no wonder, I don't like C myself. (They should see my anti-C T-shirts. How about "C is a grade" on a T-shirt? I have it...)

    I have been collecting arguments. What features are important in a teaching language? Portability? No problem for FPC. Readability, intutive syntax? I think FPC is superb in that respect but how do you measure it? Language features? I think FPC has plenty (operator and function overloading, automatic namespaces, dynamic arrays, some garbage collection - but not for everything) but what am I missing? It even has portability to C/C++/Java as a bonus, anyone knowing FPC well will learn C/C++/Java easily (but might not like it).

    I think that OOP being an optional feature in FPC programs is a great thing. Teaching can start out procedural, students who work more efficiently without it or by mixing the two methods may do that as they please. That is IMHO much better than using a stupid language like Java that tries to force people into the "only way". I hate that and believe the very idea, locking in the thoughts of students in One Ring To Rule Them All, should be banned from universities. (So even C++ is better in that respect.)

    So... are there other arguments that would help me speak in favor of FPC, or pitfalls that I should prepare myself for?

  9. #49
    The main issue here is that C/C++ is more widely used, which means it shows up more often in research papers and more people at universities know how to read/write it. FPC would be a good alternative, but it's hard to convince people because pascal became populair in the 80s and most people still have that picture in mind. If it was something brand new, it would be way easier.

    One thing that strikes me though, is that most people here seem to think that pascal is "the" language (ok, it's a pascal forum haha) and also that learning languages is hard. I've experienced that once you know the concepts it's not that hard to learn C/C#/Java/Python/Ruby etc etc.. I'd advice everyone to do so. I see languages as tools and every tool has it's pro's and con's. Knowing a bunch of them makes you a better programmer, because you will see how each language would solve a problem, which allows you to pick the right tool for the right job.
    It's true that pascal has a lot of features and power, but it's not neccesarily a reason to "not learn" other languages. The biggest advantage of having a "big toolbox" is that you can easily work together with other programmers, and have fun (which is where programming is all about ) , without having to debate about the language to use. There is no "best" language.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  10. #50
    Quote Originally Posted by Chebmaster View Post
    There is a big difference between FPC and Delphi in one aspect.
    Free Pascal allows you to perform arithmetic operations with pointers.
    Code:
    var
      p&#58; pointer;
      a, b&#58; integer;
    ...
    p&#58;=p + &#40;a*b&#41;;
    In Delphi you must add a lot of unnecessary typecasts:
    Code:
    p&#58;=pointer&#40;cardinal&#40;p&#41; + &#40;a*b&#41;&#41;;
    Which is stupid IMO, because the pointers in themselves are a way around the strong typing.
    this is incorrect, since delphi 2009 there is a directive to allow pointer maths......

    Code:
    {$POINTERMATH ON}
    since i use it all the time....

Page 5 of 9 FirstFirst ... 34567 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •