8

I'm trying to build, using msvs 2010 the project found at the following git:

https://github.com/Joonhwan/exprtk

The problem is when I comment out the line 48 '#define exprtk_lean_and_mean' in exprtk.hpp file, I get the following compiler error:

Error   1   error C1128: number of sections exceeded object file format limit : compile with /bigobj

Googling the error, seems to indicate the the compiled translation unit has compiled to something larger than an arbitariy limit, and adding 'bigobj' to the command line should fix the problem (which it does). Compiling the code with gcc (4.3), works without a glitch.

My questions are:

  1. Does c++ place a limit on the number of types that can be had in a translation unit?

  2. Is the way the code is laid out in this project bad practice? (when googling I noticed a lot of boost libraries have the same problem eg: Boost.Sprit)

Ismael
  • 2,995
  • 29
  • 45
Gelly Ristor
  • 573
  • 1
  • 6
  • 17

2 Answers2

14

Does c++ place a limit on the number of types that can be had in a translation unit?

Note that the maximum values of such parameters are left open for particular implementations. The standard only enforces minimum requirements that must be supported by an implementation. An implementation will document the maximum values it supports and in this case MSVC implementation does so.

These are defined in a special section of the C++ standard.

Annex B - Implementation quantities

  1. Because computers are finite, C + + implementations are inevitably limited in the size of the programs they can successfully process. Every implementation shall document those limitations where known. This documentation may cite fixed limits where they exist, say how to compute variable limits as a function of available resources, or say that fixed limits do not exist or are unknown.

  2. The limits may constrain quantities that include those described below or others. The bracketed number following each quantity is recommended as the minimum for that quantity. However, these quantities are only guidelines and do not determine compliance.
    — Nesting levels of compound statements, iteration control structures, and selection control structures [256].
    — Nesting levels of conditional inclusion [256].
    — Pointer, array, and function declarators (in any combination) modifying an arithmetic, structure, union, or incomplete type in a declaration [256].
    — Nesting levels of parenthesized expressions within a full expression [256].
    — Number of characters in an internal identifier or macro name [1 024].
    — Number of characters in an external identifier [1 024].
    — External identifiers in one translation unit [65 536].
    — Identifiers with block scope declared in one block [1 024].
    — Macro identifiers simultaneously defined in one translation unit [65 536].
    — Parameters in one function definition [256].
    — Arguments in one function call [256].**
    — Parameters in one macro definition [256].
    — Arguments in one macro invocation [256].
    — Characters in one logical source line [65 536].
    — Characters in a character string literal or wide string literal (after concatenation) [65 536].
    Size of an object [262 144].
    — Nesting levels for #include files [256].
    — Case labels for a switch statement (excluding those for any nested switch statements) [16 384].
    — Data members in a single class, structure, or union [16 384].
    — Enumeration constants in a single enumeration [4 096].
    — Levels of nested class, structure, or union definitions in a single struct-declaration-list [256].
    — Functions registered by atexit()[32].
    — Direct and indirect base classes [16 384].
    — Direct base classes for a single class [1024].
    — Members declared in a single class [4 096].
    — Final overriding virtual functions in a class, accessible or not [16 384].
    — Direct and indirect virtual bases of a class [1 024].
    — Static members of a class [1 024].
    — Friend declarations in a class [4 096].
    — Access control declarations in a class [4 096].
    — Member initializers in a constructor definition [6 144].
    — Scope qualifications of one identifier [256].
    — Nested external specifications [1 024].
    — Template arguments in a template declaration [1 024].
    — Recursively nested template instantiations [17].
    — Handlers per try block [256].
    — Throw specifications on a single function declaration [256].

Community
  • 1
  • 1
Alok Save
  • 202,538
  • 53
  • 430
  • 533
  • These minimums in the square brackets, because they're 'recommended' can not be used as minimums that would define if a compiler is compliant towards the standard or not - is this correct? – Gelly Ristor May 14 '12 at 06:01
  • @GellyRistor: Yes that is true.But most of the mainstream standard compliant compilers will atleast support these minimum requirements and they do. – Alok Save May 14 '12 at 06:04
  • 2
    One more question, given the list above, which one of them defines the recommended number of 'sections' which the msvc 2010 compiler is complaining about? – Gelly Ristor May 14 '12 at 06:10
  • @GellyRistor: I think it might be the binary object size and so I made it bold, but it could be perhaps some other value like number of identifiers in a scope.I am not sure hence posted the entire list. – Alok Save May 14 '12 at 06:12
  • I see, it makes sense now. So it seems that the compiler is at fault, not the library. – Gelly Ristor May 14 '12 at 06:17
  • 1
    @GellyRistor: It's probably "External identifiers in one translation unit", in combination with the "Edit and Continue" option of MSVS. That option puts every function in its own section, to facilitate easy replacement. – MSalters May 14 '12 at 07:59
7

The limitation is inside OBJ format used by old versions of MSVC and corresponding linkers. So while this restriction is arbitrary it could not be made default behavior for new versions of compilers. Check out description of the /bigobj option:

Linkers that shipped prior to Visual C++ 2005 cannot read .obj files that were produced with /bigobj.

Ismael
  • 2,995
  • 29
  • 45
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • 1
    And since you're using C++ (not C), mixing compiled code from several different Visual Studio versions is unlikely to work anyway. – MSalters May 14 '12 at 07:57