LINUX.ORG.RU
 
MuZHiK-2

Разрешено использование C++ в GCC


0

1

Вчера в списке рассылки GCC появилось важное сообщение по поводу использования языка программирования C++ при разработке GCC (GNU Compiler Collection, а не сам компилятор языка C).

>>-----Цитата---->>

Марк Митчелл (Mark Mitchell), один из основных разработчиков GCC:

Я рад сообщить, что руководящий комитет GCC и FSF одобрили использование C++ в самом GCC. Конечно, нет никаких причин использовать возможности С++ только потому, что мы умеем это делать. Главная цель - предоставить пользователям более качественные компиляторы, а не кодовую базу на C++ для самих себя.

Перед тем, как мы действительно начнём использовать C++, мы должны определиться с набором правил, которыми нужно будет руководствоваться при использовании C++ для разработки GCC. Я считаю, что для начала мы должны минимизировать список разрешённых возможностей С++, чтобы не подвергать разработчиков GCC, не знакомых с C++, таким резким переменам в основном языке разработки компиляторов. Мы всегда сможем расширить использование С++ позднее, если появится такая необходимость.

<<-----Цитата----<<

На данный момент разработчики ограничиваются стандартом C++98 и использованием типа long long для 64-битных целых чисел. Использование множественного наследования, шаблонов (тех, которые не входят в стандартную библиотеку C++) и исключений, скорее всего, будет запрещено. Это мотивировано тем, что это будет сложно для программистов на C, а также тем, что сами программисты C++ могут с лёгкостью допустить ошибки в таких вещах.

Так как язык C++ достаточно обширен, то Марк Митчелл предложил составить список того, что разрешается использовать, а не того, что использовать нельзя. На данный момент необходимо составить некоторые информационные нормативы, а не очередной стандарт ISO.

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

>>> Официальный анонс


[#] Ответ на: комментарий от JackyTreehorn 03.06.2010 18:52:18  
oh

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

()
[#] Ответ на: комментарий от anonymous 03.06.2010 18:50:10  
rtvd

> int setValue(...,...) { return UNKNOWN_VALUE; }

Пример непонятен.

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

*** ()
[#] Ответ на: комментарий от anonymous 03.06.2010 18:50:10  
r

>Дальше при компиляции при замене этого вызова новыми тут же проверяется используетя ли возвращаемое значение.

О май год.

Используется - в каждом месте где вызывалось - стоит проверка. Нука зарефактори.


***** ()
[#] Ответ на: комментарий от rtvd 03.06.2010 19:29:09  

>> int setValue(...,...) { return UNKNOWN_VALUE; }

> Пример непонятен.

> Будьте добры продемонтрировать код до рефакторинга и после. В том числе то, как изменятся вызовы setValue.

Забванов. :)

Все то же самое:

int setValue (String name, int value) { if (name.equals("height")) { _height = value; return; } if (name.equals("width")) { _width = value; return; } return UNKNOWN_VALUE; }

переводится в

void setHeight(int arg) { _height = arg; } void setWidth (int arg) { _width = arg; }

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

С исключениями:

int setValue (String name, int value) { if (name.equals("height")) { _height = value; return; } if (name.equals("width")) { _width = value; return; } throw UNKNOWN_VALUE; }

переводится в

void setHeight(int arg) { _height = arg; }

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

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

anonymous ()
[#] Ответ на: комментарий от r 03.06.2010 19:38:01  

>> Дальше при компиляции при замене этого вызова новыми тут же проверяется используетя ли возвращаемое значение.

> О май год.

> Используется - в каждом месте где вызывалось - стоит проверка. Нука зарефактори.

Так в ручную и убираешь. С исключениями хрен найдешь где убирать.

anonymous ()
[#] Ответ на: комментарий от r 03.06.2010 17:53:29  

>> Mono C# долгое время реализовывал только подмножество C#

> 27 лет?:)

Первый _стандарт_ Си++ - это 1997 год, какие еще 27 лет? %)

> Сейчас mono C# реализцет стандарт С# 1.0/C# 2.0.

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

> столько компаний которые вбухали в это дело столько бабла - мигель столько и представить не может.

Не знаю. А если учесть, что в .NET мигель занимался повторной реализацией платформы, в которую M$ вбухал миллиарды... думаю, Си++ такие деньги просто не снились.

> А где воз?

Сколько компиляторов Си++ на свете? А сколько C#? Вот там и воз.

***** ()
[#] Ответ на: комментарий от anonymous 03.06.2010 19:40:20  
rtvd

> int setValue (String name, int value) { if (name.equals("height")) { _height = value; return; } if (name.equals("width")) { _width = value; return; } return UNKNOWN_VALUE; }int setValue (String name, int value) { if (name.equals("height")) { _height = value; return; } if (name.equals("width")) { _width = value; return; } return UNKNOWN_VALUE; }

Сила. А теперь вопрос к автору кода: что вернет эта функция, если первый аргумент - "height". :)

Далее.. Примера того, как изменится код вывода не было приведено. Вместо этого был процитирован мой же код. :)

Далее.. То, что в плюсах хреново с статическим анализом кода в случае исключений, не значит что в Java так же плохо. Особенно, когда речь идет о checked exceptions, которыми и пользуются люди.

> В процессе разработки отложенная работа имеет свойство накапливаться приводя усложнению разработки.

Абсолютно точно. Особенно если "отложенная работа" это работа мозга.

*** ()
[#] Ответ на: комментарий от anonymous 03.06.2010 19:40:20  
r

>переводится в

А куда делся return UNKNOWN_VALUE? Или у тебя рефакторинг тул - это китаец который знает что этот код не понадобитиься? Или у IDE прямой контакт с господом?

> setValue сразу проверяется обрабатывается ли значение кода ошибки.


Значение ошибки обрабатывается.

было if (setValue("width", 100) != UNKNOWN_VALUE) {....}

стало...?

Нука напиши?

>При рефакторинге выясняй, десятью уровнями выше это исключение обрабатывают или от другой функции кидающей такое же исключение.


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

В случае же статумсами нам вообще в каждом вызове бессмысленный мусор.

PS: Ты вот это компилить то пробовал:

int setValue (String name, int value) { if (name.equals("height")) { _height = value; return; } if (name.equals("width")) { _width = value; return; } return UNKNOWN_VALUE; }

Попробуй. Увидишь какую чушь написал.





***** ()
[#] Ответ на: комментарий от anonymous 03.06.2010 19:42:20  
r

>Так в ручную и убираешь.

Правда! Ты вообще семантически эквивалентный нормальный код без исключенйи не сгенеришь.

Была проверка на статус код. У методов типа setWidth return type - void. Ты вообще пока не показал как это семантически эквивалентно преобразовать.

Был if (setValue("width",...)) где setValue возвращал int. Теперь там setWidth возвращающий void. Нука нука опиши формальное преобразование, и что там за некомпилящийся бред в результате?


***** ()
[#] Ответ на: комментарий от tailgunner 03.06.2010 19:52:10  
oh

Ты дебил или притворяешься?
Для C# есть МСовская хрень, полностью реализующяя стандарт, для плюсов такой хрени нету.

()
[#] Ответ на: комментарий от oh 03.06.2010 18:11:03  
annulen

> Полный же язык, да и компиляторы, полностью реализующие спецификации есть.

с компиляторами плохо. есть один на насме, и кросс-платформенный инетерпретатор

** ()
[#] Ответ на: комментарий от r 03.06.2010 17:53:29  

> C++ пишут уже 27 лет. При чем столько компаний которые вбухали в это дело столько бабла - мигель столько и представить не может. А где воз?

А что не так с С++? 27 лет C++ живет потому что исключительно удачный и практичный язык, основа любой современной платформы. Состояние языка и компиляторов уже давно на высоком уровне, достаточно для решения большинства практических задач. Все эти вклады сил и бабла уже многократно себя оправдали, благодаря плюсам имеет большое количество высокопроизводительного удобного софта. Другие современный популярные языки такие как C#/Java заимствовали синтаксис C++ и многие удачные идеи что в очердной раз доказывает успешность C++. А что до тех кто пугает тем что можно отсрелить себе ногу какими-то конструкциями - ну дык, что вы хотели - не отказыватся же от путешествия на машине из-за того что в аварию можно попасть. Уже давно не сталкивался с тем чтобы трудности на проектах рождал бы сам язык.

()
[#] Ответ на: комментарий от r 03.06.2010 20:01:42  
rtvd

r, хотел бы пообщаться с Вами лично. Можете скинуть мне свою контактную информацию на rtvd собака mail.ru?

*** ()
[#] Ответ на: комментарий от oh 03.06.2010 20:35:53  

> Ты дебил или притворяешься?

Утипути, профессионалы ITT. ПНХ, чучело.

***** ()
[#] Ответ на: комментарий от tailgunner 03.06.2010 21:35:21  
oh

по делу нечего ответить? Правльно, соси дальше

()
[#] Ответ на: комментарий от tailgunner 03.06.2010 19:52:10  
r

>Первый _стандарт_ Си++ - это 1997 год, какие еще 27 лет?

Первый ISO стандарт С++. Java ISO не стандартизирована - это не обозначает что на нее нет стандарта.

27 лет с момента появления компилятора С++ - 1983 год.

>Ну то есть ты тоже понимаешь, что компиляторщики реализуют то, что могут и считают нужным, а не то, что говорит стандарт.


Обычно существует как минимум одна реализация языка которая удовлетворяет его спеке - зачастую это от источника языка. В данном случае не существует ни одной. О чем это говорит?

И второй вопрос - если получается что язык С++ как определено в стандарте _никому_ не нужен - зачем же стандарт разрабатывают никому не нужный?

>А если учесть, что в .NET мигель занимался повторной реализацией платформы, в которую M$ вбухал миллиарды...


Мигель осилил с с кучкой людей то во что MS вбухал миллиарды. Вывод - C# вполне осиливаемое для кучки людей. С++ неосиливаемое даже для корпораций типа MS которые если надо могут в бухать миллиарды.

>Сколько компиляторов Си++ на свете? А сколько C#? Вот там и воз.


Это к чему еще? Они что всех разработчиков разделили и никому не хватило или что? Или отдельновзятый интел не может справиться?

Без разницы. Компиляторы С# - стандартные. Все 2. Компиляторы С++ нестандартные. Все что есть:)

***** ()
[#] Ответ на: комментарий от r 03.06.2010 22:02:39  

> 27 лет с момента появления компилятора С++ - 1983 год.

Что-то я запутался - речь о стандартах или о первом компиляторе? %)

> Мигель осилил с с кучкой людей то во что MS вбухал миллиарды

Он осилил древний стандарт. _Древний_.

> Вывод - C# вполне осиливаемое для кучки людей. С++ неосиливаемое даже для корпораций типа MS

Слушай, ты сам-то в это веришь? Что компилятор Си++ для M$ был так же важен, как .NET и что Си++ прям таки корпорацией асиливали и ниасилели? :D

>>Сколько компиляторов Си++ на свете? А сколько C#? Вот там и воз.

> Это к чему еще?

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

> Компиляторы С# - стандартные. Все 2. Компиляторы С++ нестандартные. Все что есть:)

Доо. Два компилятора C# поддерживают 2 разных стандарта, офигеть стандартизация %)

***** ()
[#] Ответ на: комментарий от r 03.06.2010 22:02:39  

>Java ISO не стандартизирована - это не обозначает что на нее нет стандарта.

Нет стандарта ISO? Кому нужно это пионерское фуфло?

>27 лет с момента появления компилятора С++ - 1983 год.

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

>Обычно существует как минимум одна реализация языка которая удовлетворяет его спеке - зачастую это от источника языка. В данном случае не существует ни одной. О чем это говорит?

О том, что язык простой с урезанными возможностями.

>С++ неосиливаемое даже для корпораций типа MS которые если надо могут в бухать миллиарды

Количество вбуханных денег не коррелирует с качеством или сложностью продукта. Майкрософт может вбухать что угодно куда угодно и получить нестандартное глюкалово. Лучше посчитай сколько RMS вбухал в GCC.

*** ()
[#] Ответ на: комментарий от legolegs 03.06.2010 22:41:32  
oh

> О том, что язык простой с урезанными возможностями.
Ох лол,
ну да, так и есть. Все языки, кроме c++ - простые, с урезанными возможностями.

()
[#] Ответ на: комментарий от tailgunner 03.06.2010 22:19:24  
r

>Что-то я запутался - речь о стандартах или о первом компиляторе? %)

Это анонимуса спроси. Речь про то что на сегодняшний день нет компилятора реализующего стандарт.

>Он осилил древний стандарт. _Древний_.


В каком смысле древний? Отстают от ms. А когда осилят хоть какой нить стандарт С++? Хоть с++98?

>Слушай, ты сам-то в это веришь? Что компилятор Си++ для M$ был так же важен, как .NET и что Си++ прям таки корпорацией асиливали и ниасилели? :D


Нет. Компилятор С++ для мс был важен. Даже сейчас важен - учитывая что развивается. И несовместим он со стандартом не потому что лениво делать ненужных вещей, а наоборот потому что чтобы соблюсти стандарт нету никаких сил и стоит это огромных бабок.

Например нахер никому ненужный strictfp в жабе почему-то не напрягло никого реализовывать - ибо стандарт.

Точнее сформулируем что если язык такой что для корпораций типа мс или интел встает вопрос о том что лучше нахер этот стандарт чем так корячится - это характеризует язык.

>Два компилятора C# поддерживают 2 разных стандарта, офигеть стандартизация %)


А что тут такого? Один отстает - допилят будет поддерживать. Все нормально. Покажи мне хоть один С++ компилятор который поддерживает хоть один стандарт.

***** ()
[#] Ответ на: комментарий от legolegs 03.06.2010 22:41:32  
r

>Нет стандарта ISO? Кому нужно это пионерское фуфло?

Тем хто не фапает на вывески.

>Все эти 27 лет язык развивался.


На бумажке. Реализаций до сих пор нет.

>О том, что язык простой с урезанными возможностями.


Ну да конечно. Все остальные в%ебывают по спецификации как дураки. А вот оно как надо - забить на спеку и делать что хошь. И нафига тогда форкгроуп карачится - на них же все плюют.

***** ()
[#] Ответ на: комментарий от r 03.06.2010 23:14:07  
oh

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

()
[#] Ответ на: комментарий от r 03.06.2010 23:11:37  

>>Слушай, ты сам-то в это веришь? Что компилятор Си++ для M$ был так же важен, как .NET и что Си++ прям таки корпорацией асиливали и ниасилели? :D

>Нет.

Ну так и нефиг.

> Компилятор С++ для мс был важен.

Важно было, чтобы он был. Его соответствие стандартам особо никого не колебало. Так же, как M$ нужна была своя Java.

> Один отстает - допилят будет поддерживать. Все нормально. Покажи мне хоть один С++ компилятор который поддерживает хоть один стандарт.

Что я люблю в стандартах - всегда есть из чего выбрать (с)

Кстати, как там с поддержкой трижды насквозь расово верного C99? %)

***** ()
[#] Ответ на: комментарий от tailgunner 03.06.2010 23:32:42  
r

>Так же, как M$ нужна была своя Java.

MSовская жава вполне соответствовала (не была реализована только RMI библиотека). Конфликт вышел по причине MSовских расширений и бренда.

>Его соответствие стандартам особо никого не колебало.


Ты сам то веришь, что конторы которые реализуют компилфторы совсем непарятся соответствием языка - спецификации?

>Кстати, как там с поддержкой трижды насквозь расово верного C99?


http://gcc.gnu.org/gcc-4.5/c99status.html

***** ()
[#] Ответ на: комментарий от r 04.06.2010 0:46:42  

> MSовская жава вполне соответствовала (не была реализована только RMI библиотека). Конфликт вышел по причине MSовских расширений и бренда.

Об этом и речь - кто-то попытался расширить Яву под свои нужды и получил по рукам. А вот Си++ расширяли все, кому не лень.

> Ты сам то веришь, что конторы которые реализуют компилфторы совсем непарятся соответствием языка - спецификации?

Да. Они парятся над стандартами де-факто (ситуация с C99 как бы намекает).

>> Кстати, как там с поддержкой трижды насквозь расово верного C99?

> http://gcc.gnu.org/gcc-4.5/c99status.html

Так и запишем - стандарт C99 не реализован уже 11 лет. Бида, бида, мы все умрем.

***** ()
[#] Ответ на: комментарий от tailgunner 04.06.2010 0:50:38  
r

>Об этом и речь - кто-то попытался расширить

Ненене - речь не об этом. Речь о том что жабу реализовали стандарт. А в С++ стандарт не реализовал никто. В итоге либо стандарт никому не нужен - и тогда в воркгруппе шизофреники, или он слишком сложный для реализации, что есть факт который признают все.

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

>Да. Они парятся над стандартами де-факто


Значит твоя позиция в том что в воркгруп сидят дурочки и придумывают стандарт который никому не нужен?

>Бида, бида, мы все умрем.


Мы не умрем при многих условиях. Кое-кто выжил в бухенвальде. Это ж не значит что так жить хорошо.

***** ()
[#] Ответ на: комментарий от oh 03.06.2010 21:41:57  
JackyTreehorn

У тебя самого с этим "по делу" исчезающе мало.

* ()
[#] Ответ на: комментарий от r 03.06.2010 22:02:39  
JackyTreehorn

Формально говоря, ты прав. Но только формально ;)

* ()
[#] Ответ на: комментарий от r 04.06.2010 1:15:11  
JackyTreehorn

Если бы речь шла о нереализации существенной части стандарта, это имело бы вес.
Факты - это хорошо, но их толкование важнее.
- С++ - сложный язык? Да, с этим никто не спорит.
- Можно ли на нем писать хороший софт? Да, можно.
- Можно ли обойтись его частью, чтобы успешно делать хороший софт? Да, можно.
Некоторые предпочитают тупые ножи, потому что им так спокойнее. Так что теперь, выкинуть все острые?

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 12:34:01  
oh

> Некоторые предпочитают тупые ножи, потому что им так спокойнее. Так что теперь, выкинуть все острые?
Это тут при чем? "Тупые ножи" - это все, что не плюсы, да?

> Можно ли на нем писать хороший софт? Да, можно.

На любом полном языке можно писать хороший софт.

> Можно ли обойтись его частью, чтобы успешно делать хороший софт? Да, можно.


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

()
[#] Ответ на: комментарий от oh 04.06.2010 13:15:48  
JackyTreehorn

> Это тут при чем? "Тупые ножи" - это все, что не плюсы, да?
Я не виноват, что ты сачковал уроки русского языка и литературы.

> На любом полном языке можно писать хороший софт.

Покажи мне что-нить такое на твоем любимом брэйнфаке.

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

Конечно, можно. Но на С++ это будет удобнее и быстрее.

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 13:18:34  
oh

> Покажи мне что-нить такое на твоем любимом брэйнфаке.
У меня только 1 проект на нем, и то closed-source, так что сорри.

> Конечно, можно. Но на С++ это будет удобнее и быстрее.

В любой-любой ситуации?
В ынтерпрайзе можно юзать C# и на нем будет быстрее.

()
[#] Ответ на: комментарий от oh 04.06.2010 15:31:31  
JackyTreehorn

> У меня только 1 проект на нем, и то closed-source, так что сорри.
Ага, я так и думал.

> В любой-любой ситуации?

> В ынтерпрайзе можно юзать C# и на нем будет быстрее.

Ты за контекстом совсем не следишь или просто пухнешь на глазах? ;)

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 15:40:02  
oh

Ок, я правда не очень хорошо сформулировал ответ.
Вот так вот:
на C++ не всегда будет "удобнее и быстрее", чем на C. Плюс ко всему, всегда найдется язык, на котором разработка для конкретной задачи будет удобнее и быстрее, в сравнении с плюсами

()
[#] Ответ на: комментарий от oh 04.06.2010 15:51:21  
JackyTreehorn

> на C++ не всегда будет "удобнее и быстрее", чем на C.
Пример?

Со вторым я соглашусь, пожалуй...

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 15:53:44  
oh

Системные вещи. Embedded штучки (портировать библиотеки плюсов а какое-нибудь устройство, наверное, будет геморрно).

()
[#] Ответ на: комментарий от oh 04.06.2010 15:57:57  
JackyTreehorn

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

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 16:01:53  
oh

ну вот - системные вещи. Условия вроде одинаковые, не?

()
[#] Ответ на: комментарий от oh 04.06.2010 16:26:37  
JackyTreehorn

Если нет требования "максимальная скорость + минимальный оверхед".

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 16:33:35  
oh

допустим

()
[#] Ответ на: комментарий от oh 04.06.2010 16:53:11  
JackyTreehorn

Ну и в чем тогда проявляется преимущество голого С?

* ()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 16:53:50  
oh

На нем быстрее и удобнее разработка, из-за отсутствия костылей

()
[#] Ответ на: комментарий от JackyTreehorn 04.06.2010 23:09:04  
oh

я подумал тут, в общем вы наверное правы. Разве что сейчас r не прийдет :)

Вообще, хорошо, что сошлись, поговорили.
А то вон там ----> http://www.linux.org.ru/forum/development/4968593/\
только-только начали

()
[#] Ответ на: комментарий от oh 05.06.2010 0:10:49  
r

Пошел я смотреть на этот qross. Пошел глянуть на тест:

http://github.com/0xd34df00d/Qross/blob/master/src/qross/test/main.cpp

54 readFile....

проверка есть только на f.open

65. f.readAll не проверяется - а ведь может не прочитаться.

...

Смотрим где используется

70 runScriptFile

ага - проверяется прочитался ли файл и если нет ту же ошибку наверх.

Два соображения:

1. это что все ошибки в природе будут перечислены в одной иерархии? Эй шеф какие номера заняты? "И на этом можно писать большие программы" (C)....?

2. результат runScript проверяется в 151 main. То есть грубо говоря ошибка которая возникла в глубокой функции по всему стеку вызовов проверяется и выносится кодом в самый верх. Кто там говорил про экономию места на кошках? По ходу получается одну и ту же проверку надо делать в каждом методе по стеку вызовов.

А теперь вернемся к readAll и почему это IO операция взруг стала "безопасной". Обратимся для этого к доке по qt:

This function has no way of reporting errors; returning an empty QByteArray() can mean either that no data was currently available for reading, or that an error occurred.

ОхyETb бля. И может у вас диск сбоит или сетевая шара отпала, а может просто файл пустой.

И это в таком мегафреймворке как Qt! Потенциально ошибочные IO операции забивающие на ошибки.

Зачем исключения говорите?


***** ()
[#]  
erfea

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

** ()