c++ web scripting

Has anyone ever heard of a c++ web 'scripting' engine? I think it
would be fairly easy to make one. All that is needed is an
intermediary that compiles the code on demand and caches the executables.

For example, I put a file like hello.cpp:

#include <iostream>
int main(void) {
cout << "<h1>hello world</h1>";
}

in the web server directory, and when I point my browser to
http://localhost/hello.cpp, the c++ web 'scripting' engine compiles
the code on the fly and serves the output over http. It would work
just like CGI, except the compilation is automatic.

re: c++ web scripting

"Shailesh Humbad" <noreply@nowhere.com> wrote in message
news:ROu0d.526$MG3.387@fe2.columbus.rr.com...[color=blue]
> Has anyone ever heard of a c++ web 'scripting' engine? I think it would
> be fairly easy to make one. All that is needed is an intermediary that
> compiles the code on demand and caches the executables.
>
> For example, I put a file like hello.cpp:
>
> #include <iostream>
> int main(void) {
> cout << "<h1>hello world</h1>";
> }
>
> in the web server directory, and when I point my browser to
> http://localhost/hello.cpp, the c++ web 'scripting' engine compiles the
> code on the fly and serves the output over http. It would work just like
> CGI, except the compilation is automatic.[/color]

It would be easy to setup a web server to do that. Your 'scripting engine'
is just the compiler followed by running the program.

john

re: c++ web scripting

Shailesh Humbad wrote:
[color=blue]
> Has anyone ever heard of a c++ web 'scripting' engine?[/color]

cgicc. It works great.
[color=blue]
> I think it
> would be fairly easy to make one. All that is needed is an
> intermediary that compiles the code on demand and caches the executables.[/color]

Wha? What's wrong with just configuring your CGI to call your .EXE or
binary? I done all this, last millenium.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

re: c++ web scripting

Shailesh Humbad wrote:[color=blue]
> Has anyone ever heard of a c++ web 'scripting' engine? I think it would
> be fairly easy to make one. All that is needed is an intermediary that
> compiles the code on demand and caches the executables.
>
> For example, I put a file like hello.cpp:
>
> #include <iostream>
> int main(void) {
> cout << "<h1>hello world</h1>";
> }
>
> in the web server directory, and when I point my browser to
> http://localhost/hello.cpp, the c++ web 'scripting' engine compiles the[/color]

for CGI, it won't work this way for your above code.
[color=blue]
> code on the fly and serves the output over http. It would work just
> like CGI, except the compilation is automatic.[/color]

C++ cgi code can already work with C/C++ interpreter Ch.

re: c++ web scripting

On Sat, 11 Sep 2004 07:34:40 +0000, Phlip wrote:
[color=blue]
> Shailesh Humbad wrote:
>[color=green]
>> Has anyone ever heard of a c++ web 'scripting' engine?[/color]
>
> cgicc. It works great.[/color]

Seconded. cgicc works way better if you want it to output compliant HTML
than if you want "normal" (nonstandard, table-driven, or otherwise
silly) HTML, though. IMO this is a feature, though from the mailing list I
seem to be in the minority.

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

re: c++ web scripting

Shailesh Humbad wrote:
[color=blue]
> Has anyone ever heard of a c++ web 'scripting' engine? I think it
> would be fairly easy to make one. All that is needed is an
> intermediary that compiles the code on demand and caches the executables.
>
> For example, I put a file like hello.cpp:
>
> #include <iostream>
> int main(void) {
> cout << "<h1>hello world</h1>";
> }
>
> in the web server directory, and when I point my browser to
> http://localhost/hello.cpp, the c++ web 'scripting' engine compiles
> the code on the fly and serves the output over http. It would work
> just like CGI, except the compilation is automatic.[/color]

Hi,

I have written a webapplicationserver in c++, which supports c++. I defined
a template-language like PHP, JSP or Mason for c++, so you can embed
c++-code in HTML-pages. It much faster than cgi, because there is no need
to start a process for each request. Even dynamic pages with this system
are faster than static pages in apache.

Here is a example of a dynamic web-page:

<%args>
some_text // define query-parameter here
</%args>
<html>
<body>
<# this is a comment, which is precompiled away #>
<{
// do some c++-coding here:
for (unsigned i = 0; i < 10; ++i)
{
// output the value of the query-param "some_text" 10 times:
}>
<p> <$ i $> : <$ some_text $> </p>
<{
} // end of for-loop
}>
</body>
</html>
__END__

The tags <$ ... $> outputs a c++-expression. Everything here is written to a
std::ostream, so you can output every object which has a
"operator<<(std::ostream&)" defined.

There are many more features like embedding other c++-components or special
tags for initialization or support for i18n.

I would like to release it under the GPL, but it lacks documentation yet.
What I have is a short introduction as a word-document written in german.
If someone is interested in helping, let me know.

It would be also nice to hear comments.


Tommi Mäkitalo

re: c++ web scripting

Tommi Mäkitalo wrote:[color=blue]
> Shailesh Humbad wrote:
>
>[color=green]
>>Has anyone ever heard of a c++ web 'scripting' engine? I think it
>>would be fairly easy to make one. All that is needed is an
>>intermediary that compiles the code on demand and caches the executables.
>>
>>For example, I put a file like hello.cpp:
>>
>>#include <iostream>
>>int main(void) {
>>cout << "<h1>hello world</h1>";
>>}
>>
>>in the web server directory, and when I point my browser to
>>http://localhost/hello.cpp, the c++ web 'scripting' engine compiles
>>the code on the fly and serves the output over http. It would work
>>just like CGI, except the compilation is automatic.[/color]
>
>
> Hi,
>
> I have written a webapplicationserver in c++, which supports c++. I defined
> a template-language like PHP, JSP or Mason for c++, so you can embed
> c++-code in HTML-pages. It much faster than cgi, because there is no need
> to start a process for each request. Even dynamic pages with this system
> are faster than static pages in apache.
>
> Here is a example of a dynamic web-page:
>
> <%args>
> some_text // define query-parameter here
> </%args>
> <html>
> <body>
> <# this is a comment, which is precompiled away #>
> <{
> // do some c++-coding here:
> for (unsigned i = 0; i < 10; ++i)
> {
> // output the value of the query-param "some_text" 10 times:
> }>
> <p> <$ i $> : <$ some_text $> </p>
> <{
> } // end of for-loop
> }>
> </body>
> </html>
> __END__
>
> The tags <$ ... $> outputs a c++-expression. Everything here is written to a
> std::ostream, so you can output every object which has a
> "operator<<(std::ostream&)" defined.
>
> There are many more features like embedding other c++-components or special
> tags for initialization or support for i18n.
>
> I would like to release it under the GPL, but it lacks documentation yet.
> What I have is a short introduction as a word-document written in german.
> If someone is interested in helping, let me know.
>
> It would be also nice to hear comments.
>
>
> Tommi Mäkitalo[/color]

Hi Tommi,

This is exactly what I was looking for. I'm so surprised nothing like
this already exists. If you think about it, .Net's "new and improved"
approach toward web applications is to compile the code on request,
and keep the compiled object code in a cache. However, .Net does not
compile to native code, but to an intermediate language, which adds
overhead. We were so busy with ASP, PHP, and other scripting
languages, that we only now realized we can use C++ directly and just
have the server compile it on the fly.

I understand that CGI is slow because of the need to create new
processes. I'd be interested to understand your implementation and
try it out.

My initial comment is that you have three different kinds of
delimeters, <{, <#, and <$. ASP uses <% while PHP uses <?. I think
the easiest to type is the last one, <?, because it only involves the
left-shift key with the left hand, and the lower, easily-reachable "?"
key with the right hand. Also, I'm not sure there is a need for
multiple kinds of delimeters. In ASP, when you want to print out a
value, you write <% =some_var %>, and it has no equivalent shortcut
for comments. PHP has no equivalent for either comments or printing
values, although you can leave out the semicolon for single line
statements, e.g. <?php print "hello" ?>. Now by default in PHP, the
opening tag is required to be <?php. Maybe you can use something like
this for your engine, like <?tomi ?>, and use standard commenting
paradigms for comments and values, like <?tomi /* this is comments */
?> and <?tomi cout << "hello"; ?>. These are just suggestions.

Shailesh

re: c++ web scripting

Owen Jacobson wrote:
[color=blue]
> On Sat, 11 Sep 2004 07:34:40 +0000, Phlip wrote:
>
>[color=green]
>>Shailesh Humbad wrote:
>>
>>[color=darkred]
>>>Has anyone ever heard of a c++ web 'scripting' engine?[/color]
>>
>>cgicc. It works great.[/color]
>
>
> Seconded. cgicc works way better if you want it to output compliant HTML
> than if you want "normal" (nonstandard, table-driven, or otherwise
> silly) HTML, though. IMO this is a feature, though from the mailing list I
> seem to be in the minority.
>[/color]
(I posted this a few days ago, but it went to alt.html by accident.)

I tried cgicc prior to posting. The difference is the application
development cycle. I assume there are three steps with cgicc: edit
the code, run the compiler, and then reload the browser. When I say
scripting engine, I mean that there are only two steps: edit the code,
and reload the browser.

I see ch is an interpreter for a superset of C (with classes from
C++), but not full C++. Not only that, but I don't want
interpretation, I want cached, natively-compiled executables.

Like another poster said, it would be fairly easy to implement such a
thing. I'm just surprised it hasn't yet. Why use .Net for your web
projects when you can use C++, and skip the extra layer of complexity?

re: c++ web scripting

Shailesh Humbad wrote:
[color=blue]
> I tried cgicc prior to posting. The difference is the application
> development cycle. I assume there are three steps with cgicc: edit
> the code, run the compiler, and then reload the browser. When I say
> scripting engine, I mean that there are only two steps: edit the code,
> and reload the browser.
>
> I see ch is an interpreter for a superset of C (with classes from
> C++), but not full C++. Not only that, but I don't want
> interpretation, I want cached, natively-compiled executables.
>
> Like another poster said, it would be fairly easy to implement such a
> thing. I'm just surprised it hasn't yet. Why use .Net for your web
> projects when you can use C++, and skip the extra layer of complexity?[/color]

Why should C++ recompile between two page hits?

You need to think about routing data strictly thru XML and XSLT in XHTML
output mode. Then, regardless of the language substrate, you have templates
in a widely supported template language. Not a system that lets you couple
HTML to C++ in elaborate ways.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[color=blue]
>[/color]

re: c++ web scripting

Phlip wrote:[color=blue]
> Shailesh Humbad wrote:
>
>[color=green]
>>I tried cgicc prior to posting. The difference is the application
>>development cycle. I assume there are three steps with cgicc: edit
>>the code, run the compiler, and then reload the browser. When I say
>>scripting engine, I mean that there are only two steps: edit the code,
>>and reload the browser.
>>
>>I see ch is an interpreter for a superset of C (with classes from
>>C++), but not full C++. Not only that, but I don't want
>>interpretation, I want cached, natively-compiled executables.
>>
>>Like another poster said, it would be fairly easy to implement such a
>>thing. I'm just surprised it hasn't yet. Why use .Net for your web
>>projects when you can use C++, and skip the extra layer of complexity?[/color]
>
>
> Why should C++ recompile between two page hits?
>
> You need to think about routing data strictly thru XML and XSLT in XHTML
> output mode. Then, regardless of the language substrate, you have templates
> in a widely supported template language. Not a system that lets you couple
> HTML to C++ in elaborate ways.
>[/color]

First, I think it was pretty obvious from my post, "I want *cached*,
natively-compiled executables", that the C++ engine would not
recompile between two hits to the same, unmodified page.

Second, given that not all data is stored in XML, simple XSLT
transformation is not always possible. We need access to databases,
hence libraries written in programming languages like C++. But this
point about where to put transformation logic seems more like a
religious debate.

re: c++ web scripting

"Shailesh Humbad" <noreply@nowhere.com> wrote in message
news:Qm%0d.14068$_z4.1016@fe1.columbus.rr.com...[color=blue]
> Tommi Mäkitalo wrote:[color=green]
> > Shailesh Humbad wrote:
> >
> >[color=darkred]
> >>Has anyone ever heard of a c++ web 'scripting' engine? I think it
> >>would be fairly easy to make one. All that is needed is an
> >>intermediary that compiles the code on demand and caches the[/color][/color][/color]
executables.[color=blue][color=green][color=darkred]
> >>
> >>For example, I put a file like hello.cpp:
> >>
> >>#include <iostream>
> >>int main(void) {
> >>cout << "<h1>hello world</h1>";
> >>}
> >>
> >>in the web server directory, and when I point my browser to
> >>http://localhost/hello.cpp, the c++ web 'scripting' engine compiles
> >>the code on the fly and serves the output over http. It would work
> >>just like CGI, except the compilation is automatic.[/color]
> >
> >
> > Hi,
> >
> > I have written a webapplicationserver in c++, which supports c++. I[/color][/color]
defined[color=blue][color=green]
> > a template-language like PHP, JSP or Mason for c++, so you can embed
> > c++-code in HTML-pages. It much faster than cgi, because there is no[/color][/color]
need[color=blue][color=green]
> > to start a process for each request. Even dynamic pages with this system
> > are faster than static pages in apache.
> >
> > Here is a example of a dynamic web-page:
> >
> > <%args>
> > some_text // define query-parameter here
> > </%args>
> > <html>
> > <body>
> > <# this is a comment, which is precompiled away #>
> > <{
> > // do some c++-coding here:
> > for (unsigned i = 0; i < 10; ++i)
> > {
> > // output the value of the query-param "some_text" 10 times:
> > }>
> > <p> <$ i $> : <$ some_text $> </p>
> > <{
> > } // end of for-loop
> > }>
> > </body>
> > </html>
> > __END__
> >
> > The tags <$ ... $> outputs a c++-expression. Everything here is written[/color][/color]
to a[color=blue][color=green]
> > std::ostream, so you can output every object which has a
> > "operator<<(std::ostream&)" defined.
> >
> > There are many more features like embedding other c++-components or[/color][/color]
special[color=blue][color=green]
> > tags for initialization or support for i18n.
> >
> > I would like to release it under the GPL, but it lacks documentation[/color][/color]
yet.[color=blue][color=green]
> > What I have is a short introduction as a word-document written in[/color][/color]
german.[color=blue][color=green]
> > If someone is interested in helping, let me know.
> >
> > It would be also nice to hear comments.
> >
> >
> > Tommi Mäkitalo[/color]
>
> Hi Tommi,
>
> This is exactly what I was looking for. I'm so surprised nothing like
> this already exists. If you think about it, .Net's "new and improved"
> approach toward web applications is to compile the code on request,
> and keep the compiled object code in a cache. However, .Net does not
> compile to native code, but to an intermediate language, which adds
> overhead. We were so busy with ASP, PHP, and other scripting
> languages, that we only now realized we can use C++ directly and just
> have the server compile it on the fly.[/color]
<snip>

Doesn't .Net provide one or two good ways to use C++ code inside a .Net
application? If not P/Invoke, then at least using "unsafe"? Then, if you
go with .Net, you could choose between higher-level languages and C++
depending on your needs.

--
David Hilsee

re: c++ web scripting

Shailesh Humbad wrote:
[color=blue]
> First, I think it was pretty obvious from my post, "I want *cached*,
> natively-compiled executables", that the C++ engine would not
> recompile between two hits to the same, unmodified page.[/color]

Okay, this is a non-sequitur. Here's how C++ works. You write a program, run
a compiler, produce an executable, put it on a server, and stroll away. The
executable never changes. It may frequently serve similar pages with
different content. There's never a need to recompile it (regardless what
page content it serves).

When you say "cached", this makes me think you think C++ must recompile each
time it is used, or each time the data changes, or something. If you
envision some slight performance boost from serving the same page twice
without re-rendering it, then you are confusing some other CGI optimization
system with C++ compilation. If you need such a performance boost, just save
your page an re-serve it.

Please tell a complete, round-trip story that you envision some hypothetical
C++ CGI layer doing.
[color=blue]
> Second, given that not all data is stored in XML, simple XSLT
> transformation is not always possible. We need access to databases,
> hence libraries written in programming languages like C++. But this
> point about where to put transformation logic seems more like a
> religious debate.[/color]

No religion needed. If you pipe data, whatever its format, into XML, it will
become compatible with a very good template system, XSLT, which has a
built-in mode to emit XHTML.

Further, you can detect the user's browser type, and if it is compatible,
you can send it your XSLT, and it will render the pages for you. All you
need to do is send that browser your XML payload, and it does the rest.
That's not religion, it is interoperability. We could have got it with
tab-delimited files, or INI file format, or whatever. As an accident of
history, we got it with XML.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

re: c++ web scripting

Phlip wrote:[color=blue]
> Okay, this is a non-sequitur. Here's how C++ works. You write a[/color]
program, run[color=blue]
> a compiler, produce an executable, put it on a server, and stroll away. The
> executable never changes. It may frequently serve similar pages with
> different content. There's never a need to recompile it (regardless what
> page content it serves).
>
> When you say "cached", this makes me think you think C++ must recompile each
> time it is used, or each time the data changes, or something. If you
> envision some slight performance boost from serving the same page twice
> without re-rendering it, then you are confusing some other CGI optimization
> system with C++ compilation. If you need such a performance boost, just save
> your page an re-serve it.
>
> Please tell a complete, round-trip story that you envision some hypothetical
> C++ CGI layer doing.
>[/color]

Yeah, I can see where the confusion lies. When I say cached, I mean
the executables themselves are cached, not the HTML output of those
executables. Here is the algorithm:

(In Web Server)
* Web server receives request for a .cpp file.
* Web server invokes the CGI handler for .cpp files, ServeCPPFile.
(In ServeCPPFile)
If file does not exist Then
Delete any file status entry from the database
Return 404
End If
* Lookup FileLastModifiedTime in database, searching by file name.
If no file status exist in the database Then
Save the FileName and LastModified timestamp in the database
Compile the cpp code (save exe in cache folder)
Else
If actual FileLastModified != FileLastModified in database Then
Compile the cpp code (save exe in cache folder)
End If
End If
* Run the compiled code
(In Web Server)
* Output of ServeCPPFile is sent to the client.

It's easiest to think of the C++ CGI Layer as spawning/forking a new
process to handle each page request. In this case, the ServeCPPFile
process is launched, and then ServeCPPFile launches another process to
run the compiled CPP code. In practice, some other techniques might
be used to save the overhead of creating processes.

Process heirarchy:
Apache -> ServeCPPFile -> EXE File

Output piping:
Client <- Apache <- ServeCPPFile <- EXE File
[color=blue]
>
> No religion needed. If you pipe data, whatever its format, into XML, it will
> become compatible with a very good template system, XSLT, which has a
> built-in mode to emit XHTML.
>
> Further, you can detect the user's browser type, and if it is compatible,
> you can send it your XSLT, and it will render the pages for you. All you
> need to do is send that browser your XML payload, and it does the rest.
> That's not religion, it is interoperability. We could have got it with
> tab-delimited files, or INI file format, or whatever. As an accident of
> history, we got it with XML.
>[/color]

I'm not familiar with XSLT's advantages, having never tried it, but
I'll take your word for it. One caveat is that one loses some
performance for the gain in interoperability, particularly for legacy
data in databases.

re: c++ web scripting

....[color=blue][color=green]
>>
>> Hi Tommi,
>>
>> This is exactly what I was looking for. I'm so surprised nothing like
>> this already exists. If you think about it, .Net's "new and improved"
>> approach toward web applications is to compile the code on request,
>> and keep the compiled object code in a cache. However, .Net does not
>> compile to native code, but to an intermediate language, which adds
>> overhead. We were so busy with ASP, PHP, and other scripting
>> languages, that we only now realized we can use C++ directly and just
>> have the server compile it on the fly.[/color]
> <snip>
>[/color]
(sorry - I would like to answer Shailesh comment, but my news-server missed
it)

Let me clearify the concept of my server first.

The idea is to create c++-code out of html-files and compile these into
something executable. I want to create compiled code. Just like I do
c++-programming. Not compile when called like Jsp, but when a client
requests a page, the code is here to generate the answer at full speed. No
compiler, no interpreter or runtime, which eats runtime or memory.

I tried to create a apache-module, but it failed, because apache is linked
with a c-linker and can't load shared libraries in c++. Next I thought
about creating a apache-module, which passes the requests to another
daemon, which is written in c++. But how do I pass the requests? A pipe
would be ok. I need to stream the request to my process and the process
streams the answer. But if my process waits for requests on a pipe, it can
also listen on a socket. So I had my webapplicationserver.

Html-pages with ebedded c++-code is precompiled into c++-classes, which is
compiled into object-code and linked to a shared library. The Webserver
loads this shared library dynamically and instantiates this classes to
process the received requests.

The precompiler, I wrote can even compile pictures like jpeg or gifs into
c++-classes, so I can put a whole webapplication including all graphics
into a single shared library.

The language, I created borrows much from Mason (http://www.masonhq.com)
because this was my preferred template-engine. That's the reason I don't
use tags from Jsp or Php or Asp.

Shailish suggested to reduce the tags to a single one like Php, which uses
<? or Asp with <%. It is one possible solution too. But I need more tags. I
started with <%some_tag>...</%some_tag> like Mason, which conformes to XML
too. In practice it is very hard to type, so I shortened some often used
tags to 2 characters manly to reduce typing and improve readability.
C++-code is marked with <%cpp>..</%cpp> or shorthand <{...}>, which
resembles a code-block in c++. Expressions are marked with <$...$> which is
like a perl- or shell-variable. Comments are <%doc>...</%doc> or shorthand
<#...#> like perl- or shell-comment. Another tag is <& ... &>, which embeds
another c++-component into the page, like a subroutine-call ('&' marks a
function in perl or a reference in c++).

I have other tags to define queryparameters, attributes, initialization,
defining subcomponents and others. This long form is extendable, when I
need something more.

And best of all: I have a working implementation.

OK - It is time to give it a name. The server is called 'tntnet'. The files,
with ebedded c++ are .ecpp-files.

I will publish my source very soon.


Tommi

re: c++ web scripting

Shailesh Humbad wrote:
[color=blue][color=green]
> > Please tell a complete, round-trip story that you envision some[/color][/color]
hypothetical[color=blue][color=green]
> > C++ CGI layer doing.[/color][/color]
[color=blue]
> Yeah, I can see where the confusion lies. When I say cached, I mean
> the executables themselves are cached, not the HTML output of those
> executables. Here is the algorithm:
>
> (In Web Server)
> * Web server receives request for a .cpp file.
> * Web server invokes the CGI handler for .cpp files, ServeCPPFile.
> (In ServeCPPFile)
> If file does not exist Then
> Delete any file status entry from the database
> Return 404
> End If
> * Lookup FileLastModifiedTime in database, searching by file name.
> If no file status exist in the database Then
> Save the FileName and LastModified timestamp in the database
> Compile the cpp code (save exe in cache folder)
> Else
> If actual FileLastModified != FileLastModified in database Then
> Compile the cpp code (save exe in cache folder)
> End If
> End If
> * Run the compiled code
> (In Web Server)
> * Output of ServeCPPFile is sent to the client.
>
> It's easiest to think of the C++ CGI Layer as spawning/forking a new
> process to handle each page request. In this case, the ServeCPPFile
> process is launched, and then ServeCPPFile launches another process to
> run the compiled CPP code. In practice, some other techniques might
> be used to save the overhead of creating processes.
>
> Process heirarchy:
> Apache -> ServeCPPFile -> EXE File
>
> Output piping:
> Client <- Apache <- ServeCPPFile <- EXE File[/color]

You are planning to add an incredible amount of complexity and risk, without
benefit. What could such a Rube Goldberg contraption do that a text template
system can't do?
[color=blue]
> I'm not familiar with XSLT's advantages, having never tried it, but
> I'll take your word for it. One caveat is that one loses some
> performance for the gain in interoperability, particularly for legacy
> data in databases.[/color]

Premature optimization is the root of all evil.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

re: c++ web scripting

Shailesh Humbad <noreply@nowhere.com> wrote:[color=blue][color=green][color=darkred]
> >>>Has anyone ever heard of a c++ web 'scripting' engine?
> >>[/color][/color]
>
> Like another poster said, it would be fairly easy to implement such a
> thing. I'm just surprised it hasn't yet. Why use .Net for your web
> projects when you can use C++, and skip the extra layer of complexity?[/color]

Because in scripting languages there's lots of things you can
do in 1 line that require pages and pages of code and debugging in C++.
For example sockets. Why can't you go: fstream foo("http://bar.com");
and send your request and read the response with the << and >>
operators. It would be good if there were a bunch of libraries that
would enable you to write web-pages in C++ (compiled, I mean) without
having to do any low-level stuff. Another example would be parsing a
HTTP header and extracting any GET or POST variables.

re: c++ web scripting

Old Wolf wrote:[color=blue]
> Shailesh Humbad <noreply@nowhere.com> wrote:
>[color=green][color=darkred]
>>>>>Has anyone ever heard of a c++ web 'scripting' engine?
>>>>[/color]
>>Like another poster said, it would be fairly easy to implement such a
>>thing. I'm just surprised it hasn't yet. Why use .Net for your web
>>projects when you can use C++, and skip the extra layer of complexity?[/color]
>
>
> Because in scripting languages there's lots of things you can
> do in 1 line that require pages and pages of code and debugging in C++.
> For example sockets. Why can't you go: fstream foo("http://bar.com");
> and send your request and read the response with the << and >>
> operators. It would be good if there were a bunch of libraries that
> would enable you to write web-pages in C++ (compiled, I mean) without
> having to do any low-level stuff. Another example would be parsing a
> HTTP header and extracting any GET or POST variables.[/color]

I know exactly what you're talking about, having written some socket
apps in raw C/C++. The thing is that if those high-level libraries
don't already exist, they can be written. A lot of people have
invested their effort in creating easy-to-use web scripting libraries
(many written in C++ themselves!), but maybe they could have just
created those libraries for an embedded C++ engine in the web server.
I don't understand why we need to keep inventing new languages--it's
just a magnificent waste of limited educational resources.

re: c++ web scripting

Phlip wrote:
[color=blue]
> Shailesh Humbad wrote:[color=green]
>>I'm not familiar with XSLT's advantages, having never tried it, but
>>I'll take your word for it. One caveat is that one loses some
>>performance for the gain in interoperability, particularly for legacy
>>data in databases.[/color]
>
>
> Premature optimization is the root of all evil.
>[/color]

Can you tell me what XSLT engine you use? I would like to learn more
about it.

re: c++ web scripting

Shailesh Humbad wrote:
[color=blue]
> Can you tell me what XSLT engine you use? I would like to learn more
> about it.[/color]

Within C++, because I'm lazy, I use MSXML4. It was just lying in my system
folder, and I didn't need to download or install it. I just grab it with
this:

#import <msxml4.dll>

Don't write that. It gives me the same XML kit as other languages would
provide (possibly including .NET). However, if you don't know <comdef.h> or
other MS-specific C++ extensions to support COM, don't try to start now.
There are other libraries available but I don't know their names.

All websites should use only XHTML, because it's easier to test. Mistakes
are easier to catch. This line switches XSL to output XHTML:

<xsl:output method="xml" media-type="text/html"
standalone="no" omit-xml-declaration="yes"
encoding="UTF-8"/>

Here's a snip of useless XML:

<nodes>
<node>Hello</node>
<node>World</node>
</nodes>

Here is XSL to transform that into a Web page containing the payload inside
two text areas:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:param name="fileName"/>

<xsl:output method="xml" media-type="text/html"
standalone="no" omit-xml-declaration="yes"/>

<xsl:template match="*">
<ul>
<li><xsl:value-of select="name()"/>
<ul>
<xsl:for-each select="*">
<li>
<form name="{$fileName}!/nodes/node[1]">
<xsl:value-of select="name()"/><TEXTAREA
name="contents">
<xsl:value-of select="text()"/></TEXTAREA>
</form>
</li>
</xsl:for-each>
</ul>
</li></ul>
</xsl:template>

</xsl:stylesheet>

The value of this system is HTML tags like <form> appears inline with <xsl>
stuff. The system matches escape character conventions, so programmers don't
need to convert them so often.

The drawback is the code looks like a sea of <><> characters!

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

re: c++ web scripting

Old Wolf wrote:
[color=blue]
> Shailesh Humbad <noreply@nowhere.com> wrote:[color=green][color=darkred]
>> >>>Has anyone ever heard of a c++ web 'scripting' engine?
>> >>[/color]
>>
>> Like another poster said, it would be fairly easy to implement such a
>> thing. I'm just surprised it hasn't yet. Why use .Net for your web
>> projects when you can use C++, and skip the extra layer of complexity?[/color]
>
> Because in scripting languages there's lots of things you can
> do in 1 line that require pages and pages of code and debugging in C++.
> For example sockets. Why can't you go: fstream foo("http://bar.com");
> and send your request and read the response with the << and >>
> operators. It would be good if there were a bunch of libraries that
> would enable you to write web-pages in C++ (compiled, I mean) without
> having to do any low-level stuff. Another example would be parsing a
> HTTP header and extracting any GET or POST variables.[/color]
Hi,

my webapplicationserver (tntnet) is just what you miss. You can write
web-pages in C++ (compiled, I mean) without having to do any low-level
stuff. It parses HTTP-headers, extracts GET or POST variables including
mime-decoding for http-uploads and offers them as std::string-variables to
the application.

It is multithreaded and completely written in c++. There is a precompiler to
compile html-pages into c++-classes.

Just write a webapplication it html with some special tags to escape to c++.
To generate output you can just stream (std::ostream) it to the client.

I use Linux for development, but every other OS, which supports the normal
Unix-API should work too. And it is multithreaded for best performance.

You can find it at http://www.maekitalo.de/tntnet. I hope to add some
documentation soon.


Tommi