Too Many Function Pointers?

Discussion in 'C++' started by Bryan Parkoff, Dec 16, 2005.

  1. C/C++ Compiler encourages to limit 1,000 functions under function
    pointer, but I am allowed to overlimit 4,096 functions. I am just for fun
    to test how it works.
    The problem is that source code can only limit 64K lines otherwise C/C++
    Compiler will fail to compile. It can't be done in static, but it can be
    done at run-time to save source code's space.
    I wrote ten sample functions. I did allocate function pointer into
    memory at run-time (256K memory space). Then for...loop copies one of ten
    sample functions' memory address into function pointer 65,536 times.
    Function Pointer is now contained 65,536 functions into memory. Another
    for...loop did execute all 65,536 functions through function pointer using
    fprintf(...).
    Text.Log is created from fprintf(...) has shown all executed 65,536
    functions through function pointer. It works perfectly for larger project.
    Can you please comment your opinion? Do you think it is too much
    functions like overhead CPU? Try to compare to switch(...) because it can
    only limit 32K or less. I believe that function pointer is the best
    solution for great cache because most functions are smaller.

    Bryan Parkoff
     
    Bryan Parkoff, Dec 16, 2005
    #1
    1. Advertising

  2. Bryan Parkoff

    red floyd Guest

    Bryan Parkoff wrote:
    > C/C++ Compiler encourages to limit 1,000 functions under function
    > pointer, but I am allowed to overlimit 4,096 functions. I am just for fun
    > to test how it works.
    > The problem is that source code can only limit 64K lines otherwise C/C++
    > Compiler will fail to compile. It can't be done in static, but it can be
    > done at run-time to save source code's space.
    > I wrote ten sample functions. I did allocate function pointer into
    > memory at run-time (256K memory space). Then for...loop copies one of ten
    > sample functions' memory address into function pointer 65,536 times.
    > Function Pointer is now contained 65,536 functions into memory. Another
    > for...loop did execute all 65,536 functions through function pointer using
    > fprintf(...).
    > Text.Log is created from fprintf(...) has shown all executed 65,536
    > functions through function pointer. It works perfectly for larger project.
    > Can you please comment your opinion? Do you think it is too much
    > functions like overhead CPU? Try to compare to switch(...) because it can
    > only limit 32K or less. I believe that function pointer is the best
    > solution for great cache because most functions are smaller.
    >
    > Bryan Parkoff


    1. Your question is incomprehensible. Please see FAQ 5.8:
    http://www.parashift.com/c -faq-lite/how-to-post.html#faq-5.8
    2. Compiler limitations are off topic here. Please ask in a newsgroup
    dedicated to your compiler/platform
    3. There is no such language as C/C++.
     
    red floyd, Dec 16, 2005
    #2
    1. Advertising

  3. Bryan Parkoff wrote:
    > C/C++ Compiler encourages to limit 1,000 functions under function
    > pointer,


    What? What are you talking about? 1000 functions under function pointer:
    what does that mean? What "C/C++ Compiler" are you talking about? There
    is no such language as "C/C++", you know that, right?

    > but I am allowed to overlimit 4,096 functions. I am just for fun
    > to test how it works.
    > The problem is that source code can only limit 64K lines otherwise C/C++
    > Compiler will fail to compile. It can't be done in static, but it can be
    > done at run-time to save source code's space.


    You're losing me here...

    > I wrote ten sample functions. I did allocate function pointer into
    > memory at run-time (256K memory space). Then for...loop copies one of ten
    > sample functions' memory address into function pointer 65,536 times.


    Care to illustrate this with code?

    > Function Pointer is now contained 65,536 functions into memory.


    I honestly fail to understand what that sentence means. How can
    a [single] function pointer (why is it capitalised in your message?)
    "contain" 64K functions "into memory"? I've always been under the
    impression that a single function pointer can only point to ("contain")
    a single function. Or is "Function Pointer" a collection of some kind
    in your explanation?

    > Another
    > for...loop did execute all 65,536 functions through function pointer using
    > fprintf(...).


    Huh?

    > Text.Log is created from fprintf(...) has shown all executed 65,536
    > functions through function pointer. It works perfectly for larger project.


    Uh... OK.

    > Can you please comment your opinion?


    I have none. I don't know what you're talking about. If it were just me,
    I'd probably not comment at all. But I am fairly certain that many others
    didn't understand what you're talking about either.

    > Do you think it is too much
    > functions like overhead CPU?


    Too much functions? Overhead CPU? No I don't think so.

    > Try to compare to switch(...) because it can
    > only limit 32K or less. I believe that function pointer is the best
    > solution for great cache because most functions are smaller.


    You lost me. Smaller than what?

    In any case, judging from my own (albeit somewhat obsolete, perhaps)
    experience, it is much better to use broken C++ to explain something here
    than broken English. I strongly suggest you try again, and this time post
    some code to supplement your narrative.

    V
     
    Victor Bazarov, Dec 16, 2005
    #3
  4. Bryan Parkoff

    Kaz Kylheku Guest

    Bryan Parkoff wrote:
    > C/C++ Compiler encourages to limit 1,000 functions under function
    > pointer, but I am allowed to overlimit 4,096 functions. I am just for fun
    > to test how it works.


    Here is how I understand your question.

    You are compiling for a platform which has some severe restrictions on
    the size of code and data. The documentation for the compiler
    encourages you to keep the program down to 1000 functions.

    There are also limitations in the compiler. It can only accept up to
    some 65,000 lines of source code in total, for some reason.

    So you have tried a trick just for fun: you copied the compiled
    function images into the data area, making lots of copies of them, just
    to show that functions can live in the data area, and you can have lots
    more of them there!

    You want to know whether you can exploit this to perhaps write a loader
    that will let you stuff more code into the system than can be compiled
    into a single program?

    > Text.Log is created from fprintf(...) has shown all executed 65,536
    > functions through function pointer. It works perfectly for larger project.


    The problem is that the functions are all the same, no? You want
    thousands of unique functions, no? What's the point of having two
    copies of the same function at two different locations?

    > Can you please comment your opinion? Do you think it is too much


    In my opinion, what you are doing is beyond standard C++. You're
    overcoming the limitations of a particular platform using various
    hacks. They are not defined to work according to standard C++. So it's
    best to discuss that with other users of the same platform, or an
    appropriate development support forum or channel.

    > functions like overhead CPU? Try to compare to switch(...) because it can
    > only limit 32K or less. I believe that function pointer is the best
    > solution for great cache because most functions are smaller.


    Whether using a table of function pointers, or using switch() is faster
    is implementation-dependent. But if one technique produces code that is
    too large, but another one fits, you can hardly compare them for
    performance. The performance of a program that you can't compile or
    load is nonexistent. :)
     
    Kaz Kylheku, Dec 16, 2005
    #4
  5. "Kaz Kylheku" <> wrote in message
    news:...
    > Bryan Parkoff wrote:
    >> C/C++ Compiler encourages to limit 1,000 functions under function
    >> pointer, but I am allowed to overlimit 4,096 functions. I am just for
    >> fun
    >> to test how it works.

    >
    > Here is how I understand your question.
    >
    > You are compiling for a platform which has some severe restrictions on
    > the size of code and data. The documentation for the compiler
    > encourages you to keep the program down to 1000 functions.
    >
    > There are also limitations in the compiler. It can only accept up to
    > some 65,000 lines of source code in total, for some reason.
    >
    > So you have tried a trick just for fun: you copied the compiled
    > function images into the data area, making lots of copies of them, just
    > to show that functions can live in the data area, and you can have lots
    > more of them there!
    >
    > You want to know whether you can exploit this to perhaps write a loader
    > that will let you stuff more code into the system than can be compiled
    > into a single program?
    >
    >> Text.Log is created from fprintf(...) has shown all executed 65,536
    >> functions through function pointer. It works perfectly for larger
    >> project.

    >
    > The problem is that the functions are all the same, no? You want
    > thousands of unique functions, no? What's the point of having two
    > copies of the same function at two different locations?
    >
    >> Can you please comment your opinion? Do you think it is too much

    >
    > In my opinion, what you are doing is beyond standard C++. You're
    > overcoming the limitations of a particular platform using various
    > hacks. They are not defined to work according to standard C++. So it's
    > best to discuss that with other users of the same platform, or an
    > appropriate development support forum or channel.
    >
    >> functions like overhead CPU? Try to compare to switch(...) because it
    >> can
    >> only limit 32K or less. I believe that function pointer is the best
    >> solution for great cache because most functions are smaller.

    >
    > Whether using a table of function pointers, or using switch() is faster
    > is implementation-dependent. But if one technique produces code that is
    > too large, but another one fits, you can hardly compare them for
    > performance. The performance of a program that you can't compile or
    > load is nonexistent. :)
    >

    Hello,

    Yes, it is what I mean. One function pointer has 256K bytes which
    function has 4 bytes of memory address. It is 65,536 functions times 4
    bytes equals 256KB. You can create 10 functions to 10,000 functions. Copy
    member address of function into function pointer array. It is like "Run[0
    to 65,535]()" function. You use for...loop to execute function pointer
    65,536 times.

    It is an example:

    for (UINT Array = 0; Array < 65536; ++Array)
    Run[Array]();

    It will run fine. Why do document claim that it has to limit 1,000
    functions. Someone wrote 80x86 assembly code and they attempted to
    construct JMP Table up to 65,536, but it crashed. Function pointer table up
    to 65,536 works fine under C/C++ code.
    Do you believe that it is good program to handle 65,536 functions
    through function pointer on 80x86 and other non-x86 machines?
    Why do Microsoft C/C++ Compiler limits 64K source code lines? Do you
    know if other C/C++ Compiler such as GNU have unlimited source code lines?
    I am curious.

    Bryan Parkoff
     
    Bryan Parkoff, Dec 17, 2005
    #5
  6. Bryan Parkoff

    Ian Guest

    Bryan Parkoff wrote:
    > Why do Microsoft C/C++ Compiler limits 64K source code lines? Do you
    > know if other C/C++ Compiler such as GNU have unlimited source code lines?
    > I am curious.
    >

    Why on earth would you want a file with 64K lines?

    Ian
     
    Ian, Dec 17, 2005
    #6
  7. Bryan Parkoff

    Phlip Guest

    Ian wrote:

    > Bryan Parkoff wrote:


    >> Why do Microsoft C/C++ Compiler limits 64K source code lines? Do you
    >> know if other C/C++ Compiler such as GNU have unlimited source code
    >> lines? I am curious.
    >>

    > Why on earth would you want a file with 64K lines?


    MS's MIDL generates them all the time, so I doubt that limit.

    Maybe the restriction is on 64K functions. Darn.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Dec 17, 2005
    #7
  8. Bryan Parkoff

    Ian Guest

    Phlip wrote:
    > Ian wrote:
    >
    >
    >>Bryan Parkoff wrote:

    >
    >
    >>> Why do Microsoft C/C++ Compiler limits 64K source code lines? Do you
    >>>know if other C/C++ Compiler such as GNU have unlimited source code
    >>>lines? I am curious.
    >>>

    >>
    >>Why on earth would you want a file with 64K lines?

    >
    >
    > MS's MIDL generates them all the time, so I doubt that limit.
    >

    Sounds like a good reason to avoid it...

    Ian
     
    Ian, Dec 17, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. peelman

    How many threads is too many?

    peelman, Jan 13, 2005, in forum: Java
    Replies:
    12
    Views:
    857
    Esmond Pitt
    Jan 15, 2005
  2. Rhino
    Replies:
    33
    Views:
    1,334
    Oliver Wong
    Dec 22, 2005
  3. rbt
    Replies:
    1
    Views:
    364
  4. How many roles is too many?

    , Jun 13, 2006, in forum: ASP .Net Security
    Replies:
    4
    Views:
    200
    Joe Kaplan \(MVP - ADSI\)
    Jun 18, 2006
  5. Dag Sunde
    Replies:
    4
    Views:
    372
Loading...

Share This Page