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
In reply to Re: Combine Perl with C++ or C
by anonymized user 468275
in thread Combine Perl with C++ or C
by maverick_anew
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |