STL и MFC: выход за границы модуля и производительность

[Алексей++]

lapulya, вот ты сам и похоронил свою пламенную речь

...
замечено только одно место которое меня не устраивает, это передача объектов библиотеки через границу модуля и изменение этого объекта как раз в другом модуле
...

- а в MFC меня устраивает всё А шаблоны, как показала практика, не обязательны к применению

[lapulya]

Дело твое (но повторюсь зря ты это...). Ну а через границу модуля я просто гоняю или константные объекты или приведенные с стандартныому виду (ну типа char * вместо std::string)

[Алексей++]

lapulya, в другой модуль просто указатель , мне кажется, передать и нельзя - только весь буфер. Если ошибаюсь - то ошибаюсь ))

[lapulya]

Ну конечно ошибаешься, все модули работают в одном процессе => у них одно адресное пространство (ну это просто адресное пространство данного процесса), точнее что касается памяти у них все одинаково, поэтому передавая из модуля в модуль указатель на некую область памяти, получающий модуль совершенно запросто может читать и писать в память как по этому адресу, так и по любому другому ну ессесно в рамках дозволенного для данного процесса.

[Алексей++]

lapulya, ты же не уточнил, что у тебя за модули , я решил, что это именно разные процессы А в твоём случае можно, значит, даже нужно.  И с тем же CString это делается элементарно )

[lapulya]

CString насколько мне известно не имеет реализации мемборов в *.h файлах, так что с ним никаких проблем при грамотном использовании быть не может.

Если я еще не все забыл то между процессами никакие буферы передавать нельзя (низзззя лазить в адресное пространство "чужого" процесса) для передачи между ними есть другие инструмент и их не мало (на форуме сие ужо обсуждалось, могу найти ссылки если надо)

[Finch]

lapulya, Лазить можно, винда это позволяет. Конечно, это не совсем стандартные средства, но они сушествуют.

[Алексей++]

CString насколько мне известно не имеет реализации мемборов в *.h файлах

ещё как имеет. И h, и cpp

Если я еще не все забыл то между процессами никакие буферы передавать нельзя (низзззя лазить в адресное пространство "чужого" процесса) для передачи между ними есть другие инструмент и их не мало (на форуме сие ужо обсуждалось, могу найти ссылки если надо)

так я тебе это выше и говорил )

[Finch]

Алексей1153++, Скорее всего имелось ввиду такое:
CString.h

Код:

class CString
{
   ........
   int geLenght(void) {return lenght;}
   .........
};

[Алексей++]

Finch, в смысле ?

[Finch]

В самом описании класса описывается также и реализация функции. Как правило так описываются inline функции. Или шаблоные классы. Только я не совсем понимаю, почему это должно мешать в работе.

[Алексей++]

ничему это не помешает )

просто человек предвзято относится к MFC-классам

[lapulya]

Алексей1153++, это как раз мешает, потому что для использования любого сласса (пусть и того же CString) в в конкретном модуле необходим include хеадера как минимум в cpp файл реализации этого модуля И если в этом хеадере есть реализация какой-то функции перераспределяющей память, то труба! (тут как раз и есть засада с std::string) при вызове этой функции в "неродном" модуле (не там где был создан объект) произойдет вызов new "чужого" модуля и тут может произойти все что угодно, вот поэтому я и спросил имеет ли CString реализацию функций перераспределяющей память в хеадере. Скорее всего не имеет, а если имеет, то этот класс в данном аспекте ни чем не лучше std::string.

[Алексей++]

Алексей1153++, это как раз мешает, потому что для использования любого сласса (пусть и того же CString) в в конкретном модуле необходим include хеадера как минимум в cpp файл реализации этого модуля И если в этом хеадере есть реализация какой-то функции перераспределяющей память, то труба! (тут как раз и есть засада с std::string) при вызове этой функции в "неродном" модуле (не там где был создан объект) произойдет вызов new "чужого" модуля и тут может произойти все что угодно, вот поэтому я и спросил имеет ли CString реализацию функций перераспределяющей память в хеадере. Скорее всего не имеет, а если имеет, то этот класс в данном аспекте ни чем не лучше std::string.

ни разу с подобными проблемами не сталкивался - ни заголовки не включал специально, ни проблем с new не было А MFC люди не глупые писали - в "h"-файлах реализацию вроде нигде не писали

[Алексей++]

вот описание CString из заголовочного файла

Код:

class CString
{
public:
// Constructors

	// constructs empty CString
	CString();
	// copy constructor
	CString(const CString& stringSrc);
	// from a single character
	CString(TCHAR ch, int nRepeat = 1);
	// from an ANSI string (converts to TCHAR)
	CString(LPCSTR lpsz);
	// from a UNICODE string (converts to TCHAR)
	CString(LPCWSTR lpsz);
	// subset of characters from an ANSI string (converts to TCHAR)
	CString(LPCSTR lpch, int nLength);
	// subset of characters from a UNICODE string (converts to TCHAR)
	CString(LPCWSTR lpch, int nLength);
	// from unsigned characters
	CString(const unsigned char* psz);

// Attributes & Operations

	// get data length
	int GetLength() const;
	// TRUE if zero length
	BOOL IsEmpty() const;
	// clear contents to empty
	void Empty();

	// return single character at zero-based index
	TCHAR GetAt(int nIndex) const;
	// return single character at zero-based index
	TCHAR operator[](int nIndex) const;
	// set a single character at zero-based index
	void SetAt(int nIndex, TCHAR ch);
	// return pointer to const string
	operator LPCTSTR() const;

	// overloaded assignment

	// ref-counted copy from another CString
	const CString& operator=(const CString& stringSrc);
	// set string content to single character
	const CString& operator=(TCHAR ch);
#ifdef _UNICODE
	const CString& operator=(char ch);
#endif
	// copy string content from ANSI string (converts to TCHAR)
	const CString& operator=(LPCSTR lpsz);
	// copy string content from UNICODE string (converts to TCHAR)
	const CString& operator=(LPCWSTR lpsz);
	// copy string content from unsigned chars
	const CString& operator=(const unsigned char* psz);

	// string concatenation

	// concatenate from another CString
	const CString& operator+=(const CString& string);

	// concatenate a single character
	const CString& operator+=(TCHAR ch);
#ifdef _UNICODE
	// concatenate an ANSI character after converting it to TCHAR
	const CString& operator+=(char ch);
#endif
	// concatenate a UNICODE character after converting it to TCHAR
	const CString& operator+=(LPCTSTR lpsz);

	friend CString AFXAPI operator+(const CString& string1,
			const CString& string2);
	friend CString AFXAPI operator+(const CString& string, TCHAR ch);
	friend CString AFXAPI operator+(TCHAR ch, const CString& string);
#ifdef _UNICODE
	friend CString AFXAPI operator+(const CString& string, char ch);
	friend CString AFXAPI operator+(char ch, const CString& string);
#endif
	friend CString AFXAPI operator+(const CString& string, LPCTSTR lpsz);
	friend CString AFXAPI operator+(LPCTSTR lpsz, const CString& string);

	// string comparison

	// straight character comparison
	int Compare(LPCTSTR lpsz) const;
	// compare ignoring case
	int CompareNoCase(LPCTSTR lpsz) const;
	// NLS aware comparison, case sensitive
	int Collate(LPCTSTR lpsz) const;
	// NLS aware comparison, case insensitive
	int CollateNoCase(LPCTSTR lpsz) const;

	// simple sub-string extraction

	// return nCount characters starting at zero-based nFirst
	CString Mid(int nFirst, int nCount) const;
	// return all characters starting at zero-based nFirst
	CString Mid(int nFirst) const;
	// return first nCount characters in string
	CString Left(int nCount) const;
	// return nCount characters from end of string
	CString Right(int nCount) const;

	//  characters from beginning that are also in passed string
	CString SpanIncluding(LPCTSTR lpszCharSet) const;
	// characters from beginning that are not also in passed string
	CString SpanExcluding(LPCTSTR lpszCharSet) const;

	// upper/lower/reverse conversion

	// NLS aware conversion to uppercase
	void MakeUpper();
	// NLS aware conversion to lowercase
	void MakeLower();
	// reverse string right-to-left
	void MakeReverse();

	// trimming whitespace (either side)

	// remove whitespace starting from right edge
	void TrimRight();
	// remove whitespace starting from left side
	void TrimLeft();

	// trimming anything (either side)

	// remove continuous occurrences of chTarget starting from right
	void TrimRight(TCHAR chTarget);
	// remove continuous occcurrences of characters in passed string,
	// starting from right
	void TrimRight(LPCTSTR lpszTargets);
	// remove continuous occurrences of chTarget starting from left
	void TrimLeft(TCHAR chTarget);
	// remove continuous occcurrences of characters in
	// passed string, starting from left
	void TrimLeft(LPCTSTR lpszTargets);

	// advanced manipulation

	// replace occurrences of chOld with chNew
	int Replace(TCHAR chOld, TCHAR chNew);
	// replace occurrences of substring lpszOld with lpszNew;
	// empty lpszNew removes instances of lpszOld
	int Replace(LPCTSTR lpszOld, LPCTSTR lpszNew);
	// remove occurrences of chRemove
	int Remove(TCHAR chRemove);
	// insert character at zero-based index; concatenates
	// if index is past end of string
	int Insert(int nIndex, TCHAR ch);
	// insert substring at zero-based index; concatenates
	// if index is past end of string
	int Insert(int nIndex, LPCTSTR pstr);
	// delete nCount characters starting at zero-based index
	int Delete(int nIndex, int nCount = 1);

	// searching

	// find character starting at left, -1 if not found
	int Find(TCHAR ch) const;
	// find character starting at right
	int ReverseFind(TCHAR ch) const;
	// find character starting at zero-based index and going right
	int Find(TCHAR ch, int nStart) const;
	// find first instance of any character in passed string
	int FindOneOf(LPCTSTR lpszCharSet) const;
	// find first instance of substring
	int Find(LPCTSTR lpszSub) const;
	// find first instance of substring starting at zero-based index
	int Find(LPCTSTR lpszSub, int nStart) const;

	// simple formatting

	// printf-like formatting using passed string
	void AFX_CDECL Format(LPCTSTR lpszFormat, ...);
	// printf-like formatting using referenced string resource
	void AFX_CDECL Format(UINT nFormatID, ...);
	// printf-like formatting using variable arguments parameter
	void FormatV(LPCTSTR lpszFormat, va_list argList);

	// formatting for localization (uses FormatMessage API)

	// format using FormatMessage API on passed string
	void AFX_CDECL FormatMessage(LPCTSTR lpszFormat, ...);
	// format using FormatMessage API on referenced string resource
	void AFX_CDECL FormatMessage(UINT nFormatID, ...);

	// input and output
#ifdef _DEBUG
	friend CDumpContext& AFXAPI operator<<(CDumpContext& dc,
				const CString& string);
#endif
	friend CArchive& AFXAPI operator<<(CArchive& ar, const CString& string);
	friend CArchive& AFXAPI operator>>(CArchive& ar, CString& string);

	// load from string resource
	BOOL LoadString(UINT nID);

#ifndef _UNICODE
	// ANSI <-> OEM support (convert string in place)

	// convert string from ANSI to OEM in-place
	void AnsiToOem();
	// convert string from OEM to ANSI in-place
	void OemToAnsi();
#endif

#ifndef _AFX_NO_BSTR_SUPPORT
	// OLE BSTR support (use for OLE automation)

	// return a BSTR initialized with this CString's data
	BSTR AllocSysString() const;
	// reallocates the passed BSTR, copies content of this CString to it
	BSTR SetSysString(BSTR* pbstr) const;
#endif

	// Access to string implementation buffer as "C" character array

	// get pointer to modifiable buffer at least as long as nMinBufLength
	LPTSTR GetBuffer(int nMinBufLength);
	// release buffer, setting length to nNewLength (or to first nul if -1)
	void ReleaseBuffer(int nNewLength = -1);
	// get pointer to modifiable buffer exactly as long as nNewLength
	LPTSTR GetBufferSetLength(int nNewLength);
	// release memory allocated to but unused by string
	void FreeExtra();

	// Use LockBuffer/UnlockBuffer to turn refcounting off

	// turn refcounting back on
	LPTSTR LockBuffer();
	// turn refcounting off
	void UnlockBuffer();

// Implementation
public:
	~CString();
	int GetAllocLength() const;

protected:
	LPTSTR m_pchData;   // pointer to ref counted string data

	// implementation helpers
	CStringData* GetData() const;
	void Init();
	void AllocCopy(CString& dest, int nCopyLen, int nCopyIndex, int nExtraLen) const;
	void AllocBuffer(int nLen);
	void AssignCopy(int nSrcLen, LPCTSTR lpszSrcData);
	void ConcatCopy(int nSrc1Len, LPCTSTR lpszSrc1Data, int nSrc2Len, LPCTSTR lpszSrc2Data);
	void ConcatInPlace(int nSrcLen, LPCTSTR lpszSrcData);
	void CopyBeforeWrite();
	void AllocBeforeWrite(int nLen);
	void Release();
	static void PASCAL Release(CStringData* pData);
	static int PASCAL SafeStrlen(LPCTSTR lpsz);
	static void FASTCALL FreeData(CStringData* pData);
}

[lapulya]

Алексей1153++, вот смотри я говорил

Цитата: lapulya от Вчера в 19:21

CString насколько мне известно не имеет реализации мемборов в *.h файлах

ты отвечал

ещё как имеет. И h, и cpp

а теперь пишешь

А MFC люди не глупые писали - в "h"-файлах реализацию вроде нигде не писали

Ну как же можно конструктивно вести дискуссию... Ну ладно скорее всего просто ты это пропустил, хотя все мои дальнейшие рассуждения были уже направлены на использование твоего мнения как эксперта по MFC (я так понимаю тут лучше тебя его никто не знает).

Ну а раз реализации в хеадере нет, то и проблем при передаче объекта через границу модуля нет (поэтому ты с ними и не сталкивался).

[Алексей++]

lapulya, а в чём противоречие то ?

я понял в таком смысле , что ты говоришь так - "нет реализации в файлах, есть где то в длл (например)" , поэтому так написал

и я вовсе не экперт MFC , Джон, например - вот это действительно эксперт

и всё равно не понятно, как связны такие вещи, как:
1) где находится реализация
2) возможность передачи указателя (ну или сразу тела объекта)

?

[lapulya]

Если класс имеет реализацию функций в хеадере И эта реализация перераспределяет память (ну там буфер увеличивает, типа старый маленький освобождает, а новый большой выделяет), то тут таятся большие грабли. Вчем собственно грабли - для использования объекта этого класса в другом модуле (например, в другой dll), необходимо как минимум в cpp файле этого "другого модуля (для определенности назовем его dll)" сделать includ хеадера описывающего этот класс (ну тут все я сно - хотим в реализации dll использовать объект какого-то класса, для определенности пусть будет CString, значит нужен инклуд хеадера, в котором описан класс CString). Далее - если в cpp файла этой dll у объекта типа CString идет вызов той самой функции, которая перераспределяет память И (не забываем) эта функция имеет реализацию в хеадере, то понятное дело что произойдет вызов и delete и new определенных в dll (при компоновке dll вся реализация кода этой dll, естественно включая реализацию всех функций описанных в хеадерах, которые инклудятся в dll - будет своя!!!!).

И что же в итоге мы имеем, а то что буфер у объекта CString был изначально создан в первом модуле (для определенности в exe), потом сам объект был передан через границу модуля в dll, там (уже в dll) этот буфер освобождается (при вызове функции перераспределяющей память, при этом отрабатывает delete dll) и вуаля.... ЖОПА!!! Ну а дальше она просто усугубится поскольку новый буфер быделяется new из dll, а потом освобождается delete в exe. На самом деле уже первая жопа потенциально форматирует винт.

[Алексей++]

lapulya, возможно, я просто тупой, но я так и не понял твоей проблемы. Во первых - не делай в хедере реализаций , во вторых - не делай выделение и удаление в разных местах, и будет щастье
Указатель обычно передают не для того, чтоб там где то удалить буфер, на который указатель указывает, а чтобы этот буфер скопировать

[lapulya]

проблема в том что stl имеет всю реализацию внутри хеадера и при передаче неконстантного объекта через границу модуля (и изменения этого объекта в чужем модуле) будут проблемы.

А у меня проблемы нет, я только объяснял вот это

Ну а через границу модуля я просто гоняю или константные объекты или приведенные с стандартныому виду (ну типа char * вместо std::string)

Кстати, указатель передают, чтобы с буфером поработать (т.е. и читать и писать, но не меняя его размеров, да и то не факт...), а вот константный буфер передают как раз только для чтения.

[Алексей++]

lapulya, я же объяснял, что объект я тут же удаляю

[lapulya]

да какая разница. Если память хоть раз была выделена в одном модуле, а потом в другом освобождена, все )))) винт отформатирован ))))))

[Алексей++]

Если память хоть раз была выделена в одном модуле, а потом в другом освобождена,

во-первых, нормальный программист так не делает, если только прям прижало (да и то, для этого другие механизмы использоваться должны)
во-вторых, к форматированию это не приведёт. Сделай такую штуку нарочно - и я поверю, что это может случайно произойти, да и то, если природа ошибки будет одинакова

[lapulya]

1) вот если прижало и он так сделал, то и получит на орехи
2) да легко, писать не буду долго подгадывать, а вот суть в псевдо коде такая, допустим у тебя есть в программе кусок, который стирает определенный файл, естественно делаются все проверки и т.д.

if (есловие)
removeFile(определенный)

при запуске программы исходный код смаппирован в память, при освобождении чужого участка памити и трешь ту область где идут проверки и пишешь в нее строку, которая в допустим там начинается условно с 1, получаем так

if (true || .... )

и имяфайла меняем на *, в итеге имеем

if (1)
removeFile(*);

очень условно, но смысл должен быть понятен, более того, может так сложиться есть у тебя строка которая будучи смапирована в память просто будет ассемблерным кодом функции форматирующей винт, соответсвенно если в рантайме исправить представление printf ("Hello word"); на эту и получишь, то что хочешь. Я ж уже рассказывал дважды как в рантайме!!! (прога уже работает) изменить функцию обработки сообщений, вот это наглядный пример того, как можно изменив кусок памяти в рантайме и кардинально поменять логику выполнения программы.

[Алексей++]

Код:

 при освобождении чужого участка памити и трешь ту область где идут проверки и пишешь 

процессор не даст изменить сегмент кода

[lapulya]

Во первых код в динамике менять можно (я ж сказал что могу функцию обработки окна сменить), а во-вторых причем тут процессор?

[Алексей++]

lapulya, процессор при том, что есть сегменты кода, стека и данных , разделение которых в x86 поддерживается на аппаратном уровне

чтобы поменять из программы содержимое сегмента кода, надо приложить усилия (какие - точно не знал , да и забыл, как говорится ) , а кроме того может взбрыкнуть антивирус . Хотя последний тут практически ни при чём , те самые усилия случайно не получатся, как следствие изменения буфера строки, например

[Finch]

lapulya, Ой, куда тебя не туда занесло. В конечном счете все действия оператора new сводятся к вызову функции malloc. Все действия оператора delete сводятся к вызову  free. Для Linux будет все равно откуда вызвано, все равно будет обрашение к библиотеке стандартных функций  libc.
Какие я вижу вообше подножки в этом: Оператор new можно переопределить и занести Какие либо свои структуры в выделяемый участок памяти. Естественно другой delete, который не обучен этому, просто напросто не сможет удалить данный участок памяти. Последствия этого течь памяти.
ּВ винде память для программ выделяется в специальных участках памяти, называемых куча. Если delete  начнет удалять в не своей куче, просто напросто, он не найдет соответствуюший адрес в своих таблицах, и просто не удалит его. Как следствие течь памяти.
В принципе я не совсем понимаю, почему должна быть разница, где описан код, с работой с динамической памятью. По любому случаю, в окончательном объектном файле будет просто линк на функции malloc и free стандартной библиотеки.

[Антон (LogRus)]

Finch, попробуй взять std::string
напиши dll которая которая будет заполнять строку например 1000 символов интерфейс вот такой
extern "C"
{
void foo(std::string &);
}

теперь напиши exe который будет вызвать функцию библиотеки.

библиотеку компилируй в VC++, а exe компилируй в gcc

{
   std::string s;
   foo(s);
}

у меня была ошибка обращения к памяти, лечил предварительным резервирование буфера в строке что бы не было аллокации в библиотеке

использовал std::string из STLport

куча то у всех конечно одна, но вот только операторы new/delete не обязательно явно делают malloc, они могу делать еще какую-то работу

Хотя всё это давно было я тогда только начинал программировать и VC++ была старенькая, фиг знает, какая заточка есть у STLPort от VS 6.0.

[lapulya]

Finch, Дискутировать на эту тему даже не буду ибо... ээээх...
Короче проблемы будут... вот..., если не верится надо книжки почитать (да в баню книжки..., просто Страуструпа взять и про new и его переопределение почитать, или Рихтера, там тоже есть)

Ладно, поясню, реализация new  в одном модуле (да через malloc и т.д.), НО тут вопрос сколько выделить и как использовать, допустим для оптимизации работы с памятью или для отслеживания утечек (или по еще 1000 причин) реализация new для int выделяет не 4 а допустим 6 или 8 или 10 байт, то и освобождение памяти будет такоеже т.е. соответственно 6, 8 или 10 байт. А в другом модуле типа все стандартно, т.е. для int выделяется и освобождается 4 байта.

Ну и теперь простой вопрос, что будет если память выделялать в модуле где под int выделяется 4 байта, а освобождается в модуле где под int отводится 10 байт... а для масштабов бедствия можно представить, что это был массив из 10000 элементов...