Hi,

I'm trying to implement a very simple c function call,

Here's the c function I'm using to test...  (It's in a file called test.cc)

int foo(int x)
{
  int y;
  y=x+1;
  return y;

The poplog file I have is...

exload test [libtest]
foo(x) :int
endexload;

I compile the test.cc file into a shared object library with the following commands...

g++ -c -fpic test.cc
g++ -shared -o libtest.so test.o

When I try to compile the poplog exload it complains

;;; Error: can't find value for symbol foo

;;; MISHAP - ERRORS ACCESSING EXTERNAL SYMBOLS (see above)
;;; FILE     :  /home/mhl/external/temp.p   LINE NUMBER:  3
;;; DOING    :  external_do_load exload runproc

I checked the symbols is the library and there's a 'foo_Fi' so I changed the poplog code to read...

exload test [libtest]
foo(x) :int <-'foo_Fi'
endexload;

which works fine. I noticed a section on symbol names in ref * external (line 856) which says that exload should automatically do the mapping. Does anyone know why this isn't the case here? Is it something to do with the method I'm using to compile library, or the fact that I'm using Linux?

Cheers

-- Mike

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

You have used the Gnu C++ compiler, not the C compiler which is gcc.
The man gcc file on my linux machine states:

       gcc    assumes preprocessed (.i) files are C and assumes C
              style linking.

       g++    assumes preprocessed (.i) files are C++ and assumes
              C++ style linking.

       Suffixes of source file names indicate  the  language  and
       kind of processing to be done:

       .c    C source; preprocess, compile, assemble
       .C    C++ source; preprocess, compile, assemble
       .cc   C++ source; preprocess, compile, assemble
       .cxx  C++ source; preprocess, compile, assemble

So you should use .c as the file suffix if you intend the program to
compiled and linked as if it were a C program.

That assumes that you are using C, not C++

Try again after re-naming your file test.c

    gcc -c -fpic test.c
    gcc -shared -o libtest.so test.o

    exload test [libtest]
        (language C)
        foo(x) :int
    endexload;

    exacc foo(33) =>
    ** 44

(I never use C. I have just copied stuff from examples in REF EXTERNAL)

I hope that helps.

There are many examples of external function calls in the Pop-11 X
libraries in here:

    $usepop/pop/x/pop/*/*.p

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html

(Aaron Sloman See text for reply address) said:

(snip)

Obviously this is best if you are writing a C program, but if you
really do need C++, you can tell the compiler to use C style linking
for the functions you wish to import into poplog. For example, you
can declare foo in a header file thus:

extern "C" int foo(int x);

and then you can compile the .cc file as C++.

--
Jonathan L Cunningham

I do need C++ so this is useful thanks. I know this may be wishful
thinking but I'm hoping to return a class instance from C++ to poplog
would this be at all possible? Has anyone ever tried it?

Thanks

--
Mike

http://www.cs.nott.ac.uk/~mhl/

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

I have never used C++ but I have been told that the only way to get
pop-11 to communicate with C++ is via C.

So if you can get C to interpret a C++ instance as a C
datastructure, then tell Pop-11 what sort of object it is, then
you can perhaps do what you want -- maybe, depending on what you
want Pop-11 to do with the instance.

Storing it somewhere is one thing (see REF EXTERNAL_DATA).

Attempting to invoke C++ methods from pop-11 is probably out of the
question. As far as I know nobody has implemented an interface
between Pop-11 and C++ and I have been told it would be extremely
difficult to do.

So you'll probably have to use C procedures to provide the
interface.

If you come up with a generalisable solution, it may be worth
documenting and adding the information to the poplog web site.

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html

(Aaron Sloman See text for reply address) said:

I haven't tried this either, but from general knowledge of how
things work ...

It really does depend what you want to do with it. If you just want
to return a pointer to the C++ object to poplog, which you will then
pass back to some other C++ object later, that should be no
different than handling any other C pointer.

If you want to store a C++ object as a poplog object, you could do
that easily enough, but I can see no reason why you would want to. Far
simpler to store it as a C++ object, and just pass a pointer to it
into poplog.

I expect it would be simple to do, but a bad idea. It is not defined
in the C++ language, but all C++ compilers that I know of implement
non-static member functions (methods) by passing one extra argument
to the function, which is given the name "this". The difficulty would
be in knowing the link name of the underlying C function corresponding
to the C++ member function, which also is not defined in the standard,
and can vary from compiler to compiler. (And also whether the extra
argument goes in front of or after the declared arguments -- probably
in front, I should think, to allow for functions which take a variable
number of arguments.)

If you have virtual member functions, then you need to access them via
the class's virtual function table: there will be a pointer to this
in the instance object, but exactly where would again be compiler
dependent.

Which all leads to the conclusion ...

 ... as Aaron says.

I think it would depend on what you wanted to do, and how efficient
you needed it. For example, if 99.9% of your processing is within
poplog and/or within C++, with relatively rare communication between
them, then you don't care about efficiency, only clarity and ease
of use.

There *are* general standards for this kind of thing: search for
keywords like ORB, IIOP, CORBA, IDL etc. on the Internet. Maybe the
best way for poplog to do this would be to implement an interface
to something of that ilk.

I have a slight prejudice against CORBA, so I haven't been following
how successful (as a standard) it has become. But I'm
not aware of any alternative standard either (I don't count anything
that Microsoft does as an alternative standard).

--
Jonathan L Cunningham