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 элементов...

[sss]

Не.... Вы зря так накинулись на Finch. Все правильно. Если обе функции резервируют из одной кучи - то все будет хорошо, какие бы дополнительные действия не делали new/delete. За это ответит менеджер памяти системы. Если из разных - привет утечки, плюс, возможно, всякие там int 3 и исключения...

[Джон]

lapulya, Я всё пытался понять причину, теперь вроде прояснилось. ИМХО ты перечитал книжек и сам себя запугал. Те ты хочешь сказать, что если я в дебаггерной версии проверю sizeof(int), то получу 6,8 или даже 10 байт?

Дебаггер действительно резервирует больше памяти, не за счёт структур языка. Так что твой аргумент бездоказателен.

[Finch]

LogRus, Именно со стрингом я не игрался в свое время, но свои собственные классы раскрывал в Dll т потом передавал в управление в основной модуль. Все работало как часы. Самое главное условие было, чтобы все модули компилировались при одинаковых условиях. Если Debug версия, то все должно быть Debug. Надо точно посмотреть в стандарт, но насколько я знаю в релиз версии delete не должен вызывать никаких прерываний и исключений, если дать ему на удаление неправильный адрес.

[lapulya]

Джон и sss ))))) new зарезервирует ровно столько памяти сколько Я скажу (ХОТЬ МЕГАБАЙТ), а вот из них доступно пользувателю будет ровно sizeof(int), чуешь чем паХнет...

[Finch]

lapulya, Вот с этого места поподробнее пожайлуста.

[Алексей++]

lapulya, вывод : если ты переписываешь new и delete , делай это так, чтобы не сказалось ни на чём, кроме класса, для которого ты это делаешь И не надо будет таких проблем искать, как ты ищешь

[Алексей++]

Джон и sss ))))) new зарезервирует ровно столько памяти сколько Я скажу (ХОТЬ МЕГАБАЙТ), а вот из них доступно пользувателю будет ровно sizeof(int), чуешь чем паХнет...

а у меня всегда было доступно ровно, сколько я попросил, ни больше ни меньше

[lapulya]

Я ща немного пьян ))) рассуждать могу ))) так вот пример из MSDN не совсем корректно поскольку переопределен оператор new для класса но дело не в этом а в подходе

Код:

// spec1_the_operator_new_function1.cpp
#include <malloc.h>
#include <memory.h>

class Blanks
{
public:
    Blanks(){}
    void *operator new( size_t stAllocateBlock, char chInit );
};
void *Blanks::operator new( size_t stAllocateBlock, char chInit )
{
    void *pvTemp = malloc( stAllocateBlock );
    if( pvTemp != 0 )
        memset( pvTemp, chInit, stAllocateBlock );
    return pvTemp;
}
// For discrete objects of type Blanks, the global operator new function
// is hidden. Therefore, the following code allocates an object of type
// Blanks and initializes it to 0xa5
int main()
{
   Blanks *a5 = new(0xa5) Blanks;
   return a5 != 0;
}

[lapulya]

так вот если мне надо я могу написать его так

Код:

void *Blanks::operator new( size_t stAllocateBlock, char chInit )
{
//мое begin
    void * registerID = malloc( sizeof(int) * 10000 );
//мое end

    void *pvTemp = malloc( stAllocateBlock );
    if( pvTemp != 0 )
        memset( pvTemp, chInit, stAllocateBlock );
    return pvTemp;
}

[lapulya]

Алексей1153++, писать в сегмент кода можно (ну елы-палы... так собственно половино взломов и осуществляется), для этого есть мега функции АПИ, и вот тут у тебя и будет ЖОПОЛЬ... Да чего удивительногото, я вот не пойму, вот вызови SetWindowsLong с параметрами смемы функции опработки сообщений окна и подсуть ей какуюто лажу.... например адрес статической функции в которой ты таки винт форматируешь ))))) и будет тебе счастье...

[Finch]

lapulya, Пока что это всё грозит только течью памяти. Ну и если некоректно переопределены new и delete, то и вылетом программы. Но это все никак не отражается на предмете нашего спора, пока.

[lapulya]

Неееее, ты ж не забывай, что при таком выделении, я и освобождать его буду... ну весь этот мегабайт (я ж хороший мальчик)!!! А теперь представть, что память выделялась при "стандартном" new, а освобождается вот в таком (см пример с мегабайтом), соответственно мы отдадим системе в пользование кучу НУЖНЫХ данных!

При этом все рухнет.

Не понял, я об этом и говорю, что все рухнет, а что еще какой-то предмет дискуссии был? Или ты конкретно про формат винта?

[Finch]

Во втором твоем примере, ты выделяеш два участка памяти. На второй ты отдаеш указатель, первый повисает в воздухе. При обычном delete, возратится в систему второй указатель. Первый продолжает висеть.

Пример из ֵMSDN в принципе не страшен для системы, кто его будет чистить.

[lapulya]

Finch, ты издеваешься да?
хорошо, я посню (хехе язык заплетаются, но писать еще могу )))) ), так вот при выхове new выделяем мегабайт + саму необходимую память (допустим под int), пишем в мапу (с клучем адреса выделенной памяти подд int) адрес моего мега, а в переопределенном delete (надеюсь пример не нужен) я удаляю не только выделенную память под инт (скстате, я могу его даже не удалять а пометить как неиспользуеная, ну да это в другой теме), но и отыскав в мапе по ключу [значения поинтера на int] поинтер на мегабайт освобождаю и его(его - это я про мой любьыный мегабайт)!!! Вот и капец... пойду еще чарочку выпью ))))

[Алексей++]

Алексей1153++, писать в сегмент кода можно (ну елы-палы...

так блин пипец, я не говорил, что нельзя ))) Но случайным образом это вряд ли произойдёт

И вапще, протрезвей уж тогда , тогда дальше будем тебя воспитывать )

[lapulya]

это почему вряд ли, пометим сегмент кода, как сегмент данных (допустим мы драйвер, утилиту или антивирус пишем, или тучу других немного специфичных, но прикладных программ... искусственный интелленкт, да малол и что), ну а дальше по накатанному (описанному выше). Короче если специально так сделать не получится, то случайнго легко )))) . И потом, ну что ты привязался именно к формату винта, тебе падения программы недостаточно? Мне например, этого выше головы хватает, чтобы признать, что это неопределенное повелдение, при котором может случиться ВСЕ, что угодно (конечно все зависит от обстоятельств, может и корректно отработать) И что так писать ни в коем случае НЕЛЬЗЯ!

[Алексей++]

И потом, ну что ты привязался именно к формату винта, тебе падения программы недостаточно?

lapulya, ну уже не приписывай мне свои фобии )))

а у меня программы падают исключительно на этапе отладки , а винт, слава Богу, терялся только при взрывчике в блоке питания, кой никак с операторами new и delete не связан Более того, даже синий экран уже несколько лет не видел у себя на компе.

И случайно заменить сегменты не получится. К сожалению, не так тут подкован, чтоб привести пример такого действия... Может ты покажешь ?

[Джон]

Я ща немного пьян

Только ща? (шутка)

Слушай, если ты пытаешься убедить в том, что можешь умудриться сделать так, что программа таки вылетит, то это напрасный труд. Даже если не очень постараться, то можно сделать подобное гораздо проще. Например, сместив указатель перед вызовом delete.

Но ответь на вопрос - ЗАЧЕМ ТЕБЕ ЭТО НАДО? Чтобы подтвердить твою выдуманную теорию? Так это не явное доказательство её состоятельности. Говоря другими словами,  ты приводишь в качестве доказательства грубые ошибки программера. Ведь автоматически это не произойдёт, а если ты сам делаешь ошибки, то кто в этом виноват?

[sss]

Вот вот. Как это - при выделении int выделяем 1MB + sizeof( int), потом в другом модуле удаляем вроде бы int, а на самом деле 1MB + sizeof( int). То есть, в этом, другом модуле, мы не знаем что там 1MB + sizeof( int). В итоге: код, неявно использующий это пространство, делает его доступным приложению, абсолютно не умеющему с ним работать.

И еще. Для безопасной передачи объекта лучше всего, если у объекта есть виртуальный метод (например Release), который вызовет нужный деструктор в нужное время. Все остальные передачи должны или строго документироваться или вообще не использоваться (шутка).

Блин, все равно lapulya прав. Передача объектов ( например STL) одного модуля в другой, не заточенных под это действо, опасно утечками и сбоями в работе приложения...

[Джон]

Если интересует грамотное решение, то оно есть и широко используется.

DWORD dwSize = 0;
кто-то_неважно_кто->GetData(NULL, &dwSize);
*p = new тип_данны�

[Алексей++]

Джон, так я обычно так и делаю ) Только не
new тип_данны

[lapulya]

Джон, сам то понял чего сказал? У меня new может выделять память в нескольких местах (в моем примере в двух, а потенциально в 1000 и более) а возвращает только ОДИН пои нтер, на тот участок который дается пользователю, вот его то ты своими ухищрениями освободишь, но
1. Ты не освободишь все остальные выделения памяти (это как раз мой мегабайт) - итог все рухнуло
2. Ты реально отдашь системе всю память которая была выделена, ну а кто ж тебе сказал что ее отдавать то надо!!! (ее реализация new в буфере своем например хранит, для скоростного выделения в следующий раз!!!!, но new не знает о том что ты ее реально системе отдал, и при последующем выделении new отдаст твоей программе поинтер на область памяти, которую система (это я про ОС) считает уже СВОЕЙ, типа свободной) - итог все рухнуло

Общий итог - не ты выделял, не тебе и отдавать. Нарушил это правило - получи неопределенное поведение.

[Алексей++]

ее реализация new в буфере своем например хранит, для скоростного выделения в следующий раз!!!!,

бред , кто бы стал так писать ? Раз человек сказал программе - отдать память системе, значит отдай, неча запоминать для быстрого выделения

[Джон]

lapulya, ты вобще что ли код не понмаешь или похмелье долбит?  Я же тебе показал, что выделение памяти и освобождение происходит в ОДНОМ месте!!! Это не ухищрение, а грамотное решение передачи буфера куда угодно. Или ты такие решения никогда не видел? А как программист ты ОБЯЗАН обеспечить адекватное поведение new и delete в одном модуле. Или ты в одном модуле для одного типа данных можешь сделать НЕСКОЛЬКО new? Ну-ну флаг в руки и читать Страуструпа.

ИМХО ты уже пургу несёшь ради пурги. Мне уже даже не интересно...

[lapulya]

Что значит человек сказал... он так сказать может, только если сам взял, потому как точно знает, что при этом происходило (если ты сам память на самом низком уровне выделял), а если ты используешь new это уже не значит, что ты ее сам выделял, значит и освободить можешь только вызвав delete, а не free и т.д.

И если ты на практике такого не видел и не слышал, то это не значит, что это не использиется, не правильно или как ты пишешь бред (new очень медленная операция, это я так... для информации). От себя скажу - такой подход используется в ТУЧЕ мест! С другой стороны если ты используешь MFC, то ясное дело что тебе это не известно, а точнее, что ты этим не пользуешься.

[lapulya]

Джон, Ты наверное не сшачала читал, смысл дискусии, что если выделение происходит в одном модуле, то и освобождать надо в нем же (Пушистый интересовался почему). Если ты просто написал как выделить память и удалить в ТОМЖЕ САМОМ модуле (ты в своем посте, кстати, этого НЕ написал), так это СОВСЕМне в тему и с этим никто не спорит (я бы даже сказал что такое изврашение никчему, достаточно просто new). А если ты таки предлагаешь new делать в одном модуле, а delete в другом (пусть и ровно так как ты и предложил), то твое предложение ни как не помогает.

[Алексей++]

lapulya,

Что значит человек сказал..

имеется в виду программист ))

он так сказать может, только если сам взял, потому как точно знает, что при этом происходило

есть такой момент, я знал

а если ты используешь new это уже не значит, что ты ее сам выделял, значит и освободить можешь только вызвав delete, а не free и т.д.

1) не согласен, я САМ выделял память, попросив сделать это систему. А придираться к тонкостям промежуточного процесса не надо
2) new-delete , воистину. Никогда кроме как ими и не пользовался

И если ты на практике такого не видел и не слышал, то это не значит, что это не использиется, не правильно или как ты пишешь бред

верю, что ты применяешь это на практике, но это действительно не правильно и бред

(new очень медленная операция, это я так... для информации)

ни разу не приходилось применять что то кроме, скорость всегда устраивала Значит, медленно - понятие относительное

От себя скажу - такой подход используется в ТУЧЕ мест!

примеры , плюсы и минусы этих мест

С другой стороны если ты используешь MFC, то ясное дело что тебе это не известно, а точнее, что ты этим не пользуешься.

а может просто MFC правильно написан ?

Джон, Ты наверное не сшачала читал, смысл дискусии, что если выделение происходит в одном модуле, то и освобождать надо в нем же (Пушистый интересовался почему).

неправда! Хватит приписывать то, что я не говорил Смысл дискуссии: насколько вредно менять байты в буфере экземпляра CString. По крайней мере это у меня так

[Джон]

lapulya, #100 ваще ничего не понял. Но уже и не пытаюсь.

ты в своем посте, кстати, этого НЕ написал

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

Читал сначала и сделал вывод, что ты сам запутался и остальных пытаешься запутать, выдумывая ральные, но всем подавно известные проблемы. Я только до сих пор понять не могу зачем? Ведь ёжику понятно, что тот кто породил должен и убивать. Или кто-то с этим спорит?

[Алексей++]

Точно, ещё Тарас Бульба так говорил - я тебя выделил через new, я тебя обратно в кучу и верну (через delete)

Или не он говорил ?

[lapulya]

имеется в виду программист ))

)))) это я понял, ясно что не дворник )))

Цитировать

Джон, Ты наверное не сшачала читал, смысл дискусии, что если выделение происходит в одном модуле, то и освобождать надо в нем же (Пушистый интересовался почему).

неправда! Хватит приписывать то, что я не говорил  Смысл дискуссии: насколько вредно менять байты в буфере экземпляра CString. По крайней мере это у меня так

Это она началась с этого (пример Джона никак не помогает в этом "насколько вредно менять байты в буфере экземпляра CString", поскольку ты не контролируешь ни создание, ни удаление буфера памяти, которым пользуется CString)

а может просто MFC правильно написан ?

Я не говорю, что он написан неправильно, могу сказать что для многих приложений он слишком громоздкий, медленный и отжирает слишком много памяти, НО опять таки все зависит от приложения, вот для офисных приложений его скорость с большим запасом хватает, поэтому ты и не ользуешься чистым АПИ, поскольку тебе писать программу используя MFC удобнее и быстрее. Ну а есть приложения где он не применим (вот почему бы примеры не придумать самим всеж на поверхности... это проги, где критично важна скорость и/или место в памяти и/или переносимость ну или что-то чего библиотека не умеет, а расширить своими классами по каким либо причинам нецеоесообразно из-за архитектуры, например). То что медленно понятие относительно известно за долго до программирования)))) Так вот с этим я так же не спорю (и не спорил) и поэтому то и написал, что раз скорость тебя устраивает, то и совершенно логично, что ты и не пытался ее увеличить (один из ключевых принцыпов Тойоты - не надо делать того что не приносит пользы/выгоды)

1) не согласен, я САМ выделял память, попросив сделать это систему. А придираться к тонкостям промежуточного процесса не надо

ну какойже тут промежуточнй процесс, совершенно нормальное распределение обязанностей, один разработчик пишет одно, другой другое (если ты программу один пишешь, включая все библиотеки, то ну в этом есть и прелесть и недостаток, но я то про общий случай, когда несколько программистов пишут программу, да в ней еще и сторонние библиотеки используются). Так вот один пишет логику какогото модуля, а второй например сервисные функции, в том числе и неализацию new, а посему уже не ты контролируешь создание объекта и в другом модуле с ним надо вести себя как полагается (о чем я и пытаюсь рассказать)

примеры , плюсы и минусы этих мест

Ну что ж, давай разбелемся в чем суть... есть несколько причин когда имеет смысл использовате переопределенную new (на вскидку я придумал три, но подозреваю есть и еще)
1. (развивать тему не буду, могу тольуо теоритизировать, а вам же подавай фактов и примеров))) , так гарбачто только направление) Это определение утечек + подсчеты ссылок + автоматическое управление памятью (типа реализация гарбадж коллектора)
2. Предположим програма работает с данными, которые должны храниься в памяти, да еще и в непрерывном участке, тогла выделяя память беспорядочно (т.е. так как ты ))), без обид, это просто пример) мы ее сильно фрагментируем, и может так случиться что там нужен кусок памяти допустим длинной в 50МБ, при  этом у нашего просецесса, в настоящий момент доступно аж 2Гб!!!, но выделить непрерывный участок ОС не сможет (ну нет свободного непрерывного участка памяти), соответственно если реализщовать new так, что допустим (только как пример) при запуске аллоцируем там ну пусть 100 Мб и выделяем память оттуда помечаяя ее как используемую и возвращая тудаже (т.е. помечая как свободную, но не отдавая ОС как ненужную), мы решаем проблему дешрагментации
3. Как я уже сказал new медленная операция (куда как медленнее (на порядки) вызовов виртуальных функций и т.д., т.е. реально медленная),так вот если есть необходимость очень очень частого вызова new (как правило для маленьких в размерах объектов, но есссесно не обязательно для них), то прога, которая должна выполняться быстро (прикладные системы реального времени, ОС, утилиты и драйверы, компьютерные игры, программы занимающиеся расчетами: научные и коммерческие, ну там 3D MAX или какое нить моделирование, AutoCAD и т.д.) должна как-то обойти этот момент, опять на помощь может (а может и нет, можно же new переопределить, для приложения в целом, можно для класса, а можно например фабрику объектов сделать, поднявшить ввер по лестнице абстракции) прийти переопределение new (ну опять таки например выделением изначально большого буфера и черпая оттуда память при необходимости и отдавая в нее же)
Это плюсы, ну а минусы ты и сам ща найдешь ))) я тебя знаю ))))

[lapulya]

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

[lapulya]

Джон, я так (уже без надежды)... чисто обратить внимание, что речь шла о проблемах при передаче объекта через границу модуля и уже там, в другом модуле, переаллоцирование памяти (в качестве примера приводилась передача sdt::string и описание возникающих при этом проблем и описанием того откуда они бесутся), а так же о том, что нехорошо менять контент сонстантного буфера, особенно предоставленного чужим для тебя кодом/библиотекой. Я покрайней мере дисутировал об этом

В чем твоя мммм твой аргумет, когда ты привел пример

Код:

DWORD dwSize = 0;
кто-то_неважно_кто->GetData(NULL, &dwSize);
*p = new тип_данных[dwSize];
кто-то_неважно_кто->GetData(p, &dwSize);
...

delete [] p;

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

[Алексей++]

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

не замечал Всё летает, экзешник маааленький, озу занято ровно столько, сколько весит программа+сколько я выделил памяти на переменные, не больше

вот для офисных приложений его скорость с большим запасом хватает, поэтому ты и не ользуешься чистым АПИ, поскольку тебе писать программу используя MFC удобнее и быстрее

опять придумываешь то, чего нет Я не пишу офисных, у меня скорость очень даже критична - мы занимаемся охранными системами
АПИ активно не  пользуюсь, потому что удобнее MFC, но вместе с тем легко и без зазрения совести использую АПИ там, где не реализована MFC или просто по велению желания

Ну а есть приложения где он не применим

примеры обязательны

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

[lapulya]

Леха,

не замечал  Всё летает...

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

не замечал  ... экзешник маааленький...

Еслиб ты все тоже самое написал на чистом АПИ ты бы понял о чем речь (опять же все относительно, для ммм примера создай приложение в котором просто отображается окно на АПИ и с помощью MFC и сравни)

не замечал  Всё летает...озу занято ровно столько, сколько весит программа+сколько я выделил памяти на переменные, не больше

)))) так ровно так будет даже если использовать самую не эффективнуб библиотеку (естественно памяти отжирается ровно столько, сколько ты сказал ))) )

Цитировать

Ну а есть приложения где он не применим

примеры обязательны

На вскидку игры

опять придумываешь то, чего нет  Я не пишу офисных, у меня скорость очень даже критична - мы занимаемся охранными системами
АПИ активно не  пользуюсь, потому что удобнее MFC, но вместе с тем легко и без зазрения совести использую АПИ там, где не реализована MFC или просто по велению желания

Я никогда ничего не придумываю, я предполагаю, видимо охранная система не критична к скорости (это опять предположение), мне как стороннему наблюдателю не очевидно, где там скорость нужна (сработает она сек. позже или раньше, но роизнаю что могу ошибаться). Кстати вопрос, то место в системе где важна скорость, выполняется на тойже машине и в рамках того же процесса, что и GUI? Ответ нет, говорит о том, что не мы говорим о проблеме узкого места (я допускаю что оно есть, но не тут). Если ответ да, то ммм могу порекомендовать переписать какую-то часть (отдельный модуль) на АПИ (полностью) и замерить скорость и память, а потом потребовать у руководства премии и повышения, поскольку этот модуль будет работать тем быстрее, чем больше в нем было кода из MFC и занимать тем меньше мапяти, чем больше объектов MFC в нем создавалось. (когда я говорю про память я имею ввиду И объем экзешника И объем отжираемого прогой ОЗУ)

[Джон]

я так и не понял

На самом деле всё очень просто:

кто-то_неважно_кто->

Вот этот самый "неважно кто" может быть чем угодно - в данном случае - другим модулем. Именно он должен мне сообщить какого размера буфер необходим для данных, чтобы Я его создал, а потом опять же Я его удалил. Кстати такую конструкцию желательно использовать не только при получении данных из другого модуля. Очень полезно ВСЕГДА вместе с указателем на буфер передавать и размер этого буфера. Конечно подразумевается, что ответная сторона должна уметь правильно использовать эти данные.

зы Ну и тоже, к слову - про MFC, STL и пр. это уж совсем ни к селу ни к городу. Эта проблема не зависит от неких врапперных библиотек. Чем передача скажем массива типа int отличается? Если ты видишь, что другой не прав, то чётко сформулируй проблему и укажи на неё, а ты подхватил MFC, STL, new, malloc, скоростная реализация, пургу про debugger понёс... в итоге столько лишних килобайт спихнул... А сформулировать проблему можно в нескольких словах. Чем меньше слов, тем меньше комбинаций. Тогда и дисскутировать проще - всё чётко и ясно.

[lapulya]

Джон, я все описал очень четко. Если я хоть где-то не четко или нелогично что-то написал или привел некорректный пример, то приведи любой пример из моей фразы? Вот где у меня есть высказывание, которое не следует из моего предыдущего поста или поста моего собеседника - повторяю ХОТЬ ОДИН пример приведи, и я признаю, что я был неправ.

[lapulya]

Джон, ты пишишь

Вот этот самый "неважно кто" может быть чем угодно - в данном случае - другим модулем. Именно он должен мне сообщить какого размера буфер необходим для данных, чтобы Я его создал, а потом опять же Я его удалил. Кстати такую конструкцию желательно использовать не только при получении данных из другого модуля. Очень полезно ВСЕГДА вместе с указателем на буфер передавать и размер этого буфера. Конечно подразумевается, что ответная сторона должна уметь правильно использовать эти данные.

Вот ты мне объясни к чему ты это написал (вотт где логика в твоих утверждениях)? Кто-то спрашивал можно ли передать данные из модуля в модуль? Или может кто-то спрашивал как именно можно передать данные из модуля в модуль? Можно цитату где есть хоть намек на это?

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

далее

Ну и тоже, к слову - про MFC, STL и пр. это уж совсем ни к селу ни к городу. Эта проблема не зависит от неких врапперных библиотек. Чем передача скажем массива типа int отличается? Если ты видишь, что другой не прав, то чётко сформулируй проблему и укажи на неё, а ты подхватил MFC, STL, new, malloc, скоростная реализация, пургу про debugger понёс... в итоге столько лишних килобайт спихнул... А сформулировать проблему можно в нескольких словах. Чем меньше слов, тем меньше комбинаций. Тогда и дисскутировать проще - всё чётко и ясно.

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

[Алексей++]

lapulya, игры тоже на си++ часто пишут. Летает же Платы - ускорители рулят , аудио, видео, физические даже есть

Еслиб ты все тоже самое написал на чистом АПИ ты бы понял о чем речь (опять же все относительно, для ммм примера создай приложение в котором просто отображается окно на АПИ и с помощью MFC и сравни)

по размеру - не думаю, что намного будет разница, что есть 64 килобайта сегодня ? )

)))) так ровно так будет даже если использовать самую не эффективнуб библиотеку (естественно памяти отжирается ровно столько, сколько ты сказал )))

так будет всегда и везде

На вскидку игры

пишут, я даже не сомневаюсь в этом.

Охранная программа очень активно работает с ресурсами - инфы по радиоканалу приходит море, всё это надо складывать в базу и показывать операторам на сервере и 10-20 клиентах. Секунды решают всё: если где то нажали тревожную кнопку, опоздание на 5 секунд может обернуться , в общем то, бедой. Программа работает месяцами без выключения , параллельно на компе запускаются и работают другие программы - нормально работают По структуре в программе всего один дополнительный поток, кроме основного процесса, поток читает данные с порта

зы Джон прав, при чём тут MFC, не MFC ? ) Тормозов в MFC не больше, чем в АПИ , всё зависит от кривизны рук )

[lapulya]

Алексей1153++,

игры тоже на си++ часто пишут. Летает же  Платы - ускорители рулят , аудио, видео, физические даже есть

ЭЭЭЭ не знаю что сказать... я бы сказал так - обычно (а не часто) их пишут на с++... Может ты хотел написать "игры тоже с использованием MFC часто пишут." ну скажем так я знаю всего пару игр (а игр вообще я знаю очень много) которые были написаны с использованием MFC (я говорю про саму игру, а не например редактор карт или миссий) и все они пошаговые стратегии, шахматы например, ну или на вскидку варлорд2 и 3, но их не много и им не нужна высокая производительность.

по размеру - не думаю, что намного будет разница, что есть 64 килобайта сегодня ? )

А ты смотри не абсолютную а относительную разницу (типа не на сколько, а во сколько)

так будет всегда и везде

ну дык я об этом и написал (сама прога включая любые библиотеки ничего не выделяет))) если ей программер не укажет)

опоздание на 5 секунд может обернуться , в общем то, бедой.

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

зы Джон прав, при чём тут MFC, не MFC ? ) Тормозов в MFC не больше, чем в АПИ , всё зависит от кривизны рук )

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

Выскажу личное мнение (прошу сильно не пинать) - мне MFC не нравится ия ее не использую, по сути у меня своя MFC (обертка над АПИ), я ее давно написал и от проета к проекту улучшал, что при этом имел...
положительные моменты - гораздо большую гибкость, скорость и экономию в ресурсах, а также архитектуру, которая казалась оптимальной
отрицательные моменты - достаточно много времени на проектирование, разработку и отладку (как следствие низкая скорость разработки до выхода в свет первой ммм версии, а далее как по накатанному, но местами при развитии также были затыки, но не часто и они были не большими) + необходимость ее развивать + немного времени уходило на поддержку нескольких версий библиотеки (правда реально очень мало, но всетаки) которые использовались разными приложениями (это естественно, этож не коммерческая библиотека и как и любая не коммерсческая она развивалась и хочешь или нет, некоторые решения в интерфейсах были не очень удачными. Ну а следовательно: или допилка клиентского кода и использование единой версии бибилиотеки для всех кдиентов, или код клиента константен и поддержка нескольких библиотек. Я не сторонних крайних мер, поэтому делал то так, то подругому), а так же из недостатков следует отметить трудности с передачей ее другим программистам (документации я не писал, все что было - это комментарии в особо сложных участках кода + выгрузка в розу диаграммы классов в разрезе модулей)

[Алексей++]

lapulya, я сказал, что хотел сказать Производительность у MFC хорошая, если это не так - приведи конкретные примеры или вообще не говори об этом

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

люди платят за безопасность, они знают, что ОЧЕНЬ скоро после нажатия приедет наряд с автоматами Им "может да, может нет" не нужно
Скорость реакции реал-таймовых игр зависит от скорости соединения, так как процессор намного быстрее скорости обмена. О чём тут говорить ? при чём тут язык вообще ?

но по скорости чистому АПИ он уступает и сильно (я ж говорю просто выведи окнои и замерий время),

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

Выскажу личное мнение (прошу сильно не пинать) - мне MFC не нравится ия ее не использую, по сути у меня своя MFC (обертка над АПИ), я ее давно написал и от проета к проекту улучшал, что при этом имел...

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

---------
зы а в остальном: если ты поставил цель просто спорить, то не переспоришь ) Вот когда веские аргументы станешь приводить, тогда и посмотрим А так - хоть до посинения

[lapulya]

Алексей1153++,

lapulya, я сказал, что хотел сказать  Производительность у MFC хорошая, если это не так - приведи конкретные примеры или вообще не говори об этом

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

Скорость реакции реал-таймовых игр зависит от скорости соединения, так как процессор намного быстрее скорости обмена. О чём тут говорить ? при чём тут язык вообще ?

Первое - скорость реал тайм-игр от скорости соединения не зависят (они вообще без сети могут работать), от скорости соедингения может зависеть онлайн игры, но опять таки скорость соединения тут непричем, потому как пропускная способность канала в наши дни, не знаю как в Златоусте, но у меня в Москве гораздо (на несколько порядков) больше нежели необходима любой игре в которые я играл (включая WoW для определенности).
Второе - я про язык первым ничего не говорил (я только дал комментарий на твое "игры тоже на си++ часто пишут"), поэтому причем тут язык программирования это я у тебя спросить должен? С чего ты про него говорить стал?
В третьих - (еще раз повторю то, что написано выше) Если говоря про пример имел ввиду - докажи, что использование MFC в играх тормозит их, то не буду (это аксиома и в доказательствах не нуждается, если я тебя именно в этом не убедил, точнее если ты в этом сомневаешься или просто считаешь что это утверждение не верно, спорить и даже дискутировать не будет просто расстаемся каждый со своим мнением)

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

Ладно (тебе лень я понял ))) ), я сам эти две строчки напишу и вышлю результаты по скорости работы + оперативной памяти + памяти на диске (кстати )))))))))) MFC по умолчанию статически линкуется, да?)))) )

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

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

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

[Алексей++]

это аксиома и в доказательствах не нуждается,

то есть ты признаёшь своё бессилие привести хорошие примеры ?

Первое - скорость реал тайм-игр от скорости соединения не зависят

я подумал, что ты говорил об игре по сети (локально никто 5 секунд не допустит задержку - это и так понятно)

MFC по умолчанию статически линкуется, да

да . Ну давай, напиши , подсчитай.

[lapulya]

Алексей1153++,

то есть ты признаёшь своё бессилие привести хорошие примеры ?

Да, ибо это именно тот момент, когда я считаю, что хочешь поспорить только ради спора.

я подумал, что ты говорил об игре по сети (локально никто 5 секунд не допустит задержку - это и так понятно)

Даже если говорить про игры по сети, то есть огромное количество игр (именно по сети) в которых задержка в 5 секунд невозможна (точнее неприемлена, при таких задержках проигрышь гарантирован), как пример WoW + все те игры что я перечислил ранее (но теперь рассмотреть вариант игры по сети. По ясню, подавляющее большинство игр позволяют играть как типа против компа - стендэлон, так и по сети, против(ну или за ))) ) людей)

да . Ну давай, напиши , подсчитай.

Ок напишу... Тока не гони...

[lapulya]

Напасал, итак (у меня виста, 2005 студия):
На диске
MFC - 276Кб
API - 56Кб

В памяти (тут сложновато, использую таск менеджер, другого не имею)
MFC
памяти - 9 756Кб, выделенной памяти (в чем отличие от предыдущего пораметра не знаю) - 2 236Кб
API
памяти - 8 028Кб (более чем на 1,5Мб меньше), выделенной памяти (в чем отличие от предыдущего пораметра не знаю) - 2 016Кб (более 200Кб)

Скорость выполнения
MFC - 195 тиков (в среднем по GetTickCount)
API - 157 тиков (в среднем по GetTickCount)

А я только одно окно вывел

[Алексей++]

во первых, не знаем чистоты эксперимента: какой проект, как построен, что делает?
-----------------
1) как видим, разницы практически нет ни в чём, немного больше озу - это ерунда, совсем мизерно больше экзешник - туфта (они НА столько и будут отличаться - dll то уже встроена и её размер не измениться, то есть будет 2Mb на API и 2Mb+220байт на MFC - если грубо.) Если это не так - доказывай
2) тики отличаются немного. Кстати: а)как мерял  ? b) почему значения близки к маленькой отметке шкалы ? Метрологию не учил ? Сколько измерений делал для получения среднего значения ?

[sss]

Алексей1153++, хватит дразнить человека. У меня давно случай был. Устраиваюсь я как-то на работу, сидит дядя и задает мне вопрос. Какой код работает быстрее - на ассемблере или delphi. Ну в общем аксиомный такой вопрос. И тут меня злость взяла. Я ему - без разницы. Один хер все упрется в сервисы системы и навык писателя. Ну и не взял он меня, а мне и лучше - как я теперь думаю . Это я к чему - хватит писями мериться....
Алексей1153++, вчера кстати был день метролога. Поздравляю 

[Алексей++]

sss,
да я не дразню Пусть человек, раз так рьяно доказывает ошибочное мнение, убедится, прав он или нет. Или я убедюсь. Неважно Просто потом нам знание об этом пригодится как ему, так и мне.

[Алексей++]

кстати, я не метролог, терпеть не переношу метрологию У нас препод был суровый, ух... Только я плохо всё равно учился

[Антон (LogRus)]

не знаю что за тест, но для меня явно мало данных о тесте.
лично мне нужно что бы тест шел минимум 1 минуту
при этом нужно получить данные о числе итераций и суммарном времени
о памяти хочется знать mem usage/VM Size - это из таскменеджера и virtual bytes/private bytes из монитора производительности.
и нет описания теста.

[lapulya]

LogRus, я ж написал что у меня виста, а ты про показатели из таск менеджера ХР, я в висте ничего серьезного не писал и что это за показате памяти не знаю (вообще их в висте 5 или 6 на процесс, все имеют разное значение), я ж это открыто написал, вот есть два показателя (из 6) чем один от другогоотличается - я не знаю))) - названия обоих привел.

О тестах
количество прогонов - 100 (это я о тиках), вопрос пушистого "почему значения близки к маленькой отметке шкалы " я не понял. Приеденное значение тиков это разница между количеством тиков в начале выполнения и сразу после UpdateData (после отрисовки окна), на самом деле разница еще польше (читай апи быстрее), паотому что объект app создается раньше того момента когда мы в мэйн попадаем. То что разница не вылика, так еще раз повторю, проги только окно создают и отрисовывают и все!!! пишите проги больше, соответственно и абсолютная разница будет расти, а вот относительная около 20%, помоему это существенно и эта тенденция только увеличится (не забываем про контролы и т.д.) - на мой всзляд этого достаточно, чтобы признать что апи быстрее (конечно не в разы, но я об этом и раньше говорил, я даже сомневаюсь, что при большом размере программы этот показатель достигнет 2... ну т.е. апи не будет работать в 2 раза быстрее, но в 1,5 легко). Леха как я говорил, в приложениях не критичных к скорости (памяти и т.д.) никто и никогда разницы на глаз не заметит.

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

[lapulya]

Кстати, еслибы это окно было диалоговым (с контролами и побрякушками) разница былабы существеннее и заметнее (но опять таки только в цифрах, на глаз ее в жизни не заметить, ну если речь об ИйБиЭм совместимых современных машинах идет

[Алексей++]

lapulya,

количество прогонов - 100 (это я о тиках)

какие прогоны были ? Уточни уже об них

вопрос пушистого "почему значения близки к маленькой отметке шкалы " я не понял.

я не совсем правильно выразился - измеренное значение близкО к цене деления (то есть ~10...30 тиков) , и если в случае , скажем, линейки, можно точно сказать что 2 мм - это да, 2 мм , то на пружинных весах с ЦД==1 грамм нельзя точно взвесить 1...5 граммов. Вернее, взвесить то можно, но погрешность растёт сильно (50% - 1 грамм). А вот килограмм взвесится с погрешностью 0,1% .
В общем - пока количество тиков не сделаешь по несколько тысяч в обоих случаях - точности никакой. Ещё к этому присобачиваем кеширование , то есть после парочки прогонов программа вполне может заработать быстрее.
Вот как-то так )

Теперь, нихрена не понятно, при чём тут UpdateData  (я вообще не пользуюсь этим) и вообще - контролы (КОНТРОЛЫ, О БОЖЕ!!! (юмор) ) ? Когда играешь в игру или архивируешь файл - много контролов используешь ?

паотому что объект app создается раньше того момента когда мы в мэйн попадаем

опять не правда, с менй начинается выполнение программы , потом создаётся объект theApp, в котором потом вызывается InitInstance, где создаётся и показывается главное окно с контролами (О БОЖЕ!!! КОНТРОЛЫ!!! (юмор) )

пишите проги больше, соответственно и абсолютная разница будет расти, а вот относительная около 20%,

с какого перепугу то ? Вовсе не правда.

Кстати, проекты - в студию

И ещё кстати - виста не показатель, там даже папка с трудом открывается

[lapulya]

Алексей1153++,

какие прогоны были ? Уточни уже об них

А что уточнять? Я ж говорю 100 запусков под ряд и усреднение кол во тиков, я не знаю чего еще уточнить...

я не совсем правильно выразился - измеренное значение близкО к цене деления (то есть ~10...30 тиков) , и если в случае , скажем, линейки, можно точно сказать что 2 мм - это да, 2 мм , то на пружинных весах с ЦД==1 грамм нельзя точно взвесить 1...5 граммов. Вернее, взвесить то можно, но погрешность растёт сильно (50% - 1 грамм). А вот килограмм взвесится с погрешностью 0,1% .
В общем - пока количество тиков не сделаешь по несколько тысяч в обоих случаях - точности никакой. Ещё к этому присобачиваем кеширование , то есть после парочки прогонов программа вполне может заработать быстрее.
Вот как-то так )

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

Теперь, нихрена не понятно, при чём тут UpdateData  (я вообще не пользуюсь этим) и вообще - контролы (КОНТРОЛЫ, О БОЖЕ!!! (юмор) ) ? Когда играешь в игру или архивируешь файл - много контролов используешь ?

Обо всем попорядку:
1. UpdateData ))) ну описался я, конечно UpdateWindow
2. Контролы тут при том, ммм тут мне нужна твоя помощь, разьве при отображении диалога MFC не создает как минимум по одному объекту на каждый контрол (вроде должен) с его инициализацией, регистрацией и т.д. Если НЕ создает, то да, виноват - контролы тут не причем (ну не знаю я MFC), а если коздает, то уж извиняй это все тормоза поотношению к АПИ (там ничего лишнего не создается и не вызывается, даже если писать враппер самому над АПИ, все равно это будет быстрее работать и компактнее в памяти по отношению к врапперам MFC)
3. В игре те же самые диалоги, пинели инструментов и в огромном количестве (одних меток то сколько, везде всего понапимано, тебе скриншот из WoW? У нас стобой пальцев на руках и ногах не хватит, чтобы хотябы половину посчитать)

с какого перепугу то ?  Вовсе не правда.

что именно не правда, то что абсолбтая разница расти будет, дык это ж очевидно? Если у MFC каждый объект в памяти запимает больше место, чем реализация его через АПИ, то два объекта удвоят эту разницу и т.д. отсюда и абсолютное увеличение... или ты имел ввиду что-то другое?

Кстати, проекты - в студию

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

И ещё кстати - виста не показатель, там даже папка с трудом открывается

)))) Согласен, но мне что теперь застрелиться ))) я ж примеры то для тебя привожу, сам то я и так в результате уверен, хоть в висте, хоть в ХР, хоть в 2000, хоть Вин95, хоть в мобильных версиях Винды (самя подо все кроме висты писал)
 

опять не правда, с менй начинается выполнение программы , потом создаётся объект theApp

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

[Алексей++]

запусков чего ? Программы что ли ? Ну да, тест хороший... Но нужны и другие - на производительность

Контролы тут при том, ммм тут мне нужна твоя помощь, разьве при отображении диалога MFC не создает как минимум по одному объекту на каждый контрол (вроде должен) с его инициализацией, регистрацией и т.д.

ничего я в общем случае не создаю - положил контрол на диалог и забыл про редактор.
Свои производные классы только приходится связывать - но АПИ делает то же самое,  только в АПИ нужно стандартные контролы явно создавать, в в MFC стандартная рутина где то в глубине скрыта - я не вожусь с этим. Но там тот же CreateWindow и всё

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

в WOW - 3D . Там нет контролов , как в винде, полигон, по которому тыркнули вычисляет видюха. Как тут сравнивать ? Тут интерфейс по иному устроен

Если у MFC каждый объект в памяти запимает больше место, чем реализация его через АПИ,

а зачем ему больше занимать ? Хендл - он и в африке не ананас...
А производные классы - они и в АПИ больше будут занимать

)))) Ну неееет ну что ж это получается, тебе все покажи, расскажи, докажи и премер

мне - ничего доказывать не надо Я вполне доволен жистью, вон в соседнем разделе групповуха начинается )

Код:

но глабальные переменные создаются до входа в майн 

только память под них выделяется и вызывается конструктор.

 А объект то винды создаётся после входа в мейн
Ну тут Джон подскажет, если я ошибся Но вроде это так