Re: [ZooLib-dev] CW8 Mac trouble

[Andrew G. <ag...@em...>]

Sorry I was away when this flurry of messages came in -- I was in the UK
and without regular access to the net. However I'm back home now.

I looked at the Pro 8 headers prior to the release and had anticipated
some problems with the various vector and string implementations that
the new MSL provides, but didn't actually do anything about it.

A quick workaround that will preserve the semantics ZooLib is expecting
from the STL -- define _MSL_RAW_ITERATORS in your project's .pch file
(or in zconfig.h for that matter). That will make all iterators be
typedefed pointers, just as they have been up till now.

We do have a problem with this recent change to MSL. In several places
ZooLib has APIs that take a pointer to an entity and a count. This style
of API allows one to use the same entry point to pass no entity at all
(nil pointer, zero count), a single entity (address of that entity,
count of one), or an arbitrary number (address of an entity in an array,
distance to the end of that array). With vector iterators being
typedefed pointers we're able to pass vector contents through the same
API. If vector iterators are real objects then we need an additional API
taking such  an iterator, that's easy. But if iterators sometimes are
and sometimes aren't typedefed pointers then we can't simply have this:
  void SomeAPI(vector<T>::iterator iStart, size_t iCount);
  void SomeAPI(T* iStart, size_t iCount);
because when typeeof(vector<T>::iterator) == typeof(T*) then we've got
two methods with identical signatures.

I think the real solution to this is to look at the problematic entry
points and determine which ones need the full generality and which
don't. The ones that always take vector iterators can just take vector
iterators. The ones that allow for pointers or iterators can be split
into two entry points thus:
  void SomeAPI(size_t iCount, vector<T>::iterator iStart);
  void SomeAPI(T* iStart, size_t iCount);
or
  void SomeAPI(vector<T>::iterator iStart, size_t iCount);
  void SomeAPI_Pointer(T* iStart, size_t iCount);
creating distinct signatures regardless of how vector iterators are
defined.

Note that this same issue applies to places which use strings -- and I
think there are a lot of them and it's been a real boon to be able to
treat string iterators and char*s interchangeably.

With regard to the CW SDK plugin API.

For the moment you might just download zac.hqx (binhexed binary) I put
in CVS (zoolib/tools/zac/zac-build-cw) earlier in July.

Slightly longer term, I need to put together the mac file implementation
that uses the FileRef-based APIs -- it's been on my list to do for a
while, but it hasn't been a high priority in my own work -- and then
we'll be able to convert between the revised CWFileSpec and ZFileSpec
properly.

A+

On 01 Jul 2002 07:46:15 +0200, Conrad Weyns wrote:
> Hi all,
> Installed my new CW v8 some days ago and in the process of updating projects.
> Just finished making changes to Whisper2 and thought I'd give zoolib a go.
> Working on zac right now.
> 
> >The current projects (I've only gotten as far as zac so far) won't 
> >compile as CVS-ed.
> >
> >MetroWerks has changed the STL part of MSL (see the release notes for 
> >the details.)  I spent a morning on this one in my company's product 
> >already this week.
> >In ZFileTrail::sTrailFromTo():
> >	if (matchUntil < iDest.size())
> >		theTrail.AppendTrail((iDest.begin() + matchUntil).base(), 
> >iDest.size() - matchUntil);
> >
> >Adding ".base()" fixes the problem, which seems to involve getting a 
> >pointer to data out of an iterator.  This shouldn't be necessary and the
> 
> AppendTrail requires a const string* as its first param.
> iDest is const vector of string, compiler seems happy with:
> 
>     theTrail.AppendTrail(&(*(iDest.begin() + matchUntil)), iDest.size() -
> matchUntil);
> 
> Alternatively, I try writing several lines when in doubt/trouble:
> 
> 		vector<string>::const_iterator it = iDest.begin();
> 		it += matchUntil;
> 		string tmp(*it);
> 		theTrail.AppendTrail(&tmp, iDest.size() - matchUntil);
> 
> (Actually, I am surprised this worked pre v8. Is there supposed to be an
> implicit conversion from a vector<string>::iterator to the string*, I
> would have thought that to be a reference only, but then I have to admit,
> the stl often baffles me, and particularly std::vector seems to have many
> different faces across stl implementations)
> 
> >Pro8 also seems to have tightened the rules about implicit casting (saw 
> >this at work too.)
> >Two errors are in ZASCompilerCW.cpp:
> >static ZFileSpec sFromCWFileSpec(const CWFileSpec& inSpec)
> >and
> >static CWFileSpec sFromZFileSpec(const ZFileSpec& inSpec)
> >Involve casting between ZFileLoc, CWFileSpec, and ZFileLoc_Mac_FSSpec.  
> 
> The Plug-In SDK has changed in CW v8. It seems to turn on the use of long
> file names now - allways. (Do a diff between the CWPlugins.h files of v7
> and v8)
> Casting is not possible anylonger between a CWFileSpec and an FSSpec when
> CWPLUGIN_LONG_FILENAME_SUPPORT is turned on, see CWPlugins.h:
> 
> 	#if CWPLUGIN_LONG_FILENAME_SUPPORT
> 
> 		#define CWPLUGIN_FILENAME_LEN 256
> 		typedef struct CWFileSpec 
> 		{ 
> 			FSRef 			parentDirRef;	/* parent directory			*/
> 			HFSUniStr255	filename;		/* unicode file name		*/
> 		} CWFileSpec;
> 
> 		typedef char			CWFileName[CWPLUGIN_FILENAME_LEN];
> 
> 	#else
> 
> 		#define CWPLUGIN_FILENAME_LEN 32
> 		typedef FSSpec			CWFileSpec;
> 		typedef char			CWFileName[CWPLUGIN_FILENAME_LEN];
> 
> 	#endif
> 
> Pre v8, CWFileSpec was typedefed to differ between Win and Mac only, now
> it allso caters for OS X where an FSSpec doesn't even come into it any more! 
> Zoolib will have to change. If you are using an old zac with cw v8, this
> may be why you get an unknown error.
> I'll give this some thought.
> 
> nb: none of my projects that make moderate use of templates and the stl
> made it through this upgrade without changes - so, once again, I have had
> to adjust my understanding of the language....
> 
> Cheers,
> Conrad Weyns.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ZooLib-dev mailing list
> Zoo...@li...
> https://lists.sourceforge.net/lists/listinfo/zoolib-dev
-- 
Andrew Green                           mailto:ag...@em...
Electric Magic Co.           Vox/Fax: +1 (408) 907 2101