By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,925 Members | 1,134 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,925 IT Pros & Developers. It's quick & easy.

Program size limitation

P: n/a
AB
Hello all,

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Any ideas?

Jul 13 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
AB wrote:
Hello all,

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?
Depends on your compiler.

--
Ian Collins.
Jul 13 '06 #2

P: n/a
"AB" <ab*****@gmail.comwrites:
I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Any ideas?
The C standard imposes no specific limit on the number of lines either
in a translation unit or in a program. A compiler could impose such a
limit, I suppose, but there's no particular reason to do so (unless
it's a cripped demo). As far as I know, it's the same for C++.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 13 '06 #3

P: n/a
AB a écrit :
Hello all,

I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Any ideas?
Some compilers (like MSVC 6.0 for instance) would have problems
when compiling sources with more than 65535 lines. This is due
to the debug information format that MSVC was using some years ago.

Other compilers have no practical limits, even if the OS can have some
limitations.

Gcc under windows (mingw) stops at more than 65535 relocations in an
object module. lcc-win32 had this limit some years ago but I took it
away, maybe mingw has done that too, I do not know.

Of course there is the limitations of disk space (I think that above
1000 million lines your hard disk starts getting full) and there is some
limitations in executable size: under 32 bits systems you usually
can't have a program of more than 2GB size (2GB reserved for the
system) or at most 3GB... This surely puts a stop in the number of lines
of code your program can have. 64 bits systems do not have that
limitation but may have others, since no one has implemented a full
64 bit virtual space yet.

jacob
Jul 13 '06 #4

P: n/a
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:44*********************@news.orange.fr...
AB a écrit :
>I heard once that there is a limitation on the number of lines of code
that a program can have when using C, but not for C++. Is this true?

Of course there is the limitations of disk space (I think that above
1000 million lines your hard disk starts getting full) and there is some
limitations in executable size: under 32 bits systems you usually
can't have a program of more than 2GB size (2GB reserved for the
system) or at most 3GB... This surely puts a stop in the number of lines
of code your program can have.
Not true. Someone here recently posted an example of a program that had
thousands of lines of code, branches, computed gotos, functions, etc. that,
after optimization, resulted solely in the machine code equivalent of
"return 7;". It is a common beginner mistake to assume that source code
size has any relation to the output code size.

Also, even on 32-bit systems, there is no fundamental limit of 2GB or 3GB;
that's an implementation detail. There is at least one x86 Linux variant
that gives user code 4GB minus a few (4kB) pages for trapping NULL and for
switching to kernel page tables on a syscall. If that's not enough, the
implementation could implement overlays so that the actual program could
exceed 4GB, just not with all parts loaded at the same time. MS implemented
similar tricks in Windows for accessing parts of 36-bit PAE memory within
32-bit userland.

Even disk space is not a practical limitation, since one can always add more
disks to make bigger arrays and use multiple object files if a single object
would exceed a 64-bit filesystem.

The only practical limit is in how complex a program can get and still be
correct and maintainable.
64 bits systems do not have that limitation but may have others, since
no one has implemented a full 64 bit virtual space yet.
That's really no different than the 32-bit non-limits.

I am a little curious what happens when __line__ exceeds the range of a long
long, though...

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

Jul 13 '06 #5

P: n/a
"Stephen Sprunk" <st*****@sprunk.orgwrites:
[...]
I am a little curious what happens when __line__ exceeds the range of
a long long, though...
(__LINE__, not __line__)

__LINE__ expands to

The presumed line number (within the current source file) of the
current source line (an integer constant).

(C99 6.10.8p1)

Presumably it could be an unsigned long long literal. I suppose an
attempt to use __LINE__ when the line number exceeds ULLONG_MAX would
invoke undefined behavior.

The "#line" directive can be used to change the presumed line number,
but:

The digit sequence shall not specify zero, nor a number greater
than 2147483647.

(C99 6.10.4p3)

That's not in a constraint, so attempting to use #line to set the
presumed line number to ULLONG_MAX would invoke undefined behavior.

I see this is cross-posted to comp.lang.c++; the C++ rules may be
different.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 13 '06 #6

P: n/a
In comp.lang.c++ jacob navia <ja***@jacob.remcomp.frwrote:
: AB a ?crit :
: Hello all,
: >
: I heard once that there is a limitation on the number of lines of code
: that a program can have when using C, but not for C++. Is this true?
: >
: Any ideas?
: >

TI suspect the 4 GByte limitation is for "flat mode" with x86 architecture,
meaning un-segmented (all code in one s32-bit segment), as then the max
offset for EIP = 2^32 - 1.

-- Scott
==========
: Some compilers (like MSVC 6.0 for instance) would have problems
: when compiling sources with more than 65535 lines. This is due
: to the debug information format that MSVC was using some years ago.

: Other compilers have no practical limits, even if the OS can have some
: limitations.

: Gcc under windows (mingw) stops at more than 65535 relocations in an
: object module. lcc-win32 had this limit some years ago but I took it
: away, maybe mingw has done that too, I do not know.

: Of course there is the limitations of disk space (I think that above
: 1000 million lines your hard disk starts getting full) and there is some
: limitations in executable size: under 32 bits systems you usually
: can't have a program of more than 2GB size (2GB reserved for the
: system) or at most 3GB... This surely puts a stop in the number of lines
: of code your program can have. 64 bits systems do not have that
: limitation but may have others, since no one has implemented a full
: 64 bit virtual space yet.

: jacob
Jan 24 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.