Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!mcnc!uvaarpa!umd5!cvl!elsie!nih-csl!keith
From: keith@nih-csl.UUCP (keith gorlen)
Newsgroups: comp.lang.c++
Subject: Re: Strange behaviour with some OOPS SubStrings.
Message-ID: <310@nih-csl.UUCP>
Date: 25 Feb 88 18:42:40 GMT
References: <2100@cadnetix.COM>
Organization: NIH-CSL, Bethesda, MD
Lines: 57
Summary: This is a C++ bug.  Try defining SubString::operator==() and
	 String::operator==() out-of-line as a workaround.

In article <2100@cadnetix.COM>, gad@cadnetix.COM (Gordon Durand) writes:
-> I've run into an interesting problem when using OOPS Strings and
-> SubStrings, specifically the function SubString::operator==(const String&).
-> If I have a conditional which AND's two comparisons between strings and
-> substrings, I get the following:
-> 
-> 	CC  -DBOTCH StringBotch.C -loops:
-> 	...warning about a bitwise copy in String.h...
-> 	cc  StringBotch..c -loops -lC
-> 	"/usr/include/oops/String.h", line 42: redeclaration of _SubString__eq
-> 
-> If I break the AND into nested if statements, the problem goes away!
-> An example is included below, compiling with -DBOTCH causes problems.
-> 
-> Configuration info:	Sun 3/50 with SunOS 3.4, AT&T C++ 1.2.1,
-> 			OOPS Version 2 (installation notes dated 4/13/87)
-> 
-> Is this a problem with OOPS, C++, or my feeble mind?

-> ===================================================================
-> #include <oops/String.h>
-> 
-> main()
-> {
->    String Line ("byebye");
->    String Bye ("bye");
-> #ifdef BOTCH
->    if (Line (0, 3) == Bye && Line (3, 3) == Bye) {	// This will break.
->        printf ("Yup, Line was byebye\n");
->    }
-> #else  BOTCH
->    if (Line (0, 3) == Bye) {				// This is fine.
->       if (Line (3, 3) == Bye) {
->          printf ("Yup, Line was byebye\n");
->       }
->    }
-> #endif BOTCH
-> }
-> ===================================================================


This is a problem (almost by definition) with C++.  If you look at bug
CC#03 in the file bugs.1.2.1 in the OOPS distribution kit, you'll see
a description of a similar problem.

I believe that this bug will be fixed in the next release of C++.  As
a work-around, try changing the definitions of SubString::operator==()
and String::operator==() to be out-of-line instead of inline (I haven't
tried this yet -- let us know if it works).

Incidentally, Version 2 Release 2 of OOPS, which will be on the USENIX
C++ Tape, has a much improved String class.  It won't solve this
problem, however.
-- 
	Keith Gorlen			phone: (301) 496-5363
	Building 12A, Room 2017		uucp: uunet!ncifcrf.gov!nih-csl!keith
	National Institutes of Health	Internet: keith%nih-csl@ncifcrf.gov
	Bethesda, MD 20892