Combine Perl with C++ or C

maverick_anew has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Combine Perl with C++ or C by ww (Archbishop) on Apr 17, 2011 at 22:50 UTC
As is almost always the case with such questions, the answer depends on your problem set and the tools you have available. It also depends heavily on your definition of "useful." Sometimes the Q&D script (emphasis on the "Quick" part of that phrase) that solves a problem is more "useful" and even more elegant than the C (in all references, consider this inclusive: C and C++) code which required so many more programmer hours to develop that the deadline passed. Nonetheless, applications that require heavy computation are likely to benefit from use of C (if they're not one-offs; IOW, if one expects them to be used repeatedly and often). But given the wealth of Perl's underpinnings and the multitude of proven modules, one should not leap to utilize C. Like the hammer or screwdriver, a programming language has limits on its applicability: using a screwdriver to pound in a nail is sometimes possible, but unwise. So too is using a (claw-) hammer to remove a screw.	[reply]
Re^2: Combine Perl with C++ or C by Ratazong (Monsignor) on Apr 18, 2011 at 05:54 UTC
From my experience, one of the most important reasons to use "language X" from "language Y" is to reuse code. Often you already have some well-tested, stable code - and it is much easier to create a wrapper for that code than to re-invent it. If you are considering using different programming-languages (e.g. Perl and C) in a new project, do a good analysis if the advantages really outweight the (potential) troubles ... according to my experiences (as well as to the statements from ww and lanX in this thread) this is very doubtful. HTH, Rata	[reply]
Re: Combine Perl with C++ or C by ikegami (Patriarch) on Apr 18, 2011 at 06:13 UTC
To use an existing library is a major reason. For example, XML::LibXML, Wx and DBD::Pg. I suspect the desire to make the code as fast as possible is the other. For example, MIME::Base64 and Text::CSV_XS probably fall into this category.	[reply]
Re: Combine Perl with C++ or C by cdarke (Prior) on Apr 18, 2011 at 10:20 UTC
When you need to call an API that has no Perl equivalent, or when you are calling several APIs in succession. In my case, in particular the Win32 APIs. If you are getting data from one API and passing it to another, then to another, and so on, it does not make sense to keep converting between Perl and C for each API call. Just write the whole lot in C, call it once and return the final result.	[reply]
Re: Combine Perl with C++ or C by LanX (Saint) on Apr 18, 2011 at 00:07 UTC
> When do you believe it would be wise to implement C or C++ code into your Perl Code. Or perhaps the question should be, what programming problems would be assisted in using such a technique? Pros are time criticality drivers for special hardware perl language extensions (updated) code reuse ... (to be extended) Cons mostly outweigh the pros. Cheers Rolf	[reply]
Re: Combine Perl with C++ or C by anonymized user 468275 (Curate) on Apr 18, 2011 at 12:45 UTC
Usually one chooses to interface to C rather than C++ because two different object virtualities can cause unexpected results. C is a descendant of BCPL, which was almost an assembler in its design. The { } in C (and Perl) is a simplification of `$( $)`in BCPL. But BCPL also had `$[ and $]`to denote a section of machine assembler being inserted directly in the code for co-assembly/compilation into object code. There is an opportunity to link object code created by compiled languages into the Perl interpreter, though this tends to be avoided for practical reasons such as ease of distribution. Generally speaking the descent into C (or even assembler/MACRO-32 in the case of DOS and VMS), tends to be justifiable only by the need to use low level features such as: - direct access to virtual memory instead of Perl's symbolic memory - this is not usually motivated by performance, in spite of that being a popular knee-jerk argument - but more likely being driven by needing to use a direct virtual memory interface to an external service or a device - in regard to performance, Perl's symbolic memory is a good enough interface to virtual memory anyway. - interfacing to object modules, device drivers or shared libraries that are created from a compiled language or sometimes assembler as described above. So it's more a question of using programming opportunities than solving programming problems. One world, one people	[reply] [d/l] [select]