From jc@psyc.nott.ac.uk Mon Mar 14 19:02:38 1994
Received: from ben.Britain.EU.net by swi.psy.uva.nl with SMTP id AA10441
  (5.65c/IDA-1.4.4/SWI-1.1m for <jan@swi.psy.uva.nl>); Mon, 14 Mar 1994 19:02:27 +0100
Message-Id: <199403141802.AA10441@swi.psy.uva.nl>
Received: from psyc.nott.ac.uk by ben.britain.eu.net via JANET with NIFTP (PP) 
          id <sg.20868-0@ben.britain.eu.net>; Mon, 14 Mar 1994 16:59:03 +0000
Date: Mon, 14 Mar 94 16:57:30 GMT
From: James Cupit <jc@psyc.nott.ac.uk>
To: jan@swi.psy.uva.nl
Subject: C++ / XPCE interface..
Status: REO

Hi,

I've been using the C++ interface quite extensively over the past week
and find it very intuitive and highly usable from both a C++ and XPCE
point of view...  The only problems I've come across (apart from the
n.store() bug I've already reported) result from the usage of PceCell.
These aren't bugs as such but a bit more documentation might not come
amiss ....

When using the PceChain class (to get at ch.head), I've found it
essential to use AsChain() to avoid type conversion problems when
passing arguments..  The AsObject() construct isn't mentioned in the
manual at all.  A good example of the problems incurred by not using
this is included below.

Secondly, it might be worth pointing out that when using PceCell, one has
to be careful about the looping construct employed (not an obvious point for
people who have never used linked lists outside of, say, LISP.)

eg.  PceCell c = ch.head();
	
    for (; c; c++)
	ch.send("delete", c);

will obviously cause problems as c becomes the next cell through
the delete call. IE. the code above should be...

   for (; c; c= ch.head())
   	     ch.send("delete", c);


Thirdly, if you don't call the compiled program with

unix_prompt% program &

I sometimes find the application loses it's event focus if I
inadvertently type something in the same shell (it regains the focus
after stopping it and then resuming it..).  Could cause some people to
worry ....

Finally (a minor gripe, not a problem), I would prefer it if the
inline AsObject functions in the include files were replaced with
compiler macro defintions.  Whilst the gcc linker is probably
intelligent enough not to include the used inline definitions in the
resultant binary file, the compiler warns me every time I include a
header file and don't call it.  The code obviously still compiles but
it looks a bit messy at compile time!!!

Cheer James.

----- Problems with type coersion when passing objects as arguments ---

#include <iostream.h>
#include <stdlib.h>
#include <pce/Pce.h>
#include <pce/Chain.h>

void print_chain_length(PceChain ch)
{
  cout << (char *)ch.get("size") << endl;
}

PceStatus pceInitApplication(int argc, char *argv[])
{
  PceChain ch;
  PceChain ch2(1, 2, 3);

  ch.send("append", ch2);
  print_chain_length(ch2);
  print_chain_length(ch.get("head"));
  print_chain_length(AsChain(ch.get("head")));
  exit(0);
}
  












