Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Too Many Function Pointers?

Reply
Thread Tools

Too Many Function Pointers?

 
 
Bryan Parkoff
Guest
Posts: n/a
 
      12-16-2005
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


 
Reply With Quote
 
 
 
 
red floyd
Guest
Posts: n/a
 
      12-16-2005
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-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++.

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      12-16-2005
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
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      12-16-2005
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.

 
Reply With Quote
 
Bryan Parkoff
Guest
Posts: n/a
 
      12-17-2005

"Kaz Kylheku" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.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


 
Reply With Quote
 
Ian
Guest
Posts: n/a
 
      12-17-2005
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
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      12-17-2005
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!!!


 
Reply With Quote
 
Ian
Guest
Posts: n/a
 
      12-17-2005
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how many hard drives is too many? mattcar Computer Support 6 06-29-2007 01:58 AM
How many warnings is too many? Rhino Java 33 12-22-2005 09:39 PM
How many threads are too many? rbt Python 1 06-11-2005 11:03 PM
How many threads is too many? peelman Java 12 01-15-2005 07:37 AM
Too many (small) vs. too large linked script files in a document... Dag Sunde Javascript 4 12-16-2004 11:38 PM



Advertisments