You see pretty often here people saying that they have a x million of lines of code project. How is this measured? Is this number, the number shown under 'Information' menu? The manual says that only the compilable lines are counted (so, without comments and empty lines):
Source compiled -> Displays total number of lines compiled.
But the manual doesn't explain how a piece of code as if/then/else is counted:
if B=true
then
for i:= 0 to 100
do Stuff
else ;
Is every line that has a blue dot is a "compiled line"?
The Embarcadero code (the RTL and VCL code) and 3rd party libraries are also included into the count?
(The conclusion) What does it mean when somebody says about a Delphi program that it has 1 million lines?
The Total lines the compiler tells you is counting the number of lines in the unit(s), regardless of what code is (or isn't) there. It even counts blank lines. Start a new project. Compile it and note the number of lines it says (mine says 42). Then, add just one line break somewhere, and compile again. It will claim there is one more line of code (43). So it does not seem the compiler takes any code into consideration for this number - only the actual line breaks.
In fact, if you add the total number of lines in the main form's unit (new project) as well as the project's main file, it will total to 2 less than what the compiler tells you (40 out of 42). So I wouldn't trust this number to mean much other than a rough estimate.
Libraries such as VCL, RTL, and Indy are not included in this count because those are pre-compiled. It is possible that your project might refer to a library or external unit which needs to be compiled, thus it will also include those into the count.
As far as your mention of how it counts if..then..else blocks, keep in mind that your 5 lines of code can be combined into just 1 line of code (stripping line breaks) and it will still compile, and the compiler will count only 1 line, not 5 lines.
Related
COBOL program B has 3 entry points. Linkage section contains 1 general area, and then 3 areas (call them link-sect-a, link-sect-b and link-sect-c)
Cobol program A calls program B using entry 3. In z/OS, it's perfectly valid (and normal) to write
CALL PROGB-ENTRY3 using common area, link-sect-c
The trouble seems to be with GnuCobol, that after compiling both, anything as simple as the following in program B after entry point 3
DISPLAY 'First 50 bytes in link-sect-c 'link-sect-c(1:50)
causes a crash on the reference to link-sect-c
If instead, I change the call in program A (as well as the entry 3 in program
B to include all 4 arguments) to
CALL PROGB-ENTRY3 using common area, link-sect-a, link-sect-b, link-sect-c
(even though I have no need for either link-sect-a or link-sect-b)
the code works
I can include the 2 example programs if required, since they're really quite trivial
I added the option -fsticky-linkage to the compilation of program B, and that solved the problem. (It was easy to confirm it. Remove the option and compile again; problem reintroduced)
I'm having some issues isolating errors in my 837. The system that's interpreting my 837 is giving me a segment where the error is found, but since I have so many claims (and therefore segments), I can't just count the segments until I get to the one I need.
Is there some way of finding a specific segment line? I know the general area the segment line is in (based on the an account number the error is listed under), but I have no way of knowing which of the segments has the errors.
Here's an example of what I mean. There's revenue codes listed after the SV2, then a corresponding code, then the cost of that code.
SV2*0450*HC:96368*100.00*UN*1~
DTP*472*D8*20171204~
LX*13~
SV2*0450*HC:96371*700.00*UN*5~
DTP*472*D8*20171204~
LX*14~
SV2*0450*HC:96372*50.00*UN*1~
DTP*472*D8*20171204~
LX*15~
Thanks.
Please take a look at X12 Parser
loop.getLoop("2400", 0).getSegment("SV1").getElementValue("SV101")
can get you the value needed.
For more examples look at X12ReaderTest
I'm wondering what techniques are employed to fast lex a huge source file (e.g. C++) in popular text editors.
Re-lexing an entire document each time I edit the file (i.e. I add some characters) could quickly become unfeasible.. but those characters might change everything (towards the top, towards the bottom or both) into the source file, as it is the case when inserting
/*
or
\*
halfway through the huge file.
Is there a standard approach to runtime lexing?
I'd assume the same techniques that are used to lex source files by compilers.
A good FSA-based lexer (or a hand-written one) spends only a few instructions per character. Assume a klunky machine that takes 5 nS to execute an instruction (way slow WRT modern workstations). If you have a million-character buffer (that's about 300,000 lines of 30 characters), and it takes 10 instructions to process each, the total lexing time is 50 million nS = .05 second.
Why do you think this is a problem?
I'm surprised that searching j__objc_msgSend returns 0 result on stackoverflow, and Google doesn't seem to know it well either. According to it's disassembly, j__objc_msgSend only calls objc_msgSend, then why do we need j__objc_msgSend when we have objc_msgSend already? And in general, what's the difference of j__objc_msgSend and objc_msgSend?
And in this screenshot specifically, what's the difference of the right most branch ending with "End of function", and the left most branch ending without "End of function"? Does it have something to do with j__objc_msgSend?
This is ARM RISC code, and the preferred programming mode for ARM is relative -- don't use absolute addresses, always use "IP+/-offset". Here, the called address was out of range for a direct call or jump, and the compiler used the nearest he could find. It adds an extra jump (or more than 1!) but it's position-independent. (*)
The compiler cannot construct a jump to the target address with a simple instruction, because you cannot immediately load every possible 2^32 number with RISC assembly.
If the routine objc_msgSend returns of its own, then this is equivalent to call objc_msgSend; return -- only shorter. Both forms do a single 'return', from the point of view of the current function.
(*) You can see in the disassembly screenshot (?? why not text?) that R12 gets loaded with the difference between the target and the current address. This difference is calculated by the compiler; it does not appear as a subtraction in the original binary, that's IDA's work. Then the difference is added to the current address -- whatever this is! The immediate value objc_msgSend - 0x1AE030 uses a small enough amount of bits to be loaded into R12 in a single instruction (an ARM RISC 'feature' you ought to be familiar with).
In case you are wondering about the j__label syntax: that's just IDA, telling you this is a direct jump to a known label. Presumably, if your code is long enough, you might find the distance to this label is too big again, and so you might find j__j__objc_msgSend.
I need to vectorize with SSE a some huge loops in a program. In order to save time I decided to let ICC deal with it. For that purpose, I prepare properly the data, taking into account the alignment and I make use of the compiler directives #pragma simd, #pragma aligned, #pragma ivdep. When compiling with the several -vec-report options, compiler tells me that loops were vectorized. A quick look to the assembly generated by the compiler seems to confirm that, since you can find there plenty of vectorial instructions that works with packed single precision operands (all operations in the serial code handler float operands).
The problem is that when I take hardware counters with PAPI the number of FP operations I get (PAPI_FP_INS and PAPI_FP_OPS) is pretty the same in the auto-vectorized code and the original one, when one would expect to be significantly less in the auto-vectorized code. What's more, a vectorized by-hand a simplified problem of the one that concerns and in this case I do get something like 3 times less of FP operations.
Has anyone experienced something similar with this?
Spills may destroy the advantage of vectorization, thus 64-bit mode may gain significantly over 32-bit mode. Also, icc may version a loop and you may be hitting a scalar version even though there is a vector version present. icc versions issued in the last year or 2 have fixed some problems in this area.