Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Array of pointer-to-functions

Reply
Thread Tools

Array of pointer-to-functions

 
 
Ian Collins
Guest
Posts: n/a
 
      09-17-2012
On 09/18/12 11:27 AM, Scott Lurndal wrote:
> Ian Collins<(E-Mail Removed)> writes:
>> On 09/18/12 01:57 AM, Scott Lurndal wrote:
>>> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
>>>> On Sunday, September 16, 2012 10:57:08 PM UTC-5, I wrote:
>>>>> Great, thanks for the tip! Just getting into classes, hopefully polymorphisms will come up in the text.
>>>>
>>>> More generally, don't declare all variables at the top of a function. Declare them right where they are used. This is not just about correctness (like in this case), but also about readability and style.
>>>
>>>
>>> Which is a matter of opinion. I prefer all variables to be declared at the beginning of a basic-block. Makes it
>>> easier to find when functions get larger than a handful of lines. Also prevents compile errors in the presence
>>> of goto's (which can be used safely and properly, primarily as early exits w/cleanup).

>>
>> I smell Troll bait
>>
>> We all know functions shouldn't be longer than a handful of lines and no
>> C++ programmer would ever risk his or her head by using goto.

>
> Well, after a microkernel, two hypervisors, two computer simulators and three operating systems
> all written in C++, I've seen some pretty long functions (the fork implementation,
> for example), and judicious use of goto is often warranted (and used - usually
> for function exits where resources must be returned on failure, e.g. locks unlocked,
> memory returned, et alia)[*].
>
> Given the similar characteristics of multithreaded applications, similar considerations
> apply.
>
>
>[*] While none of these projects used exceptions in any way, RAII techniques were
> used in a couple of the more complicated paths in 1991, specifically the fork implementation
> had a local class instance named tForkFailure whose destructor would clean up a
> partial fork when the fork function exited, but in most cases, a simple goto was
> sufficient to release a lock at function return (the complex nature of locking in
> a general purpose unix-compatible operating system precluded using RAII techniques
> to unlock the lock; occasionally the lock need be left locked on function exit).


Well that was 20 years ago and techniques and tools have moved on since
then. If you want a lock to stay locked, tell the object that manages
it not to release it when it gets destroyed.

The use of goto for clean up code is common enough in C, but I would be
very surprised to see it in current C++ and even more surprised to see a
valid justification for its use.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Pavel
Guest
Posts: n/a
 
      09-18-2012
Ian Collins wrote:
> On 09/18/12 11:27 AM, Scott Lurndal wrote:
>> Ian Collins<(E-Mail Removed)> writes:
>>> On 09/18/12 01:57 AM, Scott Lurndal wrote:
>>>> (E-Mail Removed) writes:
>>>>> On Sunday, September 16, 2012 10:57:08 PM UTC-5, I wrote:
>>>>>> Great, thanks for the tip! Just getting into classes, hopefully
>>>>>> polymorphisms will come up in the text.
>>>>>
>>>>> More generally, don't declare all variables at the top of a function.
>>>>> Declare them right where they are used. This is not just about correctness
>>>>> (like in this case), but also about readability and style.
>>>>
>>>>
>>>> Which is a matter of opinion. I prefer all variables to be declared at the
>>>> beginning of a basic-block. Makes it
>>>> easier to find when functions get larger than a handful of lines. Also
>>>> prevents compile errors in the presence
>>>> of goto's (which can be used safely and properly, primarily as early exits
>>>> w/cleanup).
>>>
>>> I smell Troll bait
>>>
>>> We all know functions shouldn't be longer than a handful of lines and no
>>> C++ programmer would ever risk his or her head by using goto.

>>
>> Well, after a microkernel, two hypervisors, two computer simulators and three
>> operating systems
>> all written in C++, I've seen some pretty long functions (the fork
>> implementation,
>> for example), and judicious use of goto is often warranted (and used - usually
>> for function exits where resources must be returned on failure, e.g. locks
>> unlocked,
>> memory returned, et alia)[*].
>>
>> Given the similar characteristics of multithreaded applications, similar
>> considerations
>> apply.
>>
>>
>>[*] While none of these projects used exceptions in any way, RAII techniques were
>> used in a couple of the more complicated paths in 1991, specifically the
>> fork implementation
>> had a local class instance named tForkFailure whose destructor would
>> clean up a
>> partial fork when the fork function exited, but in most cases, a simple
>> goto was
>> sufficient to release a lock at function return (the complex nature of
>> locking in
>> a general purpose unix-compatible operating system precluded using RAII
>> techniques
>> to unlock the lock; occasionally the lock need be left locked on function
>> exit).

>
> Well that was 20 years ago and techniques and tools have moved on since then.
> If you want a lock to stay locked, tell the object that manages it not to
> release it when it gets destroyed.
>
> The use of goto for clean up code is common enough in C, but I would be very
> surprised to see it in current C++ and even more surprised to see a valid
> justification for its use.
>

OSes and device drivers are still commonly written in C and other non-C++
languages. This was true 20 years ago and stays true now. Symbian (former
EPOC32) is the only one relatively successful one I am aware of that was written
in C++ -- but RAII part of its C++ was intentionally broken to allow manual
control of what's cleaned up and what's not and minimize overhead of the
exceptions (they did use exceptions.. of a kind, also not standard C++ -- but I
already wrote about these).

To summarize, now as 20 years ago, RAII (and C++) have yet to prove to be
competitive in device driver and kernel development.

(I am not saying this cannot be done; on the surface of things passing lock
ownership among scopes with the likes of unique_ptr seems at least doable; but I
am unaware of a convincing broadly known case-in-point; if you know any, I would
be eager to learn about it).

-Pavel

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      09-18-2012
On 09/18/12 02:21 PM, Pavel wrote:
> Ian Collins wrote:
>>
>> The use of goto for clean up code is common enough in C, but I would be very
>> surprised to see it in current C++ and even more surprised to see a valid
>> justification for its use.
>>

> OSes and device drivers are still commonly written in C and other non-C++
> languages. This was true 20 years ago and stays true now. Symbian (former
> EPOC32) is the only one relatively successful one I am aware of that was written
> in C++ -- but RAII part of its C++ was intentionally broken to allow manual
> control of what's cleaned up and what's not and minimize overhead of the
> exceptions (they did use exceptions.. of a kind, also not standard C++ -- but I
> already wrote about these).
>
> To summarize, now as 20 years ago, RAII (and C++) have yet to prove to be
> competitive in device driver and kernel development.
>
> (I am not saying this cannot be done; on the surface of things passing lock
> ownership among scopes with the likes of unique_ptr seems at least doable; but I
> am unaware of a convincing broadly known case-in-point; if you know any, I would
> be eager to learn about it).


The only examples I have are my own and embedded drivers I have worked on.

The two things holding C++ back in this area are prejudice from the C
programmers who maintain kernels and drivers and the lack of a common
C++ ABI.

--
Ian Collins
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-18-2012
Scott Lurndal <(E-Mail Removed)> wrote:
> Well, after a microkernel, two hypervisors, two computer simulators and
> three operating systems all written in C++, I've seen some pretty long
> functions (the fork implementation, for example), and judicious use of
> goto is often warranted (and used - usually for function exits where
> resources must be returned on failure, e.g. locks unlocked, memory
> returned, et alia)[*].


Having programmed for about 10 years in C++ professionally (and longer
than that as a hobby), I don't remember having needed to use goto even
once.

And it's not like I religiously avoid it, and artificially try to shove
in contrived constructs that allow me to avoid writing "goto". The situations
just don't come up. I don't even remember having thought something like
"hmm, 'goto' would be the easiest solution here, how could I avoid it?"
There might have been one or two cases during my entire career that
something along those lines might have happened, but it has been really,
really rare.

Cleaning up resources with a 'goto' construct is particularly hideous
(and error-prone) in C++ both because it's not exception-safe, and
because there's a much, much better tool for exactly that: RAII.

Also, rarely does it happen that a function *must* be very large.
Usually you can split it into several functions, and more often than
not the resulting code will be easier to understand because of that.
(One exception that comes to mind is if you need a really large
switch block for some reason.)
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-18-2012
Scott Lurndal <(E-Mail Removed)> wrote:
> Also prevents compile errors in the presence of goto's


You must be joking.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-18-2012
Pavel <(E-Mail Removed)> wrote:
> Symbian (former EPOC32) is the only one relatively successful one I am
> aware of that was written in C++ -- but RAII part of its C++ was
> intentionally broken to allow manual control of what's cleaned up and
> what's not and minimize overhead of the exceptions


That doesn't make much sense. It's not like RAII is non-deterministic
garbage collection where you have no control over when it's run. With
RAII you know *exactly* when the destructors will be called and in which
order (because the standard mandates so).

If you remove RAII from C++, you might just as well go back to C.
 
Reply With Quote
 
Luca Risolia
Guest
Posts: n/a
 
      09-18-2012
On 18/09/2012 04:21, Pavel wrote:
> To summarize, now as 20 years ago, RAII (and C++) have yet to prove to
> be competitive in device driver and kernel development.


The Linux kernel is full of implementations of object-oriented design
patterns, for which C++ would be the only natural language.

 
Reply With Quote
 
Werner
Guest
Posts: n/a
 
      09-18-2012
On Monday, September 17, 2012 6:10:34 PM UTC+2, I wrote:
> > Why the switch statement?

>
> >

>
> >

>
> >

>
> > Kind regards,

>
> >

>
> >

>
> >

>
> > Werner

>
>
>
> I took a problem from C++ Primer Plus and tried to up the degree of difficulty, The original goal was to use a pointer to function to some function like add(). I wanted to see if I could set up a situation that would allow a user to select multiple functions of their choosing. Switch is the best way I currently know.
>
>
>
> Ian


You already have an index into the array (or vector).

There is no need for a switch. The switch is redundant.

See below:

for(int i=0;i<size_choice;i++)
{
cin>>choice;

// Choice is already an index into the
// array of function pointers... Get it?
(*array_of_pointers[choice])(...);
}






 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-18-2012
David Brown <(E-Mail Removed)> wrote:
> Please do not quote hundreds of lines just to add a single line comment!
> It is especially bad when you use Google's broken web interface to
> post - every quotation gets an extra blank line per "paragraph". And
> since every line of C code is a paragraph in this context, each re-quote
> doubles the number of blank lines messing up the post.


Do you wonder anymore why people top-post?
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-18-2012
Scott Lurndal <(E-Mail Removed)> wrote:
>>If you remove RAII from C++, you might just as well go back to C.

>
> That's ridiculous. The class paradigm (data encapsulation) is enough
> of a benefit, without RAII, without templates, without exceptions, to
> make using C++ (or a subset thereof) useful for kernel development.


That would be such a crippled version of C++ that it would hardly be
worth using.

No generic data containers, no smart pointers, no automatic memory
management of any kind, inefficient pseudo-generic data containers and
algorithms (such as the horrid qsort()). In fact, for such objects to be
even slightly usable you would in practice have to limit the objects to be
dynamically allocated only, with no possibility of creating stack-based
objects, no copying objects, no handling them by value (because all those
require RAII to work properly).

(Yes, you could allow copying objects and handling them by value,
effectively making them C structs with support for member functions.
But without constructors, destructors and assignment operators, and
especially without being able to forbid them, it would be really
error-prone. Instantiate eg. a string "pseudo-object", inadvertently
assign it to another such object, and you have a problem.)

This would in fact be similar to Objective-C (which likewise has no RAII,
no constructors, no destructors, no assignment, cannot handle objects by
value, no templates), except that in Objective-C you at least have a
useful messaging system (which allows all kinds of neat stuff that isn't
possible even in full-fledged C++).

I don't see all that much difference between that crippled C++ and just C
(using structs and free-floating functions).
 
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
const and array of array (of array ...) Mara Guida C Programming 3 09-03-2009 07:54 AM
length of an array in a struct in an array of structs in a struct in an array of structs Tuan Bui Perl Misc 14 07-29-2005 02:39 PM
Length of Array of Array of Array Tom Perl Misc 3 12-20-2004 05:23 PM
How to combine 2 int Array into ONE int Array ? S300 Java 4 08-19-2003 07:04 PM
hashed array in array need the keys... and length Daniel Perl 1 08-14-2003 06:49 PM



Advertisments