C++ or pure C for Linux kernel module, Linux device driver development. What to use?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I meant I use Perl to generate C/C++ code, i.e. I use it as a better than CPP/C++ templates engine.
And, FWIW, Perl is compiled into bytecode (as Java, Python, Ruby, but _not_ as sh, tcl), so it's not an interpreted language.
I did miss your point. I agree. Using Perl gives one close control over the code that is generated. Standard libraries of Perl "templates" would be a powerful tool.
These byte codes (and abstract machine code instruction sets) used to be called "Interpreted Languages." (E.g. the SC of the UCSD Pascal p-System.)
Wikipedia says "In computer programming an interpreted language is a programming language whose implementation often takes the form of an interpreter." Virtual machine code is still interpreted. Wikipedia puts Perl into the class of virtual machine interpreted languages.
Basic and FORTRAN were among the first to be compiled into them. Pascal had a widely used specified language (P-System stack code). If the compiler generates an abstract rather than machine specific code, it is still called an interpreted language implementation. Byte codes still require an interpreter and dynamic languages do incur an overhead. Java and Python are occasionally compiled directly into machine specific language for efficiency. They are still called interpreted languages because that was the target design.
I did miss your point. I agree. Using Perl gives one close control over the code that is generated. Standard libraries of Perl "templates" would be a powerful tool.
These byte codes (and abstract machine code instruction sets) used to be called "Interpreted Languages." (E.g. the SC of the UCSD Pascal p-System.)
Wikipedia says "In computer programming an interpreted language is a programming language whose implementation often takes the form of an interpreter." Virtual machine code is still interpreted. Wikipedia puts Perl into the class of virtual machine interpreted languages.
Basic and FORTRAN were among the first to be compiled into them. Pascal had a widely used specified language (P-System stack code). If the compiler generates an abstract rather than machine specific code, it is still called an interpreted language implementation. Byte codes still require an interpreter and dynamic languages do incur an overhead. Java and Python are occasionally compiled directly into machine specific language for efficiency. They are still called interpreted languages because that was the target design.
Well, my point WRT compiled/interpreted is that Perl and the like first compile the whole code (I'm not talking about runtime bindings here), so stupid mistakes are immediately caught.
For TCL, for example, which is truly interpreted, one needs a static checker to catch the same type of mistakes, and it's a reason I'm trying to avoid the language whenever possible.
FWIW, first Verilog implementations used P-code (I'm from VLSI world).
Well, this latest post of mine is OT, just wanted to make things clear.
...
If you are interested, I can demo my own Perl template engine here, it's very easy to use and open source. It can be really easily combined with any target language (C/C++, Verilog, Perl itself - you name it).
Well, my point WRT compiled/interpreted is that Perl and the like first compile the whole code (I'm not talking about runtime bindings here), so stupid mistakes are immediately caught.
For TCL, for example, which is truly interpreted, one needs a static checker to catch the same type of mistakes, and it's a reason I'm trying to avoid the language whenever possible.
FWIW, first Verilog implementations used P-code (I'm from VLSI world).
Well, this latest post of mine is OT, just wanted to make things clear.
...
If you are interested, I can demo my own Perl template engine here, it's very easy to use and open source. It can be really easily combined with any target language (C/C++, Verilog, Perl itself - you name it).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
