ccMail SMTPLINK Undeliverable Message

[ccMail SMTPLINK]

User ecarr is not defined

 Original text follows 
 ----------------------------------------------
Received: from gate1.dttus.com by cc4.dttus.com (SMTPLINK V2.11.01)
        ; Thu, 05 Dec 96 17:08:31 CST
Return-Path: <address@hidden>
Received: from sfi.santafe.edu by gate1.dttus.com (5.x/SMI-SVR4)
        id AA29301; Thu, 5 Dec 1996 17:01:07 -0600
Received: by sfi.santafe.edu (4.1/SMI-4.1)
        id AA13396; Thu, 5 Dec 96 15:51:48 MST
Date: Thu, 5 Dec 1996 16:50:56 -0600
From: address@hidden (Roger M. Burkhart)
Message-Id: <address@hidden>
To: address@hidden
Subject: Re: Set_c createEnd problem
Cc: address@hidden
X-Sun-Charset: US-ASCII
Sender: address@hidden
Precedence: bulk
Reply-To: address@hidden

Bohdan -- in response to your question about Set_c:

> I have been busily enhancing the space library for a GIS/MAS
> project, and wanted to use a Set type. Having located Set_c,
> I decide to use it ....
>
> Unfortunately, when I issue a createEnd during create-phase, I
> get a segmentation fault on my Solaris. I would like to know
> if this is a standard problem? OR better, can it be fixed?

Any name ending in _c is convention to mark an internal implementation
class in the defobj, collections, and activity libraries.  They aren't
intended to be referenced directly by an application at all; in effect
they're part of internal namespace that would be hidden entirely if it
could be (except for some supported use as superclasses).

In the case of Set, the name you should send createBegin: to is just
Set, not Set_c.  Set is a special "factory" object that is published
in the library header file (collections.h), which is the only header
file you should ordinarily include to use this library.  (Single header
files summarizing all the publicly visible interface are in process of
being established for additional libraries).  When you send createBegin:
to Set, it does not send the message to the compiled version of Set_c,
but to a different class generated to contain just the create phase
behavior.  That's most likely while you're crashing.  It's all part of
internal implementation machinery that a caller isn't supposed to have
to deal with.

Your code should work if you change it from:

>       Set_c * aSet;
> 
>       aSet = [Set_c createBegin: [self getZone]];
>       [aSet createEnd];

to:

        Set  aSet;
 
        aSet = [Set createBegin: [self getZone]];
        aSet = [aSet createEnd];   // aSet could be a new id, in some versions

This code, with no messages between createBegin/End, has the same effect as:

        Set  aSet;
 
        aSet = [Set create: [self getZone]];


Roger Burkhart