Carrot, an Open Source C++ scripting module for Apache 50
Fons Rademakers writes: "ROOT-Apache (aka Carrot) is an open source scripting module for the Apache webserver. Based on the ROOT framework which is using C++ as scripting language, via the CINT interpreter, it has a number of powerful features, including the ability to embed C++ code into HTML pages, run interpreted and compiled C++ macros, dynamically extend the framework with external libraries, access and manipulate databases, and generate graphics on-the-fly, among many others."
Yes... (Score:3, Funny)
Yea, Um, couldnt you feel the sarcasm dripping ?? (Score:1)
This is quite sweet! (Score:1)
Re:This is quite sweet! (Score:1)
Shudder. I want one.
Great idea (Score:5, Funny)
Re:Great idea (Score:1)
Re:Great idea (Score:2)
C/C++ are only hard to program in if you do everything from scratch. You wouldn't use any of the above languages without anyone else's toolkits and libraries. Why would you do differently with C/C++?
There are string, memory, file, html, etc libraries which make C/C++ every bit as easy (some would say easier) to work with as any language you care to name. And there are more libraries available for free use than there are for all of the languages you can name combined.
On top of that, you get a huge suite of debugging tools and superior performance. Do a little research. A C/C++ environment is about the most flexible thing out there. You can turn it into anything you like.
Re:Great idea (Score:2, Interesting)
Anyway my point was that *scripting* languages which resemble C/C++ are crap. There is no huge suite of debugging tools and superior performance for them and there is no string, memory, file, html, etc libraries which make C/C++ every bit as easy for them. I've been there. I've been forced to write in one such language. It is very annoying when you have to deal with memory managment in *scripting* language.
Re:Great idea (Score:2)
Re:Great idea (Score:2, Funny)
> coredumps, buffer overflows and format string errors
Yup, open source web software finally catches up with Microsoft. Should go nicely with the FreeBSD
Not in C++ (Score:3, Funny)
I agree though... All of the power of a scripting language with the ease of use and simplicity of C++. Makes me pine for the days where assembly was the dominant language.
Re:Not in C++ (Score:3, Funny)
Re:Not in C++ (Score:2)
While there is definite overlap, Java has a different problem space from most scripting languages (and from C or C++). Use the right tool for the job.
Java (Score:1)
Re:Java (Score:2)
That being said, as compared to C or C++, Java is a faster language in which to code -- standard library that includes networking, i/o, threading, enterprise components, directory services, database access, etc.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
That being said, for numerics, low-memory usage GUIs, kernels, and those applications that need the absolute last squeeze of performance (0.01% of all programs), use some language other than Java. Hell, use whatever works best for you. But a properly written program (badly written programs and inefficient algorithms can occur in any language) are speed-wise quite similar to one another despite the choice of language. There is a far greater variance in programmer ability than the inherent speed traits of a particular language.
For the record, I don't own any Sun hardware, don't have $2 million to spare, and my servlets and EJBs run just fine thank you.
My only point of skepticism with a scriptable C and C++ is that the languages weren't designed to be scriptable -- they were designed with compile-time inefficiency so that runtime efficiency could be maximized. This is in direct contrast to scripting languages that are meant to be loaded and run in a single pass with no linking steps, best guess, general optimizations, and ease of coding. If it works for Carrot, good for them. If it helps primarily C and C++ coders get their jobs done, good for them. Will it give the same type of benefits that languages such as Python can give, probably not.
Use the right tool for the job and use that tool correctly. Everything else (including language-bashing) is waste of energy.
Re:Java (Score:1)
Besides, like I said, Java is all about proprietary maneuvers and bad vibes. Why bother with all that, when people are cooperating on better stuff?
No no no... (Score:3, Informative)
Now with regard to Java, its standard library is much cleaner than that of Perl (for example). Perl objects were an afterthought and it shows. Its socket APIs are not intuitive. Couple this with the fact that you can't enforce by interface that a particular variable is an int vs. a string vs. anything else without extra runtime checks like regular expressions. This can add unecessarily to the runtime of a program. Large-scale Perl is a nightmare compared to language that doesn't just pay lip service to a component-based architecture. So right off the bat, this is what I get from servlets that I can't do with mod_perl.
Comparing VMs, Java's is noticeably faster than both Perl's and Python's for computationally intensive programs and is not quite so bad against C or C++ as you assert. Combine this with the fact that Java can be compiled natively with a variety of tools today (although modern JVMs do a more than adequate job). Speed approaches that of C and C++ code without core dumps, buffer-overflow exploits, etc. Add to this excellent i18n and l10n support, standard networking, threading, database, directory services, distributed programming, ABI, etc., I consider it a good trade.
A lot of development is going into Jython. Why? Because a lot of Python developers recognize the value of the Java platform.
Now let's examine the proprietary manuevers. Sun has not released Java to a standards body. ECMAScript *has* been released to a standards body and yet the programming models are not uniform on all platforms. Perl is the shining star apparently...but how many have tried to access CPAN modules directly from Perl on Windows? As it turns out, quite a few modules are programmed with C and a UNIX model in mind (or just Linux/BSD). Don't believe me, check out the graphics modules (dynamic creation of web images for example), RPC, mail handling, etc. So much for write once run anywhere with a "standard" language.
Are there issues like a logger that was put in even though there was an arguably better one out there?
Now let's examine the J2EE issue. If Sun tested JBoss for free, what does that say to IBM, BEA et all who paid a lot of money to get tested? You'll lose partners that way. But also notice that Sun has not tried to bully JBoss out of the market. When you look closely at the Lutris (Enhydra) J2EE stink, you'll note that they were worried because they used Sun J2EE libraries to produce a product. Couple this with the fact that Sun never issued a cease and desist; Lutris pulled back on their own.
As long as JBoss (and libre software in general) stays competitive, it is in Sun's best interest to leave it alone. Can you imagine what would happen if Sun suddenly decided to deny access to the Sun platform to anyone but licensed vendors? It would destroy the Solaris server market. The same holds true for Java. After all, it's just another platform, and there is far too much code out there to simply cut them off.
This is like saying that maybe tomorrow Microsoft may announce that all compilers except for Visual Studio are not allowed to be used on Windows OSes. Aside from the anti-trust issues, there is simply too much code out there that has been written with a Borland, GNU, Intel, Metrowerks, etc. compiler.
Someone's already pissed in the pool. You can't get it out now without draining all the water out first. Developers are in far more danger from DCMA, SSSCA, and other similar items than Java suddenly becoming unavailable.
Re:Java (Score:1)
I programmed about 10 years in C++ and gave it up.
Still to today there is no standard portable thread library in C++. Still to today there is no standard portable GUI library in C++. Still to today there is no standard web services, XML, directory services or ANY other standard library available in C++.
C++ is the best language I ever worked with(look at Spirit parser library, or at Open C++), but no vendor gives you a wide set of standard libraries. The only standard is the standard C++ library (where STL is a part off) and the standard C lib.
STL exists since 6 years now. And? It still is not supported on all platforms.
I now programe since 4 years JAVA.
EVERYTHING IN JAVA IS A STANDARD. And works on all machines the same.
Before you have not worked in a > 100 members development team on a > 300 man years project, just shut up to trash a language.
Most arguements against Java are either wrong(other languages are easyer, lol) or outdated(its to slow, Sun makes fraud, LOL even louder).
BTW: ROOT and CINT are nice projects and they work pretty well. I played with both.
If C++ would compile to JAVA bytecode I would stick to C++. But JBC has so many advantages
E.g. you can link with other languages compiling to JBC(C, PERL, Python, RUBY, Prolog, LISP, SCHEME, ML
C++ has no reflection, Perl has no reflection either
Well, as you hate Java you will never know. Keep sitting in your little hole, but don't cry when the time for old outdated languages is over. (Like it is for COBOL, Simula, Smaltalk
Regarding your rant against servlets: Easyer than a servlet? Even more easyer than a servlet? I don't know about mod_snake but about mod_perl I know pretty well.
They ara FAR away from a servlet. FAR.
What do you think why there are PERL servlet APIs implemented right now? Because of the ideas behind the servlet environment and the frameworks. Look for "libservlet" on freshmeat.
Regards,
angel'o'sphere
Re:Java (Score:1)
There is no portable concept of threads in various operating systems, either.
> Still to today there is no standard portable GUI library in C++.
There are a number of GUI libraries; why the obsession with a "standard" library? GUIs written in Java tend to be ugly and monstrously bloated programs. As of a year ago, Swing still had pretty serious memory leaks, and AWT still looked like donkey turds. Do you remember the original marketing spin from Sun about Java? All GUI programs were going to be written in Java, so they would run everywhere! Sun would write a Java web browser, that would be super-fantastic, and run everywhere! Microsoft would crumble as all user apps were written to Java APIs! Only of course HotJava sucked, as did pretty much all GUI Java programs, and now Sun wants to talk to you about server-side Java. Strange, given all that talk about portability. They basically retreated from GUI land, and are pushing slow server software.
> Still to today there is no standard web services
meaningless market-speak
> XML
overhyped (and brain-damaged) serialization syntax
> directory services
a weak version of a database
> or ANY other standard library available in C++.
That's odd, on my planet there is an incredible wealth of libraries in C and C++ implementing all kinds of wonderful things. For a start, you could look into the GNU project (including GNOME) or KDE.
> C++ is the best language I ever worked with(look at Spirit parser library, or at Open C++), but no vendor gives you a wide set of standard libraries. The only standard is the standard C++ library (where STL is a part off) and the standard C lib.
> STL exists since 6 years now. And? It still is not supported on all platforms.
C++ is horrifically complicated, so every compiler implements it a bit differently. STL pushes those horrifically complicated features pretty hard,
> I now programe since 4 years JAVA.
I guess you really like all those really long type names you have to use to cast objects that come out of containers. You must also really like FOR loops, and be bothered by complicated concepts like map, filter, etc..
> EVERYTHING IN JAVA IS A STANDARD. And works on all machines the same.
Meaning you have what Sun gives you. You are under the control of a vendor whose interests don't particularly line up with yours. Sounds a lot like other proprietary software situations, doesn't it?
> Before you have not worked in a > 100 members development team on a > 300 man years project, just shut up to trash a language.
There are lots of projects to be done (I would venture, even, most of them) that don't require 100 active developers. As for man-years, I would imagine that using Java increases the time required by quite a bit.
> Most arguements against Java are either wrong(other languages are easyer, lol)
For many tasks, other language are much easier to use. Want to do massive string manipulation-type stuff? Way easier to write in Perl. Want to use higher-order functions? Functional languages (e.g. ML, haskell) are a much better fit. Want to implement your program quickly? Java programs tend to be very lengthy, compared to implementations in less verbose languages.
> or outdated(its to slow, Sun makes fraud, LOL even louder).
Sun has been promising for many years that the next version of Java would be the one that solved all the performance problems. I haven't seen it happen yet. The RAM requirements are particularly egregious. The performance of JIT programs is incredibly erratic, to the point where it is difficult to measure the troughput, because the response time varies to wildly from request to request.
> BTW: ROOT and CINT are nice projects and they work pretty well. I played with both.
That's nice. It's always good to have more free software!
> If C++ would compile to JAVA bytecode I would stick to C++.
This is a really strange statement. C++ is incredibly complicated, largely because of the keep-it-close-to-the-metal spirit interacting poorly with all the features Bjarne crammed in. A C++ compiler targeting Java bytecode would get you a horrendously complicated language, and a slow program. The worst of both worlds!
> But JBC has so many advantages
Aside from burning all your RAM and CPU.
> E.g. you can link with other languages compiling to JBC(C, PERL, Python, RUBY, Prolog, LISP, SCHEME, ML
Definitely a neat feature. It's too bad that the bytecode language was aimed at embedded devices, and so is way too simple to convey at a high level what your program is doing. This makes implementing a fast JVM extremely difficult!
> C++ has no reflection, Perl has no reflection either
Perl lets you do all kinds of wacky things at runtime, including inspecting namespaces, inspecting the runtime stack, creating new classes -- with eval, you can basically do anything! Not to say that Perl is wonderful in every way (I will not defend the rampant cruftiness), but it *is* very flexible.
> Well, as you hate Java you will never know. Keep sitting in your little hole, but don't cry when the time for old outdated languages is over. (Like it is for COBOL, Simula, Smaltalk
And you will keep writing FOR loops, casting pointers you get from container objects (all that effort to declare the types of things, and then you have to throw the info away when they're in a list!), and reading up on the last "hot new trend" being pushed by the marketeers at Sun. Is it B2B-enabled Web Vortals? Or is it P2P Web Services with XML? I lose track.
> Regarding your rant against servlets: Easyer than a servlet? Even more easyer than a servlet? I don't know about mod_snake but about mod_perl I know pretty well.
As I mentioned above, for string manipulation, Perl is very convenient. When building a web page, it happens sometimes that one does . . . string manipulation! In those cases, I'll always take the four lines of Perl over ten to twenty lines of Java, even if I can't claim I'm using an Enterprise Java Bean.
> They ara FAR away from a servlet. FAR. What do you think why there are PERL servlet APIs implemented right now? Because of the ideas behind the servlet environment and the frameworks. Look for "libservlet" on freshmeat.
(incidentally, writing apache modules in C is also really easy)
Because it is *really easy* to code in Perl. People code all kinds of stuff in Perl -- surely you have seen CPAN. People write all this stuff because Perl makes it easy. If someone likes Sun's content handler API better than Apache's, they can implement it, no big deal.
If you want one vendor controlling everthing, why not use the Microsoft stuff? At least they don't pretend to have a Community Process, etc..
If you want strong typing, try ML, haskell, O'Caml, etc.
If you want a short program, Perl wins almost every time.
I just don't see where the tradeoffs make sense for Java.
Re:Java (Score:1)
I dont remember being forced to use most of what Sun provides. What they do provide though is a huge API that covers pretty much all the bases. You seem to forget that not everyone cares if something is proprietary or not. And Java certainly is not proprietary in the sense that you mean.
Why would you imagine that other than never having done a project in Java?
Java is pretty convenient for doing web projects also. Your comments carry even less weight with the implicit connection of web and EJB. EJB has nothing to do with the web. Can it be used for web projects? Yes. Is it necessary. No. Servlets work great.
I find it amusing all your railing against Java when Apache is a huge Java supporter in the web space.
Re:Java (Score:1)
What bothers me is that Sun pretends to be all friendly and open, while actually using a restrictive license / undocumented native functions to make it difficult for people to implement their own JVMs. If you write your app using the Sun-provided libraries, you won't be able to run it with gcj, for instance.
>> As for man-years, I would imagine that using Java increases the time required by quite a bit.
> Why would you imagine that other than never having done a project in Java?
When I did a project in Java, I found it much more convenient than C -- in particular, that it handled null pointer derefs and array out-of-bounds cases nicely, giving a stack trace that showed where the problem was. Also, garbage collection is nice, though it doesn't free you completely from memory management.
When I subsequently learned Perl really well, I found I was several times faster in Perl than in Java or in C. Not "line noise" code -- nicely written code, broken up into little classes, etc.. Java is so *verbose* that it just takes way more effort to get anything done, and once you've written it, tearing it down and rewriting seems pretty unappealing. Not to say that I love everything about Perl -- I think it is too complicated and poorly defined. But boy is it handy!
More recently, I've been doing C++ coding, which feels to me kind of like Java but without the memory bloat, and with nice generic containers (fewer verbose casts!). But boy do I miss map() and grep(). The STL equivalents just aren't the same at all. I can't say I miss anything about Java, but that may be because I haven't had to do any difficult memory management.
This is why I don't see why Java is useful -- it's more bloated than perl, comparable (but more variable) performance to perl, but even more verbose than C++. It combines the worst of both worlds! The Sun-is-evil slant is just the icing on the cake.
> Servlets work great.
Some people I'm working with are doing a big servlet application. They say it is very convenient, but we're having serious performance problems, and the memory usage is simply horrendous.
> I find it amusing all your railing against Java when Apache is a huge Java supporter in the web space.
I guess you haven't been following the latest [slashdot.org] stuff in the Apache section. Sun uses the Apache brand to gain credibility, Apache projects get Sun full-time developers: should be great, right? It would be, if Sun weren't so nasty.
Re:Java (Score:1)
Re:Java (Score:1)
I strongly suggest you read the relevant gcj FAQ entry [gnu.org] -- I think you may be underestimating how proprietary it is.
> And youre right that GC doesnt solve all the memory management issues. wish all people thought that
Yep. In fact, when we used Swing last year, we had lots of trouble with memory leaks in the libraries. Aargh!
> Perl is very handy but there are many projects I wouldn't want to touch with it.
What sorts of projects? As long as your programmers are skilled, I think performance is the only real problem.
> That being said I wouldnt use anything else for lots of my scripting and admin tasks.
I find that using map(), grep(), sub{} expressions, and the class system makes manipulating complex data structures very easy. And most performance-sensitive things are done off in C libraries.
> I just can't deal with C++ anymore.... Are generic containers less verbose?
I think so.
using namespace std;
...
map<int,int> foo;
foo[1] = 2;
cout << foo[1];
The main place where I encounter verbosity is in using STL iterators, but even there I don't see that its any less verbose that Java, where you are either using iterators or for loops.
> Its too "dirty" and there are far to many things it leaves you to deal with.
I think C++ is way too complicated, but if you stick to unix, the overall experience isn't too yucky. What irritates me about STL is the compiler-compatibility problems, particularly on MS Windows.
> I think Java's best space is in enterprise-level applications. I dont see Perl being all that useful there nor C++....
I'm not sure what you mean by "enterprise-level applications" -- do you mean things like the EToys ecommerce system [perl.com]? If you mean, "we have to sell this thing to a PHB who will only buy it if it is written in Java," then, okay, I guess that's the only option.
> I'd be curious to know what app server or servlet container youre using. Several are notorious for what you're reporting.
They are using Tomcat. Tomcat 4 doesn't seem to be any faster than 3; both have about 10 times the latency of Apache for "hello world."
We tried out Resin last year, and it was much better than Tomcat, but building your app on a hidden-source-code foundation is just asking for trouble down the line. Not to mention having to deal with licensing issues.
> And anyhow Apache said things are getting better and they have support from others (like IBM).
Then IBM should release an LGPL implementation of the JVM and class libraries, and everyone should use that. As things stand now, Sun has control, and they have demonstrated that they cannot be trusted.
Seriously, read the GCJ FAQ entry and think about it for a minute or two. What Sun is doing is pretty insidious.
Re:Java (Score:1)
Re:Java (Score:1)
Have you actually written Perl programs with lots of classes? It's a bit ugly, but not that bad. I actually kind of *like* how exposed the mechanics are. It is a pain to have to write the extra line of code in the constructor to bless the reference, but that's all it is: one line of code. Not the end of the world.
> Tomcat is a reference and not something that should be put into production
It certainly seems that way. I find that very disappointing.
> There is nothing hidden about the Resin source. It is downloadable and modifiable.
Wow, you are right about this! I will start agitating for further consideration of Resin. Thanks for pointing that out.
> IBM can't release an LGPL implementation. They dont own Java.
Do you mean there are patent issues, or trademark issues, or what? Even if they had to call it JNJ (JNJ's Not Java), what's to stop them from writing the program? Clearly, copyright law bars them from using Sun's code, but that's not what I'm proposing.
> I just read the section of the FAQ that you mentioned and I see accusations with no proof to back them up.
(warning: sarcasm)
Sure, those people are reimplementing all of Sun's libraries simply for the pleasure of doing so.
(end of sarcasm)
There were actually two projects working on that (GNU Classpath and the GCJ people at Cygnus) but they have merged efforts now.
Re:Java (Score:1)
Maybe I wasn't clear. I'm not saying those issues don't exist. What I'm saying is that its goofy in an article to mention something like that without at least giving some examples of what you're referring to. When people read that sort of thing they tend to want proof. A few links or something would go a long way.
Re:Java (Score:1)
Correct. Persistant objects (no process fork()) make scalability under Java much better as you can use one shared object as for example a cache. This has been covered by an excellent article before here [aceshardware.com]
Re:Java (Score:2)
My biggest problem with Java is how horribly ugly it is. Interfaces are a joke and the lack of MI is incredibly painful. It's collections are utterly uselessly and adapter classes are almost as painful as functors in C++ although the lack of any binder functions make them much less useful.
Java is, at best, an academic language. Very little useful things can be done with it other then a 20 line hello world program. It has some good ideas (Inner Classes) but they are poorly implemented and the memory model absolutely sucks.
Passing by reference encourages sloppy programming as the use of final is not encouraged as it should. A well written C++ framework is a thousand times more robust then Java. Well written C++ classes can literally be safe even with monkeys smacking the keyboard in Emacs.
Java would be better if 1) it was an open language and allowed input from people other than Sun engineers 2) it was organized by a company looking to create a good platform and not by a company looking to exploit every buzz phrase in the world 3) the JVM bytecode was robust enough to be useful for other languages (and not bastardized versions of languages such as Mangled C++).
Re:Java (Score:1)
Please. Interfaces couldnt be any simpler or easier to use. Lack of MI might be incredible painful to the
Re:Java (Score:2)
Interfaces are a poor excuse for MI and are misused in Java. The fact that interfaces can't have a default implementation (or that certain aspects of an interface can't be option) is why interfaces stink. GCC has an extension to C++ called signatures which are much more useful than Java interfaces especially since they can be applied to a class post-compilation.
Java doesn't pass by reference. It passes reference by value. Your mistake is a common one.
If Java does indeed pass value by reference, then surely I can pass reference by reference then perhaps? Or maybe dereference the reference and pass by value directly?
No, you can't. Java doesn't give you the option. It does not have a 'robust' passing mechanism. Encouraging objects to be passed around by reference (making them writable) is very bad programming practice. Strict use of const (or final in Java) makes programming much safer. There is no reason why drawString should be able to modify the String object that is passed in.
Java does have input from people other than the engineers at Sun.
Is there a non-partial committee that oversees the development of the Java language? or do a bunch of suits at Sun determine what is in the language?
They may be open to suggestions, but I would equate that more to stealing ideas.
JVM bytecode *is* robust enough to be useful for other languages.
So then it supports MI? Or referencing objects? Or passing objects by value? It supports operating overloading? Come on now. JVM bytecode is only useful to languages which only contain identical functionality to Java.
The thing I wonder about though is why does that even make a difference?
Because then Java could be used (practically) with other languages. The C-to-Java wrappers are a joke. If a language cannot be mixed with other languages, then it is useless in the real world and useless for most production programs where legacy libraries are a reality.
Re:Java (Score:1)
Welcome to the recession (Score:1)
Welcome to the recession, expert programmers in every language are on the sidewalks now :-( So with proper hiring, there is no variance any more.
Re:Not in C++ (Score:2)
iirc, REBOL [rebol.com] has these features. Unfortunately, the licensing model for that language for commercial purposes sort of prices it out of the market even though it is a killer language.
Re:Great idea (Score:2)
If you don't want core dumps, disable them. Personally, I find core dumps to be rather useful things... if something goes wrong, you can track down what happened, unlike with interpreted languages where you'll be lucky to get an uninformative "Abnormal program termination" message back.
Re:Great idea (Score:1)
Also, if you use std::string you don't get buffer overflows. gets rid of format string errors. Most of the problem with current c++ usage is that people treat it like c with classes, while it has *so* much more to offer!
Re:Great idea (Score:3, Funny)
Re:Great idea (Score:1)
Format string errors? That's C. No, C++ in the webserver will bring you the joys of doing template code instantiation on every single page lookup! Fun for the whole family!
The template is instanciated by the compiler not by the web server.
If you use an interpreter a template class is just a meta class.
Nothing to instanciated neither.
Probably you should get a degree
Or at least inform your self a bit better how languages work. No wonder that all people(like you) think that C is ALLWAYS faster than Java.
Regards,
angel'o'sphere
A better idea .... (Score:2)
I like C, but I think they got this the wrong way around...
Instead of creating a scripting language out of C, they should have created a good way to embed html codes in the C source (eg. a pre-processor and a custom library), and compile the pages to a cgi program.
This way you will get the best out of both worlds. You can code in C, and get real compile time checking instead of an interpreter failure because of a misspelled variable name or keyword. You get the speed of a compiled program and the C code can contain real html with no escape characters.
With a good library (no libc by default, that is too risky ...) you can
get access to apache internals, code in C (that is the whole idea,
isn't it ?) and get super fast performance. The library needs a large
collection of string handling functions.
Re:A better idea .... (Score:2, Informative)
Supported features: client-side cookies, file-uploading, fast-cgi and environment debugging.
http://www.gnu.org/software/cgicc/
http://www.fastcgi.com (A language independent, open extension to CGI, that provides better performance due to process persistance.)
http://debianlinux.net/c++.html (C++ resources)
Re:A better idea .... (Score:2)
printf("<tr>\n");
printf("<td colspan = \"2\">\n");
printf("<img src=\"/img/myimage.png\" alt=\"comment\" border=\"0\" height=\"100\" width=\"150\">");
Not very readable. We need a preprocessor which embeds the HTML code in C for readability.
Re:A better idea .... (Score:1)
Still I don't understand why people insist on wasting their time writting web applications in C.
Re:A better idea .... (Score:2)
example:
<H1> Say it ten times </H1>
<OL>
<CARROT>
for (int i = 0; i < 10;i++)
cout << "<LI> this whole thing will be compiled" << endl;
</CARROT>
</OL>
is converted to:
cout << "<H1> Say it ten times </H1> "" << endl;
cout << "<OL>" << endl;
cout << "<!-- begin embedded carrot section -->" << endl;
for (int i = 0; i < 10;i++)
cout << "<LI> this whole thing will be compiled" << endl;
cout << "<!-- end embedded carrot section -->" << endl;
cout << "</OL>" << endl;
cgi is not allways faster (Score:1)
Download (Score:1)
Re:Download (Score:1)