Здравствуйте, Erop, Вы писали:
A>>а вызов IsSuccessBuilded кто верифицирует и обеспечивает?
E>В смысле? E>Положим у нас есть какой-нибудь NothrowFile, и у него есть IsOpen() E>Скажем, если мы пытаемся читать из неоткрытого файла, то нам вернут код ошибки и "прочитают" 0 байт...
или испортят кусок памяти, или еще что нибудь.
Здравствуйте, Abyx, Вы писали:
E>>Скажем, если мы пытаемся читать из неоткрытого файла, то нам вернут код ошибки и "прочитают" 0 байт... A>или испортят кусок памяти, или еще что нибудь.
Зачем портить кусок памяти?
И почему остальной код не портит, в таком случае?..
Я, ещё раз повторяю, что я лично гуглические соглашения не использую, но как-то писал для них немного кода и был вынужден учитывать. И ничего ужасного в них не вижу тоже.
Ну просто немного иные типичные решения будут, но в целом всё примерно тоже самое.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, -n1l-, Вы писали:
N>>Вот конвенции кода гугла. N>>Как вам? Кто-нибудь использует? Или есть какие-то другие более распространенные? Например мелкомягких? N>>Дискасс
J>256 обсуждали уже, воспользуйся поиском, плиз.
Нононо!!!
Тут обсуждение C++ code convention, а не google code convention.
Эти я привел как пример, что бы посмотреть на реакцию, стоит ли их брать в арсенал или нет.
Здравствуйте, -n1l-, Вы писали:
J>>256 обсуждали уже, воспользуйся поиском, плиз.
N>Нононо!!! N>Тут обсуждение C++ code convention, а не google code convention. N>Эти я привел как пример, что бы посмотреть на реакцию, стоит ли их брать в арсенал или нет.
Ну я и говорю — воспользуйся поиском — там вся реакция "отлита в граните".
Переводя на русский их аргументы: "в гугле уже накопилось порядочное количество говнокода, которое небезопасно с точки зрения исключений, однако вместо того чтобы изолировать его и начать писать новый код по-человечески мы решили продолжить говнокодить"
Здравствуйте, artem.komisarenko, Вы писали:
AK>Здравствуйте, jazzer, Вы писали:
J>>Поскольку уже обсуждалось, я просто брошу линк на туда J>>http://www.rsdn.ru/forum/cpp/4621003?tree=tree
AK>Переводя на русский их аргументы: "в гугле уже накопилось порядочное количество говнокода, которое небезопасно с точки зрения исключений, однако вместо того чтобы изолировать его и начать писать новый код по-человечески мы решили продолжить говнокодить"
Здравствуйте, rusted, Вы писали:
R>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, Vlad_SP, Вы писали:
V_S>>>Угу. Прости-прощай new, теперь будет malloc/free наше все. E>>открой для себя таки new(nothrow)
R>Только вот писатели c++ кода для гугла его похоже еще не открыли. Во всяком случае, когда я был вынужден воспользовался protocol buffers, там никаких nothrow не было, просто new и без всяких попыток ловить исключения хоть где-нибудь.
а попытки проверить, что вернулось что-то валидное там были? или тоже нет? (как и в leveldb) -- типа память это ресурс который есть всегда! )
Здравствуйте, artem.komisarenko, Вы писали:
AK>Просто пара цитат: AK>
All parameters passed by reference must be labeled const
Ну на самом деле что-то в этом есть — doSomething(a) — не ясно, поменяется ли a, пока не посмотришь ее объявление. doSomething(&a) — наводит на размышления об этом.
AK>
Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h.
Собственно почему бы и нет? Мешанина инклюдов неудобна
AK>
Здравствуйте, rusted, Вы писали:
R>Только вот писатели c++ кода для гугла его похоже еще не открыли. Во всяком случае, когда я был вынужден воспользовался protocol buffers, там никаких nothrow не было, просто new и без всяких попыток ловить исключения хоть где-нибудь.
Тут в чистом виде применима аргументация Касперски, по поводу проверки результата malloc: если твоему приложению нужна память, но выделить ее в куче не получилось, то и пусть оно сдохнет, что тут еще сделаешь? Вот (вымышленный пример из реальной жизни) графический редактор пытается создать диалоговое окно "Сохранить файл", а памяти под него уже не хватило — все ушло на открытые файлы. И — что дальше? Исключения — это простой, всем понятный и неправильный ответ на сложный вопрос обработки ситуации с нехваткой памяти.
Люди! Люди, смотрите, я сошел с ума! Люди! Возлюбите друг друга! (вы чувствуете, какой бред?)
Здравствуйте, slava_phirsov, Вы писали:
_>Тут в чистом виде применима аргументация Касперски, по поводу проверки результата malloc: если твоему приложению нужна память, но выделить ее в куче не получилось, то и пусть оно сдохнет, что тут еще сделаешь? Вот (вымышленный пример из реальной жизни) графический редактор пытается создать диалоговое окно "Сохранить файл", а памяти под него уже не хватило — все ушло на открытые файлы. И — что дальше? Исключения — это простой, всем понятный и неправильный ответ на сложный вопрос обработки ситуации с нехваткой памяти.
Я не знаю что такое "аргументация Касперски", но вообще в случае нехватки памяти чаще всего сделать можно много чего, и тупое падение благодаря третье-сортной библиотеке тут далеко не лучший вариант.
Из менее вымышленных и более реальных примеров: мы обрабатываем какие-то большие и сложные данные, по мере готовности результат кусками сериализуется куда-то с помощью тех же protocol buffers. В один прекрасный момент кусок данных результата получается слишком жирным и какое-то выделение памяти внутри protobuf кидает исключение. Если б гуглокодеры помнили о такой возможности, мы могли бы эту ситуацию отловить (хоть исключениями, хоть какими другими гуглоугодными способами) и попытаться этот кусок данных результата обработать по частям (или даже просто пропустить его, если задача такое позволяет). Но сложилось так, как сложилось — new кинул исключение, о возможности которого библиотека не в курсе — и даже если мы в своем коде его поймаем, то все равно мы можем только гадать, где и какие ресурсы внутри библиотеки утекли и в каком состоянии осталось то, что осталось. И в таком состоянии действтельно только и остается, что упасть пустив коту под хвост всё, что наобрабатывали до этого.
Возможно исключения это не самый простой способ обработки нехватки памяти, возможно даже, что иногда это не правильный способ. Но вот простое игнорирования существования исключительных ситуаций — это как раз самый худший вариант.
Здравствуйте, zaufi, Вы писали:
R>>Только вот писатели c++ кода для гугла его похоже еще не открыли. Во всяком случае, когда я был вынужден воспользовался protocol buffers, там никаких nothrow не было, просто new и без всяких попыток ловить исключения хоть где-нибудь.
Z>а попытки проверить, что вернулось что-то валидное там были? или тоже нет? (как и в leveldb) -- типа память это ресурс который есть всегда! )
Проверять вылет исключения им же их конвенция запрещает, а других способов сигнализации для кидающего new не предусмотрено. Так что да, видимо считают что памяти хватит всем.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, artem.komisarenko, Вы писали:
AK>>Просто пара цитат: AK>>
All parameters passed by reference must be labeled const
E>Ну на самом деле что-то в этом есть — doSomething(a) — не ясно, поменяется ли a, пока не посмотришь ее объявление. doSomething(&a) — наводит на размышления об этом.
И действительно, сложно понять:
convert(source, destination);
вот так гораздо понятнее и красивее, благодаря симметрии:
convert(source, &destination);
а внутри метода так вообще теперь раздолье, хочешь
if (destination)
а хочешь так и
assert(destination);
и мозги хорошо тренирует, ведь при вызове теперь надо думать, а можно ему нулевой указатель скормить или не стоит? а если можно нулевой, там проверка внутри (какая? съест или асертнет?) или параметр опциональный?
E>Собственно почему бы и нет? Мешанина инклюдов неудобна
Потому что все нормальные люди инклудят в противоположенном порядке
AK>>
Use cpplint.py to detect style errors
E>Не пользовался, но почему бы и нет?
А попробуйте Реальной полезности — 2% от -W4 и 3% от -Wextra, зато "лишних" строк и пробелов не там где надо сразу целую кучу наловит. Еще оно на стримы ругается, они гуглевым стандартом тоже запрещены.
Впрочем, // NOLINT решает.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, artem.komisarenko, Вы писали:
AK>>Просто пара цитат: AK>>
All parameters passed by reference must be labeled const
E>Ну на самом деле что-то в этом есть — doSomething(a) — не ясно, поменяется ли a, пока не посмотришь ее объявление. doSomething(&a) — наводит на размышления об этом.
Распространенное ошибочное рассуждение (и часто встречающееся в спорах Си против С++, где Си якобы лучше, потому что там по амперсанду сразу видно, что передается указатель, а значит, объект по указателю может быть изменен). Чтоб увидеть ошибку, достаточно просто рассмотреть еще один уровень вложенности вызовов — внезапно все амперсанды куда-то пропадают.
Здравствуйте, landerhigh, Вы писали:
V>>Почему религиозное, может и специфическое железо ограничения накладывать.
L>Ага. AVR-ки какие-нибудь с 512 килобайтами. Да и там по исключению можно просто ребут устраивать, есличо.
строго говоря С++ исключения к железу никакого отношения не имеют, и могут быть реализованы полностью программно, как например SJLJ-исключения.
L>>Ага. AVR-ки какие-нибудь с 512 килобайтами. Да и там по исключению можно просто ребут устраивать, есличо.
A>строго говоря С++ исключения к железу никакого отношения не имеют, и могут быть реализованы полностью программно, как например SJLJ-исключения.
(зевая) Да это давно понятно, что имеется в виду скорее "C++ компилятор для данной платформы не поддерживает исключения".
Здравствуйте, rusted, Вы писали:
R>Из менее вымышленных и более реальных примеров: мы обрабатываем какие-то большие и сложные данные, по мере готовности результат кусками сериализуется куда-то с помощью тех же protocol buffers. В один прекрасный момент кусок данных результата получается слишком жирным и какое-то выделение памяти внутри protobuf кидает исключение. Если б гуглокодеры помнили о такой возможности, мы могли бы эту ситуацию отловить (хоть исключениями, хоть какими другими гуглоугодными способами) и попытаться этот кусок данных результата обработать по частям (или даже просто пропустить его, если задача такое позволяет).
А, казалось бы, просто бей слишком большие данные ВСЕГДА. Ну типа сколько данных вам надо в порции МИНИМУМ, что бы ещё не просесть по производительности? Вряд ли больше, чем пара метров наверное, да? Ну вот максимум метров по 10 прокачивайте, и, волшебным образом и памяти жрать меньше будете и ООМ никогда не получите...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, rusted, Вы писали:
R>Я не знаю что такое "аргументация Касперски"
Ну кто же не помнит старика Крупского? Крис в одной из статей, посвященных кодингу на C утверждал, что в большинстве случаев нет никакого интереса в том, чтобы проверять, сумел malloc выделить память, или не сумел. Потому что в большинстве случаев, если он не сумел найти память, то с этим уже ничего и нельзя поделать — не судьба-с.
R>Из менее вымышленных и более реальных примеров
Ви таки будете смеяться, но приведенный пример вполне реален и ничуть не вымышлен.
R> мы обрабатываем какие-то большие и сложные данные...
А что конкретно может поделать гугловский код? Вот что конкретно может он сделать кроме кидания клиенту bad_alloc из глубины стека вызовов? Предложи!
R>Возможно исключения это не самый простой способ обработки нехватки памяти, возможно даже, что иногда это не правильный способ. Но вот простое игнорирования существования исключительных ситуаций — это как раз самый худший вариант.
Игнорирование — это когда
try
{
// ... что-то делаем
}
catch(...)
{
// ... а ничего не делаем, просто поймали, чтобы не вылетело дальше
}
А вот, когда исключение честно отпускается наверх со словами "ну кончилась у меня куча" (ну и, разумеется, с чисткой ресурсов ит.п.) — это уже не игнорирование. Это уже суровая необходимость (необходимость в том случае, если вы действительно ничего не можете с этим поделать). В ряде частных случаев поделать что-то да можно, но, увы не всегда: потенциально bad_alloc может выкинуть и конструктор строки (QString, std::string, ... — он ведь буфер в куче делает, или как?), и вообще любой класс, эксплуатирующий идиому PImpl (а где он тот самый Impl создаст?).
Люди! Люди, смотрите, я сошел с ума! Люди! Возлюбите друг друга! (вы чувствуете, какой бред?)
)
