c++ as scripting language

[balajee]

Hi,
I am new bee to C++. Basically I am TCL pogrammer, write scripts to
automate interactive applications such as telnet,ftpetc. Can we use C+
+ also for the same purpose? as scripting language for above
applications?

 

[balajee]

C++ is not a scripting language. It is a compiled language.

Perhaps you mean if you use C++ to control external programs, like TCL does.
Yes, you'll just have to do everything that TCL does: fork and run the
external program as a child process, read and write to the external programs
standard input and output accordingly, etc.

 application_pgp-signature_part
< 1KViewDownload

HI,
Thanks for the reply. I am not able to open your attachment. I just
want to write telnet application using c++. Can you guide me on how to
do this? I know C++ basics.

Thanks,
Balajee

 

[Michael Doubez]

C++ is not a scripting language. It is a compiled language.

It is not.
An interpreter engine does exists:
http://root.cern.ch/drupal/content/cint

[snip]

 

[Fred Zwarts]

It is not.
An interpreter engine does exists:
http://root.cern.ch/drupal/content/cint

The C++ language is not by definition a compiled language.
But CINT is a bad example. It is not really C++.
Scoping rules, catching exceptions, dynamic_cast, amongst others,
are all very different from the C++ rules.

 

[BGB / cr88192]

Hi,
I am new bee to C++. Basically I am TCL pogrammer, write scripts to
automate interactive applications such as telnet,ftpetc. Can we use C+
+ also for the same purpose? as scripting language for above
applications?

another person has mentioned CINT, which is, sadly, the best I know of as
far as scripting in C++ goes...

I think LLVM / CLang was also working on C++ support, but am not at present
sure of their current status.


granted, the task is much easier if one is willing to live with C, given
there are several different options as far as C interpretation and dynamic
compilation goes.

LLVM / CLang;
TinyC;
CINT (again);
....

I am also using C as a scripting language (via a custom written VM-ish
framework).
I don't support C++ as it is horridly complicated (vs C), and don't
personally have the motivation or resources to beat together an
implementation (unless maybe it were an extreme subset, I had looked briefly
at EC++ in the past).
I may eventually have Java and others added to the mix, but not much can be
said here at the moment (Java support is woefully incomplete).


of course, if you are talking about using it for scripting an already
existing app, well, that is a bit more of an issue, as then one is usually
limited to whatever language(s) the app already supports.

 

[Michael DOUBEZ]

Le 29/12/2009 17:31, Fred Zwarts a écrit :

The C++ language is not by definition a compiled language.
But CINT is a bad example.

But it is the only interpreter I know of.

It is not really C++.
Scoping rules, catching exceptions, dynamic_cast, amongst others,
are all very different from the C++ rules.

Brand new version 7 is a bit better in this regard. But if I have read
correctly, they may switch to LLVM.

 

[BGB / cr88192]

<--

Le 29/12/2009 17:31, Fred Zwarts a écrit :

But it is the only interpreter I know of.

It may be an interpreter of something, but unless it is capable of accepting
any syntactically valid C++ source, and "interpreting" it to produce the
same results as if it were compiled, then it cannot be accurately described
as a C++ interpreter.
-->

granted, but AFAIK it may be close enough, nevermind missing features and
slight differences...

for example, what does it matter that much, if for example, "foo.bar" and
"foo->bar" are equivalent, ...
what if say, 95% of the time, things work, but in those 5% of edge cases,
fails miserably?...

likely, it just can't claim standards conformance is all.


it would be like, say, if you had someone who was not very good with
English, but most of the time were understood and understood what was being
said, but every so often would have notable grammer errors, not make sense,
or fail to understand well-formed statements.

do we say then that they can't speak English?... no, we usually just say it
isn't very good at it.

the reasonable cutoff then is when it is clearly different, and most or all
input fails to work.

German is not English, Spanish is not English, and Chinese is not English.
put them together, and neither side knows what is being said by the other.

Chinese-English is still English, even if often broken or incoherent, none
the less it is English, just not good English...

"watch where step, the slipery is decieving...".


programming is likely much the same way.

 

[Michael Doubez]

It may be an interpreter of something, but unless it is capable of accepting
any syntactically valid C++ source, and "interpreting" it to produce the
same results as if it were compiled, then it cannot be accurately described
as a C++ interpreter.

A standard C++ interpreter may not be the goal of CINT developers.

In the standard, the term 'compilation unit' is used but not defined;
and I suspect it is used as a synonym of 'translation unit' which *is*
defined. If you define 'compiled language' has 'without translation',
you are right but nowadays most interpreted languages use JIT and
nothing prevents from doing the same with c++.

 

[Fred Zwarts]

<--


It may be an interpreter of something, but unless it is capable of
accepting any syntactically valid C++ source, and "interpreting" it
to produce the same results as if it were compiled, then it cannot be
accurately described as a C++ interpreter.
-->

granted, but AFAIK it may be close enough, nevermind missing features
and slight differences...

for example, what does it matter that much, if for example, "foo.bar"
and "foo->bar" are equivalent, ...
what if say, 95% of the time, things work, but in those 5% of edge
cases, fails miserably?...

I think scoping rules are essential. It may be less then 1% of the rules,
but if destructors are not called at the end of the scope,
if const variables can be redefined within scope to be non-const,
then a very essential part of C++ is missing.

 

[Rolf Magnus]

for example, what does it matter that much, if for example, "foo.bar" and
"foo->bar" are equivalent, ...

How does it know if you want to access a member of an object or use its
operator->, e.g. when using std::auto_ptr?

what if say, 95% of the time, things work, but in those 5% of edge cases,
fails miserably?...

If it's supposed to be useful as a C++ interpreter, it must work with most
existing code (libraries) without the need to heavily modify it first. Is
that the case?

it would be like, say, if you had someone who was not very good with
English, but most of the time were understood and understood what was
being said, but every so often would have notable grammer errors, not make
sense, or fail to understand well-formed statements.

do we say then that they can't speak English?... no, we usually just say
it isn't very good at it.

Spoken languages and programming languages can't really be compared that
way.

 

[Robert Hairgrove]

It is not.
An interpreter engine does exists:
http://root.cern.ch/drupal/content/cint

How does this "interpreter" handle templates, for example?

Any language will eventually need to be translated into some kind of
pseudo-code or byte code (even if interpreted) or else into machine
language, if it is to be executed at all. Machines can only understand
machine language. This applies to C++ as well as Java or (shudder)
Visual Basic.

There is no denying that some small subset of C++ could be interpreted
and executed at runtime instead of first compiled and then the resulting
file run as an executable. However, all but toy programs have to deal
with issues such as memory management, variable scope, namespaces,
pointers, exceptions, etc. which cannot be resolved at runtime, but need
to be dealt with at compile time. An interpreter cannot do this IMHO.

 

[James Kanze]

Michael Doubez wrote:

[...]

Any language will eventually need to be translated into some kind of
pseudo-code or byte code (even if interpreted) or else into machine
language, if it is to be executed at all. Machines can only understand
machine language. This applies to C++ as well as Java or (shudder)
Visual Basic.

Yes, but the interpreter can interpret a textual representation
without converting it into an itermediate format. I'm not
saying that it's a good solution, but I've used one or two that
worked that way.

There is no denying that some small subset of C++ could be
interpreted and executed at runtime instead of first compiled
and then the resulting file run as an executable. However, all
but toy programs have to deal with issues such as memory
management, variable scope, namespaces, pointers, exceptions,
etc. which cannot be resolved at runtime, but need to be dealt
with at compile time. An interpreter cannot do this IMHO.

Sure it can. Some of these, like memory management, are purely
runtime. Things like lexical scope are considerably trickier,
but they can be done.

 

[balajee]

Hi,
Thanks for deep discussion. I am trying to move this thread towards
closing my needs. My requirement is - We have standard automation
framework which runs on TCL. These automation scripts connect to test
devices(our own platforms), execute few commands, fetch the output and
compare with standrd format to cross check everything is perfect. I
just want to know whether same thing can be done using C or C++.
Because of some internal reasons, we decided to not to use TCL or
PERL. We are just evaluating other options. Any suggessions are
welcome. Thanks in advance.

Thanks,
Balajee

 

[BGB / cr88192]

How does it know if you want to access a member of an object or use its
operator->, e.g. when using std::auto_ptr?

dunno, I have not looked into CINT that much personally...

If it's supposed to be useful as a C++ interpreter, it must work with most
existing code (libraries) without the need to heavily modify it first. Is
that the case?

I can't say personally, but presumably it works "well enough" otherwise most
would have not have concluded that it "works" to begin with...

typically though, for something like this, it is passable if most things at
least parse quietly enough, even if not everything works right, as one could
use precompiled libraries and gloss over the rest?...

granted, I can't say I have personally used it, so I don't really know how
well it works in practice.

Spoken languages and programming languages can't really be compared that
way.

I have heard "all or nothing" complaints enough in the past, but in my
experience it rarely is as drastic as people tend to make it out to be.


it is much like buggy code:
one would think it "all or nothing" if code contained bugs;
possibly it does, but if no one steps on them, then they don't pose a
problem.

granted, maybe one does step on one, and it is a grenade that blows their
leg off...
well, it is a bug, but if it works most of the time, well then, it works
most of the time.

approximate implementations very often work, approximately.
there is a lot that can be glossed over.


for example, I have an x86 interpreter which works well enough in my tests
even though:
many parts of the ISA are either not faked entirely, or are absent;
many core parts of the interpreter are drastically different than its
real-life CPU counterpart...

thing doesn't even have correctly working segmentation support, or at this
point, even paged memory (it instead uses "spans-based" memory, which is
made to "sort of resemble" paged memory).

as well, many flags in "eflags" don't work, many instructions are missing,
....

yet, the simulated processes don't seem to notice (me generally running code
compiled with GCC on the thing), as none have stepped on any of these
landmines (I would do, as most of these edge cases are rigged up to generate
an immediate simulated #UD or #GP if encountered...).


(oh yes, and this is the same x86 interpreter which I noted elsewhere, has
some of the logic in several places driven by string-processing magic, such
as the main instruction decoder...).


so, who knows...

 

[nick]

Hi,
   Thanks for deep discussion. I am trying to move this thread towards
closing my needs. My requirement is - We have standard automation
framework which runs on TCL. These automation scripts connect to test
devices(our own platforms), execute few commands, fetch the output and
compare with standrd format to cross check everything is perfect. I
just want to know whether same thing can be done using C or C++.
Because of some internal reasons, we decided to not to use TCL or
PERL. We are just evaluating other options. Any suggessions are
welcome. Thanks in advance.

Thanks,
Balajee

So you want your program to run other programs, interpret the output
and do stuff based on that, right? Yes, it can be done - take a look
at the 'system' function from cstdlib, or check out the first two
posts in this thread of OS-specific implementations: http://www.gidforums.com/t-3369.html

You're probably better off sticking with a scripting language for this
kind of thing, though. As long as you are exploring options, maybe try
using a batch or shell script or a different scripting language. If
TCL and perl are out, lua might be worth consideration.

-- Nick

 

[BGB / cr88192]

Michael Doubez wrote:
[...]
Any language will eventually need to be translated into some kind of
pseudo-code or byte code (even if interpreted) or else into machine
language, if it is to be executed at all. Machines can only understand
machine language. This applies to C++ as well as Java or (shudder)
Visual Basic.

Yes, but the interpreter can interpret a textual representation
without converting it into an itermediate format. I'm not
saying that it's a good solution, but I've used one or two that
worked that way.

yes...

and I know of a very trivial example:
using characters to directly drive the logic code behind such an
interpreter.

for example, the interpreter can be a sort of state machine, where each
character is dispatched via a switch and potentially either mutates state,
or switches to an alternate character dispatch loop, such that "parsing" and
"execution" are equivalent.

granted, this tends not to result in exactly "human readable" code (unless
one likes gobeledygook...), but allows for very simple, as well as
relatively fast, interpreters.


examples of where I have used this type of thing:
generating machine code (in my assembler);
driving instruction decoding (in my x86 interpreter, which uses the same
strings as the assembler);
generating special ASM fragments (various places, where I have both command
strings and FSM's (Finite State Machine) to convert these into ASM, to be
fed into the assembler);
....

another example:
I had used it before in basic genetic-programming tests, mostly as it had
allowed me to directly see the algos the GP evolver was devising, and
allowed allmost bytecode-like execution speeds.

granted, one would not design a general-purpose programming language this
way, or likely even attempt to implement a general-purpose compiler as a big
mass of FSM's...

Sure it can. Some of these, like memory management, are purely
runtime. Things like lexical scope are considerably trickier,
but they can be done.

yeah...

there is lots which can be done at runtime, and infact, many tasks are much
easier at runtime than compile time...

we just like compile-time, as it is usually faster...


anyways, namespaces and scope are hardly a problem for runtime resolution.
Lisp and Scheme have been doing lexical scoping (at runtime) for decades;
similarly, pretty much all JavaScript interpreters can do lexical scoping.
this is not the problem...

actually, there would not seem to be anything in that list which would
likely, actually, pose a problem for an interpreter.

(that or the Scheme REPL is actually just some sort of mass delusion, and
lambda's don't really exist...).


granted, if the comment were something like:
an interpreter can't really (directly) make use of statically compiled
classes and methods, I would be more inclined to agree.

it is bridging the gap between statically compiled machine code, and
high-level logic and interpretation, which is where most of the nastiness
lies...

(granted, even this can be addressed, granted it involves digging solutions
out of an "evil bag of horrors"...).


the big challenge for the average C or C++ programmer:
if given a textual string declaring a function to be called, and the
arguments to pass to it, how will you accomplish calling this function
without hard-coding any information about the function(s) to be called (the
only information available is what can be gained from standard OS API's, or
from reading in the source files).

(IOW: "if(!strcmp(name, "foo")) foo(atoi(arg1), ...);", ..., is an instant
fail).

now, consider this moment...
now, consider expanding it to support arbitrary expressions, functions,
entire compilation units, ...

can this be done? yes...
the question is to consider how to approach this.

 

[Jorgen Grahn]

[the messed up formatting is not my fault /grahn]

.

balajee writes:
....

This is not something that can be described in a few paragraphs, but if a=
ll=20
you're trying to do is emulate telnet, you don't need to script telnet at=20
all. All that telnet does is create a socket and connect to the server. Y=
ou=20
can do that yourself, without involving telnet.

Not true. Telnet is not netcat(1); it's an ancient protocol (predating
TCP, IIRC) with all kinds of quirks which few people understand.

On the other hand, I kind of doubt that balajee *really* wants to
implement the telnet protocol. He means something else. My *guess* is
that just he wants to have expect-like control over a remote terminal,
regardless of whether the protocol is telnet, rlogin, rsh or (the sane
choice) ssh.

(If he chooses anything but the antiquated telnet, he may not even
need expect. Rsh and ssh can pass a command-line to the remote shell;
I've seen plenty of people even in recent years not realize that and
write expect scripts around telnet instead.)

Back ontopic ... I don't know if there is a decent expect-like library
for C or C++. I dislike Tcl, but I turn to Python (and its pexpect
module) for such tasks. This is not an area where C++ shines.

/Jorgen

 

[Nick Keighley]

   Thanks for deep discussion. I am trying to move this thread towards
closing my needs. My requirement is - We have standard automation
framework which runs on TCL. These automation scripts connect to test
devices(our own platforms), execute few commands, fetch the output and
compare with standrd format to cross check everything is perfect.

If TCL does the job why mess with it?

I
just want to know whether same thing can be done using C or C++.

It *could* be done just as you can remove screws with a chisel. C++ is
a fairly "big" compiled language. It is not well suited to "script-
like" tasks. You could of course use C++ to implement your own
automation script language...

Because of some internal reasons,

sounds about as much fun as internal bleeding. What is an "internal
reason"? Is TCL too slow? Too expensive? Not available on a required
platform? Or just too uncool? (I don't even *like* tcl but dropping
something that works seems odd).

we decided to not to use TCL or PERL.

darn my second choice.

We are just evaluating other options. Any suggessions are
welcome. Thanks in advance.

bash? scheme (I've written scripts in chicken scheme), python, ruby
(maybe)

 

[Miles Bader]

Thanks for deep discussion. I am trying to move this thread towards
closing my needs. My requirement is - We have standard automation
framework which runs on TCL. These automation scripts connect to test
devices(our own platforms), execute few commands, fetch the output and
compare with standrd format to cross check everything is perfect. I
just want to know whether same thing can be done using C or C++.
Because of some internal reasons, we decided to not to use TCL or
PERL. We are just evaluating other options. Any suggessions are
welcome. Thanks in advance.

Perhaps Lua. It's basically designed to be an embedded/extension
language, and does it extremely well -- it's faster, smaller, more
elegant, easier to interface with, and just generally nicer than most of
its competitors.

http://www.lua.org/

-Miles