в файле file.txt есть две строки
ааа ааа ааа
ввв ввв ввв


не могу разобраться почему без помеченой знаками (!) строчке
вторая строка не прибавляется в st, а с ней все работет
замечательно. 

надо инициализировать переменную ch в ф-ии read_string (например нулём).
иначе её значение после первого вызова read_string не сбрасывается и остается равным 10

а также добавить условие окончания файла. например 

не согласен ch локальная переменная и после выхода из ф-ии перестает существовать, а при входе заново создается..
Просто компилятор постоянно "глючит" если пытается использовать неинициализированную переменную

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

Добавлено @ 18:31 
понятия "перестает существовать" и "заново создается" существуют только в теории. на практике все несколько иначе.

конечно же вероятность существует, только очень призрачная.. Специально проверил ,5 раз вызывад ф-ю и не разу она не повторил значение переменной которым была проин. переменная внутри ф-ии!!!Неиниц. переменная помещается в регистр ,а не вынемается из него так что вероятность очень мала  
Слышали про такое понятие "Время жизни переменной"??

Конечно же разработчики компиляторов подлые лгуны, а книги пишут полные ламеры  

не раскажете как??





Это сообщение отредактировал(а) vinter - 9.8.2006, 19:17

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

то есть сами данные неизменны, изменяется SP, значение ch сохраняется при втором вызове
так что baronp прав

Добавлено @ 20:28 

в случае с POD-типами - просто изменение SP и контроль за использованием вне области видимости на этапе компиляции
в случае с объектами - вызов деструктора

А стек тут причем??? неинициализированная переменная помещается не в стек , А в РЕГИСТР

где написано?
а тут

регистров не хватит   
объекты тоже в регистры засовывать?   

Это сообщение отредактировал(а) MAKCim - 9.8.2006, 20:38

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

А это что такое(просто не знаю)?

спорный вопрос все-таки...

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


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

dumb мы на "ты" не переходили  
почитайте вот это

можно узнать откуда такие сведения(для собственного просвещения)

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

vinter, 
Прикрепи сюда ассемблерный листинг этой программы твоего компилятора, тогда и спорам конец.

вот есть кусок кода:

попробуйте посмотрите при отладке значение переменной...у меня оно ни разу не установилось в 10 при опред. без инициализации

vinter, где тут видно что

записывает в сегмент данных
адрес куда указывает ch неизвестен (может быть он стековый)
а сама ch в сегменте данных

На сколько я помню если в скобках не указаны [bp] или [sp] по умолчанию префиксом ставится сегмент данных...отсюда и мои выводы

vinter,

[off]мне никуда переходить не надо - так принято в сети. но если Вы настаиваете... имейте ввиду: тон такого общения считается "напряженным", а "выкающий" собеседник выдает в себе высокомерие, либо агрессивный настрой, даже если на самом деле это не так.[/off]


попробуйте еще раз перечитать предложение и подумать над его смыслом.


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


итак, человек, который пытается доказывать "призрачные вероятности", используя при этом Debug версию, отправляет меня читать Как пережить release-версию!


занавес!


чтобы не было таких "непоняток", переменные надо называть bp и sp. 
а память хорошая. даже слишком. мы уже давно живем в 32-битном мире. пытаемся даже на 64 переползти... 

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

vinter, а как Вы себе представляете применение операции взятия адреса (file.read((char*)&ch, 1);) к переменной, находящейся в регистре  


Это сообщение отредактировал(а) Damarus - 11.8.2006, 07:39

Для такого кода

g++ выдал одно "левое" число и четыре десятки.

OK 

никак.. прочитал статью там так написано..

а тебе прочитать тяжело было?? Там как раз и написано про оптимизацию!

я как раз и доказывал отсутствие данной верятности!

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

Visual c++ 6.0,VS 2003 .NET и BC 3.1 все выдали постороннее значение  

Но одно и тоже, исключая первое 

Добавлено @ 10:06 
Во...

у меня во всех случаях -858993460 при Debug  и 1 при Release 
с cout'ом в bc 3.1 так же как у baronp 


Это сообщение отредактировал(а) vinter - 11.8.2006, 10:44

vinter,
читать, то что пишут, надо, а не комментировать.
ты постоянно аппелируешь к результатам, которые тебе выдает debug версия проекта. а в той статье как-раз написано про проблемы, возникающие при переходе от дебага к релизу. одной из них и посвящен этот топик - неинициализированные переменные. тут читай внимательно: debug версия собирается с ключами, заставляющими компилятор генерировать код, заполняющий выделенное под переменные место определенными значениями. инициализирует он все переменные значением 0xCC, дабы проще было ловить оставленные без инициализации. в release версии нет этого кода! - в переменных содержится мусор, который остался от работы других переменных, адресов возврата, параметров функций итд - все, что помещается в стэк(мы говорим о локальных переменных)

твое -858993460 и есть 0xCCCCCCCC. собери уже наконец release версию любого из приведенных здесь исходников.

Добавлено @ 10:53 
пока писал, похоже, произошло чудо... 

dumb а сразу не мог аргументировать свои ответы...Всем спасибо что просветили   

Ну, вообще-то по стандарту использование неинициализированной переменной leads to undefined behavior. И это грубая ошибка. И даже если какой-то компилятор будет стабильно создавать ch в той же ячейке памяти, то все это делать определенно не будут - что сделает программу непортируемой и зависимой от типа/версии компилятора. 

Плюс, действительно некоторые компиляторы, вроде msvc действительно инициализируют все неинициализированные переменные 0 при Debug сборке  Но расчитывать на это...


Это сообщение отредактировал(а) Dragon - 11.8.2006, 12:29