Has anyone converted the C librarys to FreePascal?

[winni]

Here is the file against the fake news.

What I did:

* A recursive grep start at fpcsrc/3.0.4/
* Let grep count the occurances per file
* A numeric sort on the second field: the count
* wrote it to a file
* manually deleted all files with count 0

Now it's only 28k and is attached.

Winni

Oops - as I just saw: I included all binaries files. Lazy me.

[del]

Question marks are an integral part of the C language,,,,, This is legal:

Code: C  [Select][+][-]

1. const int n = (x != 0) ? 10 : 20;

Does it have logic? (note const..)

What you see is what you get.

batch.cpp: In function ‘bool BatchScale(CppOpsFrame*, const string&, const wxArrayString&, wxGauge*, DispPan*)’:
batch.cpp:148:29: warning: ‘x’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 
 Compilation finished successfully.

x -226405976
n 10

And don't even THINK about changing that "n".

batch.cpp: In function ‘bool BatchScale(CppOpsFrame*, const string&, const wxArrayString&, wxGauge*, DispPan*)’:
batch.cpp:148:7: error: assignment of read-only variable ‘n’
  n += 5;
       ^
 Compilation failed.

[Thaddy]

N would be not n. My first example shows that, and NO Visual Studio will not help as somebody wrongly suggested.

[howardpc]

@winni
I think we are talking about apples and oranges.
The figure I quoted arises from counting += in only 3 kinds of fpcsrc files: .pas, .inc, .pp
You are counting in files such as .fpc, .fpcmake, makefile*, .msg, .dat, .js, .ppu, .it, .png, .tga, .res ,.pdf and others too it seems.

These are all beside the point. My point is solely about Pascal source files in the fpc source tree, which abound in their use of +=.
I am not trying to promote the use of Cisms. I merely point out that they were introduced by an FPC developer who clearly convinced the rest of the core team of the value of this abbreviated syntax as an extension to traditional Pascal.
And either he or other developers make free use of the syntax now it is there.

[winni]

No, we are  not  talking about apple and oranges. We are talking about the ability of counting to ten.

Look at my list - and then count all your 3 pascal files. What will be left? A little of nothing. Your 30.000 and something occurances of += derive all from the makefiles.

I'll make you a list of the occurances in the *.pas,*pp and *.inc file. Small file. Will be back soon.

[del]

N would be not n. My first example shows that, and NO Visual Studio will not help as somebody wrongly suggested.

OK. To answer your question: Yes. It does have logic. The compiler did as you expected it would do. It even gave you the courtesy of a warning. You're conditionally initializing a constant. The slop comes in when parts of the condition are not initialized and left to chance. I would not want Visual Studio or anything else to "help" me other than give the warning. That's the problem with Python - too much "help", and Heaven forbid if one indent slips and blows up pages of code.

[winni]

@howardpc

Now you get the complete list of all *.pas *.pp *.inc files containing +=.

Poor result of 61 files. And

* It is not checked if the += is inside a comment
* It is not checked if the += is inside a string

Further: A lot of the filse having to do with Java or Makefile.

As I said: Two of the testfiles are going wild with a lot of +=

In the rest of the poor list every file is containing less that 10 counts; most only 1,2 or 3.

The C syntax is not used in pascal - and that is a good result!

[howardpc]

I take your points about files containing += in string literals and comments, which should not be counted, and one or two files skewing the overall total of raw += instances.
Looking in detail at the results and removing comment and literal cases, I now count a total of 34 files containing a total of 263  "real" uses of +=,
along with the three "wild" tests/webtbs files which between them house a further 33,074 instances of +=. So use of += is not as widespread in the sources as it first appeared to me.

The "wild" test files do show the usefulness of the syntax in some circumstances, though. Using traditional syntax would inflate those test files considerably, perhaps enough to adversely affect download time of the svn tree.
My search result file, omitting the 33,074 instances (which make the file too large to attach here) is attached.

[winni]

So you get the same small result as me: 2 pages.

Then I take my 61 files and compare it with whole fpsrc directory tree. In my case I find 15943 files.

61 / 15943  results in 0,38 %.  Engineers call this noise.

So we can call this "C Noise" and turn the page.

Winni

[del]

Wow. Don't mean to jack the thread (too late, it's jacked) but I use *= a lot more (39 times) than += (0 times) on this project I'm working on. I'm quoting my config options below. This all originated in some Delphi stuff I did a bazillion years ago. I didn't deliberately enable the C Style operators (I love them) but I get to use them.

So what is it in my configuration file that's enabling +=, -=, *=, and /=? There are a couple of places in the project option pages where you can click on a checkbox to enable these operators. One the "Parsing" page it's checked (-Sc, {$COPERATORS ON}). Then on the "Custom Operations" page the -Sc box is unchecked. I think we're already more than pregnant with this capability. Could we not just call it good and give it our blessing?

<?xml version="1.0" encoding="UTF-8"?>
<CONFIG>
  <CompilerOptions>
    <Version Value="11"/>
    <PathDelim Value="\"/>
    <SearchPaths>
      <IncludeFiles Value="$(ProjOutDir)"/>
    </SearchPaths>
    <Parsing>
      <SyntaxOptions>
        <SyntaxMode Value="Delphi"/>
      </SyntaxOptions>
    </Parsing>
    <CodeGeneration>
      <SmartLinkUnit Value="True"/>
      <TargetOS Value="linux"/>
      <Optimizations>
        <OptimizationLevel Value="3"/>
      </Optimizations>
    </CodeGeneration>
    <Linking>
      <Debugging>
        <GenerateDebugInfo Value="False"/>
      </Debugging>
      <LinkSmart Value="True"/>
    </Linking>
    <Other>
      <ConfigFile>
        <StopAfterErrCount Value="4"/>
      </ConfigFile>
      <CompilerMessages>
        <IgnoredMessages idx5058="True" idx5057="True" idx5037="True" idx5036="True"/>
      </CompilerMessages>
      <CustomOptions Value="-dBorland -dVer150 -dDelphi7 -dCompiler6_Up -dPUREPASCAL"/>
    </Other>
  </CompilerOptions>
</CONFIG>

[winni]

No. I remind that there are so simple things like inc(), dec() and (sqr().
But if we want to continue to discuss how to foozle the pascal language:
I prefer Label and Goto. One can make a lot of nonsense with it.
And it brings back that good old 80s Basic feeling. Gosub nowhere ....

[del]

Thank you. I was hoping for something more "dry" and more narrowly addressed to the specifics of my question.

[RayoGlauco]

Many years ago, I discovered C and its abbreviated expressions, as is that    const int n = (x! = 0)? 10: 20;    that appeared in a previous post. I liked it, because you can do many things using a few text. But now, I look at this expression, and I need some time to understand what it means. Not good for debugging.

In this regard, I remember that when I was studying at the university, I saw an announcement of a "dirty programming in C" contest. It was about making an absolutely unintelligible C program that did some useful task. 

[Handoko]

Pascal encourages good programming practices, their source codes usually are relatively easy to read and debug. C/C++ are great too. Unfortunately their users 'prefer' to type less and use more symbolic characters. And they are proud of it.

The world's smallest chess program written in C:
https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Toledo_Nanochess

That's why I prefer Pascal.

[marcov]

It can't be that bad since fpc has adopted some of it.

+=,. -= *= etc..

FPC hasn't adopted those. They are only supported for conversion purposes, and were never intended to be used in newly written pascal code.

If that is really the case, how do you account for the 33,403 occurrences of += counted today in a trawl of recent FPC sources (never mind use of Cisms in the LCL)?

A very good reason to not implement more such abominations on "narrow use" arguments and be very careful with such language features in the first place. If the cat is out of the bag, things intended for rare, specific cases will suddenly be mainstream.