Уговорил - напишу компайлер который не будет создавть эти объекты...
P.S. Разумеется придется изучить стандарт на предмет обязательности создания объектов (т.е. вызовов невиртуальных конструкторов) при отсутствии в теле операций со статическими объектами...

Почему мне? Я у Майерса это прочитал.

Уффф... значит не я свихнулся...

Кстати, хотел спросить: тебе так не хочется, чтобы под заголовком стояло "изменено тогда-то тем-то"? ;)

В данном случае я спрашивал о времени жизни временного объекта при вызове SomeClass(); Мурр дал ответ, что хороший компайлер не станет вызывать конструктор SomeClass::SomeClass(), после чего я спросил: "даже если там будет код в конструкторе"? Спросив я сразу понял глупость вопроса -- если будет код, то компайлер его вырезать не станет, посколько никаких ответов не было ещё, я просто удалил вопрос, чтобы не было лишнего мусора.

Эээ... воросик - помимо получения знаний путем прочтения всякого-разного. есть еще путь постижения путем осмысления (самостоятельно) полученного опыта... не пользуеетесь?

Я разобрался с bad ptr
CString(ltoa(k,&temp,10)) проблема была тут. как только я ltoa требует к переменной k тип long там раньше стояла переменная i типа ULONGLONG
видать что-то в памяти происходило, но как только я изменил это заработало.
Вопрос. Как я могут узнать конец файла или нет в классе CFile
пример:
CStdio ifile ;
while (!iflie.eof)
{
}
так было бы прекрасно. но я там не наш╦л такого метода (eof).

Почему ж? Вот, например, прочитал я книжонку некоего гуру Джорджа Фелса, а там написано: когда подбиваешь, не х...рь. Попробовал - и правда ОН (с). Целесообразность и неизобретение колеса. Использование опыта, накопленного другими.

если будет код, то компайлер его вырезать не станет
------
Компайлер не может удалить вызов если есть побочный эффект от вызова или он не в состоянии определить наличие такого эффект - изменяется статический член, конструктор виртуальный, информация по базовому классу недоступна...
Реально же отследить эти условия не слишком просто, особенно если есть крутая иерархия и потому _большинство_ компайлеров будет строить вызов конструктора и вызов деструктора. Когда именно будет вызван последний - сразу или при выходе из области определения - не важно, кроме ситуаций с ошибками.

Целесообразность и неизобретение колеса.
-----
Увы, я изобретаю колесо регулярно... что интересно - почти всегда - целесообразно.

Об этом поподробнее пожалуйста.

> CString(ltoa(k,&temp,10)) проблема была тут. как только я ltoa требует к переменной k тип long там раньше стояла переменная i типа ULONGLONG
2all: что-то я чисто теоретически даже не могу понять, как из-за этого могли проблемы данные быть. У кого-нибудь есть идеи?

А ты сюда посмотри:

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

Дык может код принадлежит начальству, он только правит :-)
---
Без момеда нет почты к обеду

Такое начальство убивать надо. Вместе с кодом.

Может быть, потому, что stl и шаблоны сложны для двух месяцев?

Я тоже удивился, но решил что человеку воспитаному на РАПИРА и вынесшему основные знания по информатике из школы, лучше не выступать. Мало ли как там людей на факультетах информатики и кибернетики учат.
---
Сделать из мухи слона нетрудно, труднее его прокормить. (2:5030/67)

код не мой. дали чей-то старый. надо чтобы работал и с новыми требованиями.
я сделал немного по другому эту строчку.
k=(long)i;
tmp.Format("%d", k);
csLineNumber=LineNumber(tmp,2);
думаю так лучше.
Работать-то надо. вот и вожусь!

Для стековых объектов порядок размещения не гарантирован?