Re: [Gnucap-devel] [Child Process unable to receive input from a file(script)]

[al davis]

The answer to this may be of general interest so I am CCing it 
to the list.

On Friday 27 June 2014, Rishabh Yadav wrote:
> and how this conversion can be done so I can just replace
> command() with cmdproc() in the plugin's code.

The short answer to the question you ask is:

  CS my_cmd(CS::_STRING, my_string); 

Then pass on my_cmd where a CS is required.

Now to answer the question you should have asked .....

If you do this, or anything with an intermediate string, you 
lose the connection to the original input stream.  This is true 
with the C FILE* and C++ iostream also.

Passing a CS& through is common in gnucap.  & means by 
reference.  As you pass it through it keeps reading from the 
same file, the same CS object.  If you copy it instead, you 
would have two of them and each would not know what the other is 
doing.


You should not be converting back and forth.  All of the 
operations you need can be done directly on a CS object.

You should already be familiar with c++ input like this:

double x;
my_file >> x;

where my_file is a std::ifstream object.

The same works here, where my_file is a CS object.

my_file contains a status .. whether the last operation was good 
or bad, by treating it as a bool

if (x) {
        // it's good
}else{
        // it's bad
}

"bad" in this case means that whatever is there cannot be 
transferred to a double.

I could combine the read and test:

if (my_file >> x) {
        // it's good
}else{
        // it's bad
}

This works for all types for which the >> operator is defined.

The CS class has an extention for cases where x is a constant.  
With std::ifstream, you get a compile error if you do that.  
With CS, if x is a constant, the read is successful if what is 
in the stream matches the constant.

std::string x1;
my_file >> x1;

You know what that does.

char x2[200];
my_file >> x2;

That too.

But think of:

const char* x3 = "foo";
my_file >> x3;

Since you can't change x3, the operation is only successful if 
what is being read from the file would not change x3.  In this 
case it means the file must contain "foo" at that spot.

In all cases, if the read operation is not successful it does 
not advance the file pointer, so you can try again for something 
else.

if (cmd >> "elsif ") {
        // elsif part
        // the "elsif" has been consumed from cmd
}else if (cmd >> "else ") {
        // else part
        // the "else" has been consumed from cmd
}else{
        // don't have either of them
        // nothing has been consumed from cmd
}

Notice that I didn't put a blank in "foo", but I did put a blank 
in "else ".  A blank at the end matches a separator, usually 
whitespace.

So in the above case, looking for "foo", if the stream contains 
"foobar" it will match the "foo" and leave the pointer pointing 
at the b in bar.  If the code asked for "foo " instead (note the 
blank) it would not have read anything from an input of 
"foobar".

It's not a strcmp style string match.  It's more of a regular 
expression match.

What I have described here is a generalization.  What actually 
works is a matter of what types have a match for the >> 
operator.