User forums > General (but related to Code::Blocks)
Numpty Linux Question
BigAngryDog:
Really numpty question. I'm emarrassed about my ignorance, but here goes...
If I were to build an executable binary under Linux, then in principle, could I upload the binary to any Apachie server for use and execution within a website? I.e. could I use the binary to generate HTML content? Or do I need to start worrying about which distribution of Linux my binary is built for?
Thanks :)
TDragon:
--- Quote from: BigAngryDog on June 06, 2006, 10:56:31 pm ---Or do I need to start worrying about which distribution of Linux my binary is built for?
--- End quote ---
Yes. In the end, it's still an executable and it's still run by the OS.
thomas:
No, and yes.
In principle, you can do that, but it is not quite that easy. Google for "cgi" or "common gateway interface", or read this primer to get an idea how this works.
Also, you must make sure that you enable cgi in your web server (which may be a security issue, you may want to think twice about that).
Cgi is not necessarily enabled by default on a web server (or available at all), and if it is enabled, it usually only works in one specific subdirectory (so it also matters where you upload your program to).
Lastly, it does matter what kind of Linux you use insofar as you may use an incompatible version of glibc or any other library that you link to. So yes, you have to take care of that.
EDIT:
For completeness: Besides CGI, there is also FastCGI (which is supposedly faster ;)) and the possibility to incorporate executable code into a web server via some plugin mechanism (most major servers support that). Both FastCGI and plugins have the advantage that they do not need to reload the executable for every request.
I cannot tell you much more about FastCGI since I have never used it, but I guess it does not matter a lot unless you plan to run your program 100 times per second. Writing a module/plugin is evidently a lot more complicated than a simple CGI, so that is probably not what you want, either.
Unless whatever you want to do is about some insane number crunching or similar things, you might consider a script language, too. For example PHP is available nearly everywhere (even the cheap web hosters offer it), and it is a mighty fine thing. You have a syntax very close to C/C++ (learning time is almost zero), there is a function for almost everything (including database handling, networking, graphics and all kinds of weird stuff), the documentation is excellent, and execution speed is not a lot worse than a real executable. Using PHP, you can reduce the amount of time to write a "typical" web application to maybe 10% of what you would take doing it in C/C++.
Balazs:
I personally prefer Perl with CGI.pm and the plethora of related modules from CPAN :)
thomas:
As always, it depends on what you want, what you have available, and what you're used to. :)
If you are adept to Perl, then it is surely a mighty fine language, in particular when it comes to whacking character strings with regular expressions and similar things. There is probably no other language that lets you do more fancy string manipulations in a single line of code.
However, Perl's syntax is outright repelling if you are not used to it, and it can be a pain to learn (and understand). That may be the main reason why Perl projects have the reputation of becoming unmanageable at some point ;)
Neither Perl nor PHP have the cutting edge speed of a "real" executable, but they can make your life a lot easier if you use the right tool for the right job (and if you can handle the tool).
PHP has (almost) all the good features of Perl, but keeps the advantage of being 100% noob-safe and 80-90% downwards-compatible to C/C++. This can really be a huge advantage (you don't need to learn much more than to put a $ in front of variables, and to concatenate strings with . rather than +. Well, maybe you should know what an associative array is too, but that's about it ;)).
That way, you can almost copy and paste your existing C code, insert a few dollar signs, and that's it. With the only difference that you can now implement session handling and authentication via a SQL database in like 5 lines of code, and a basic shopping cart in like 10 more lines of code, and it will just work like magic. And if you need <insert arbitrary function> then chances are good that you don't need to worry about implementing it, as most everything you'll ever need is in the standard library. :)
Navigation
[0] Message Index
[#] Next page
Go to full version