Too Many Function Pointers?

[Bryan Parkoff]

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

[red floyd]

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 incomprehensibl e. Please see FAQ 5.8:
http://www.parashift.com/c++-faq-lit...t.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++.

[Victor Bazarov]

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

[Kaz Kylheku]

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. :)

[Bryan Parkoff]

"Kaz Kylheku" <kk******@gmail .com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

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

[Ian]

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

[Phlip]

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!!!

[Ian]

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