delete[] template error

Started by
36 comments, last by EvilCrap 22 years, 1 month ago
man, ive been screwing with this error for liek a week. whenever i try to call the delete[], sometimes i get a critical error. *sometimes* being right after a call to delete[]. if i cant fix this error, then my entire class is useless! delete works the first time, in fStr1, but it fails the second time, in fStr2. heres my code! uncomment the destructor line to watch the error
    

#include <string.h>

#include <iostream>

#include <string>

using namespace std;


template<class myType>
class CfastString
{
	myType* _pStringStart;
	myType* _pStringEnd;

	void alignCopy(char* pCstr)
	{
		//align strlen(pCstr) to sizeof(myType)

		int length = strlen(pCstr);
		int alignedLength = (length + sizeof(myType) - length % sizeof(myType) ) / sizeof(myType);

		//set up pointers

		if( _pStringStart != NULL) delete[] _pStringStart;

		_pStringStart = new myType[alignedLength];
		_pStringEnd = _pStringStart + alignedLength;

		//set last sizeof(myType) bytes to NULL for safety

		_pStringStart[alignedLength-1] = 0;

		//copy to string

		strcpy((char*) _pStringStart, pCstr);	
	}

public:
	CfastString()
	{
		_pStringStart = NULL; _pStringEnd = NULL;
	}
	CfastString(char* pCstr)
	{
		_pStringStart = NULL; _pStringEnd = NULL;
		set(pCstr);
	}

	~CfastString()
	{
	//	delete[] _pStringStart;

	}
	
	void set(char* pCstr)
	{
		alignCopy(pCstr);
	}
	
	bool compare(CfastString fString)
	{
		myType* pString1 = _pStringStart;
		myType* pString2 = fString._pStringStart;
	
		while( pString1 != _pStringEnd)
		{
			if (*pString1 == *pString2) {
				*pString1++;
				*pString2++;
			}else
				return false;
		}
			return true;
	}

	char* pCstr()
	{
		return (char*)_pStringStart;
	}

};	//eoc CfastString


int main(int argc, char* argv[])
{
	CfastString<int> fStr1("nickkasdfa");
	CfastString<int> fStr2("nickkasdfa");

	//compare works

	if (fStr1.compare (fStr2) ) 
		cout << "same\n";
	else
		cout << "not same\n";

	//pCstr works

	cout << fStr1.pCstr() << endl;
	cout << fStr2.pCstr() << endl;

	cin.get();
	
	return 0;
}


    
Edited by - evilcrap on February 18, 2002 4:21:00 PM
Advertisement
I don''t plan on reading or debugging your entire code sample, but you are doing something really quite strange that I spotted. Right at the top of your program you have:

#include &ltstring>#include &ltstring.h> 

You then go on to disregard any functionality in the &ltstring> header. Why? Get rid of &ltstring.h>, get rid of the c-string arrays, and use std::string. The class you have written is entirely redundant.

--
The Dilbert Principle: People are idiots.
  1. Why do you include both <string> and <string.h> if you''re not going to use std::string methods?

  2. Why do you allow for an integer based string? UNICODE? I''m just asking what the rationale is behind the decision, not bashing it.

  3. Will your compare method work on strings of basic template types?

  4. I think the error lies in the allocation and copy wrangling used to transfer char * data into other types. You might want to perform your own copy operations (seek through the string until you find ''\0'', ensuring the data is properly aligned).


I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
Oh, and your CfastString isn''t fast at all. It even includes function calls!

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!
omfg, please dont respond if you dont know what ur talking about.

string.h is for string ops on char*.
string is so i can write a std string set function, or template.

this unoptimized class is significantly faster than std string, which was the intention.

the compare works perfectly

quote:
I think the error lies in the allocation and copy wrangling used to transfer char * data into other types.

that may be, but my tests say otherwise.



anyone: please dont respond if you dont know what your talking about, or dont bother to actually skim the source.
what this class does is step through a CHAR ARRAY using a pointer to a larger type, like an int or double.
quote:Original post by EvilCrap
omfg, please dont respond if you dont know what ur talking about.

Who are you suggesting doesn't know what they are talking about?

quote:
string.h is for string ops on char*.

Yet, using char* strings is what's getting you into difficulties in the first place.

quote:
this unoptimized class is significantly faster than std string, which was the intention.


It's not faster than std::string as it doesn't even have the same functionality as std::string. You're comparing apples and oranges.

quote:
anyone: please dont respond if you dont know what your talking about, or dont bother to actually skim the source.


From where I'm sitting, it looks like you are the one in difficulty. I don't know where you're requirement for a "fast string" has come from, but you should only ever decide something is too slow when you have discovered a performance problem, profiled the application, and found that something to be the bottleneck. If you have done this, you could try investigating existing alternatives, such as vector&ltchar&gt.

--
The Dilbert Principle: People are idiots.


Edited by - SabreMan on February 18, 2002 1:52:48 PM
EvilCrap : I ran your code a 1000 times without any issue using gcc3.0.
It might just be a compiler bug on your side.



Gorg: did u uncomment the line in the destructor?
if u uncomment that line, the whole thing will go to hell.

SabreMan: give me a break. dont preach that trash to me, i know how to make programs. i want to write a fast string class cause i want to write a freakin fast string class. it may not have the functionality of std string cause its in development : its called unit testing, jackass.
quote:Original post by EvilCrap
SabreMan: give me a break. dont preach that trash to me, i know how to make programs.

And yet you''re making the very basic mistake of premature optimisation. Instead of concentrating on actually writing a program you are getting bogged down in the details of manual memory management.

quote:
i want to write a fast string class cause i want to write a freakin fast string class. it may not have the functionality of std string cause its in development : its called unit testing, jackass.

It''s your decision to waste your own time on this sort of futile pursuit, but when you go asking other people for help you would do well to tone down your arrogance and rudeness. Rather than learning through the experience of others, you are willingly committing yourself to repeat the same mistakes that have been made thousands of times before. It seems you cannot see further than your own ego.

--
The Dilbert Principle: People are idiots.

This topic is closed to new replies.

Advertisement