Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonschiВ свое время очень впечатлил пример рефакторинга кода Рихтера в progstone http://progstone.narod.ru/reciprocality/r0/day2.html Мне кажется что глубокие рассуждения о пользе или вреде нулевого факториала ведут нас к базовым аксиомам чисел. (Старик Гёдель ехидно улыбается с портретов.) Как определили функцию так она и "поплыла". Ничего мы фундаментально не улучшим если даже лишим функцию области определения. А если заставим ее быть равной нулю при x=0 то потеряем некую рекурретную индуктивность. Во все формулы надо будет ввести if (...) которых защитит произведение от внезапного обнуления. Кроме того количество перестановок пустого множества предметов дает определенные философские допущения, улучшающие картину мира. Тоесть все вроде-бы логично. У нес есть ОДНА перестановка одного предмета. И ОДНА перестановка пустого множества предметов. Статью целиком не читал. Пробежал по диагонали. Жаль время терять на попытки искать сенсацию где ее нет. Уж лучше копать уфологию там или историю шестой расы. Продуктивнее будет.... мдя. Эту книгу надо целиком читать - полезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 09:19 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
White OwlschiДико извиняюсь, а зачем while (TRUE) ? Почему не Код: plaintext 1. 2. ?Потому что вызов этой функции уже очень длинный. Чисто для визуальщины - отдельно цикл, отдельно вызов функции, отдельно выход из цикла. Можно конечно написать и так как ты предлагаешь - меньше строк будет, но... Я просто предпочитаю не писать условие которое требует переноса на следующую сторку. Лучше уж завести несколько булевых переменных и вычислять их отдельно от if/while. Длина вызова функции несильно зависит от места расположения вызова. Лично меня всегда напрягают бесконечные циклы там, где без них можно обойтись. Но я никоим образом не навязываюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 09:21 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
White Owlнадо будет каждый вызов SQL* функции обернуть в отдельную функцию/метод типа: И что, руки отвалятся один раз такие оберки сделать? Да и print_odbc_error, это не обертка что ли? Двойные стандарты? White OwlА еще, в этом коде кучка ошибок :) Он не аналогичен моему... Я не нанимался отлаживать код. Вопрос был как будет выглядеть код на исключениях. Ответ получен. White OwlНо в большой программе далеко не всегда нужно обращать внимание на SQL_SUCCESS_WITH_INFO При необходимости этот вопрос решаются элементарно. Таким образом, код на исключениях выглядит намого проще и понятнее, потому что есть возможность элементарно отделить весь отладочный код от прикладного, и я этим воспользовался в этим примере. На кодах возврата это невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 10:18 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyWhite Owlнадо будет каждый вызов SQL* функции обернуть в отдельную функцию/метод типа: И что, руки отвалятся один раз такие оберки сделать? Да и print_odbc_error, это не обертка что ли? Двойные стандарты? White OwlА еще, в этом коде кучка ошибок :) Он не аналогичен моему... Я не нанимался отлаживать код. Вопрос был как будет выглядеть код на исключениях. Ответ получен. White OwlНо в большой программе далеко не всегда нужно обращать внимание на SQL_SUCCESS_WITH_INFO При необходимости этот вопрос решаются элементарно. Таким образом, код на исключениях выглядит намого проще и понятнее, потому что есть возможность элементарно отделить весь отладочный код от прикладного, и я этим воспользовался в этим примере. На кодах возврата это невозможно.По моему грустному опыту, попытки назвать "отладочным" код, остающийся в боевом экзешнике --- это обычно попытки обосновать меньшую тщательность отладки этого "отладочного" кода. А программулине и юзерам потом по барабану, как назывался тот код, который привёл к ошибке --- "отладочный" или ещё как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 10:49 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
schimaytonпропущено... Мне кажется что глубокие рассуждения о пользе или вреде нулевого факториала ведут нас к базовым аксиомам чисел. (Старик Гёдель ехидно улыбается с портретов.) Как определили функцию так она и "поплыла". Ничего мы фундаментально не улучшим если даже лишим функцию области определения. А если заставим ее быть равной нулю при x=0 то потеряем некую рекурретную индуктивность. Во все формулы надо будет ввести if (...) которых защитит произведение от внезапного обнуления. Кроме того количество перестановок пустого множества предметов дает определенные философские допущения, улучшающие картину мира. Тоесть все вроде-бы логично. У нес есть ОДНА перестановка одного предмета. И ОДНА перестановка пустого множества предметов. Статью целиком не читал. Пробежал по диагонали. Жаль время терять на попытки искать сенсацию где ее нет. Уж лучше копать уфологию там или историю шестой расы. Продуктивнее будет.... мдя. Эту книгу надо целиком читать - полезно. Сложно вести беседу, основываясь на ссылках на книги. В этом топике есть живые люди. Ораторы. И мне интересно Слышать их живое мнение. Я не буду против вашего резюмирования книги. И я готов его Обсуждать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 11:05 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyWhite Owlнадо будет каждый вызов SQL* функции обернуть в отдельную функцию/метод типа: И что, руки отвалятся один раз такие оберки сделать? Да и print_odbc_error, это не обертка что ли? Двойные стандарты? White OwlА еще, в этом коде кучка ошибок :) Он не аналогичен моему... Я не нанимался отлаживать код. Вопрос был как будет выглядеть код на исключениях. Ответ получен. White OwlНо в большой программе далеко не всегда нужно обращать внимание на SQL_SUCCESS_WITH_INFO При необходимости этот вопрос решаются элементарно. Таким образом, код на исключениях выглядит намого проще и понятнее, потому что есть возможность элементарно отделить весь отладочный код от прикладного, и я этим воспользовался в этим примере. На кодах возврата это невозможно. господи, ООП головного мозга в терминальной стадии, право. что элементарнее может быть NDEBUG и assert(), какие еще исключения? зачем придумывать на коленке еще одну кривую и косую реализацию деления на прикладной и отладочный код? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 17:57 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_ruПо моему грустному опыту, попытки назвать "отладочным" код, остающийся в боевом экзешнике --- это обычно попытки обосновать меньшую тщательность отладки этого "отладочного" кода. А программулине и юзерам потом по барабану, как назывался тот код, который привёл к ошибке --- "отладочный" или ещё как. Не надо утрировать. Средства диагностики в runtime (поддержка трассировочных и отладочных режимов) - это большое искусство, которому в школе вообще не учат. Тем более, после "релиза" просто так через gdb уже не походишь, целые куски за счет инлайнинга запросто становятся недоступными для пошаговой трассировки. Собственно когда говорят про необходимость удаления отладочного кода - это сразу выдает в собеседнике формошлепа из какого C++Builder или его аналога, который работает в условиях конечной недоступности среды выполнения, ему на эти инструментарии трассировки глубоко фиолетово. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 18:02 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
dbpatch, Интересно, что из моего комментария было написано так двусмысленно, что дало вам повод написать этот ответ? Особенно если коммент про код, остающийся в релизном экзешнике, а ответ --- про "говорят про необходимость удаления отладочного кода" (цвет мой). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 20:03 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 20:32 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
dbpatchчто элементарнее может быть NDEBUG и assert(), какие еще исключения? Ждем теперь реализацию того же кода на ассертах. Ну чисто чтоб поржать над убогими сишниками ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 21:20 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
dbpatchiv_an_ruПо моему грустному опыту, попытки назвать "отладочным" код, остающийся в боевом экзешнике --- это обычно попытки обосновать меньшую тщательность отладки этого "отладочного" кода. А программулине и юзерам потом по барабану, как назывался тот код, который привёл к ошибке --- "отладочный" или ещё как. Не надо утрировать. Средства диагностики в runtime (поддержка трассировочных и отладочных режимов) - это большое искусство, которому в школе вообще не учат. Тем более, после "релиза" просто так через gdb уже не походишь, целые куски за счет инлайнинга запросто становятся недоступными для пошаговой трассировки. Собственно когда говорят про необходимость удаления отладочного кода - это сразу выдает в собеседнике формошлепа из какого C++Builder или его аналога, который работает в условиях конечной недоступности среды выполнения, ему на эти инструментарии трассировки глубоко фиолетово. Судя по его тематике, у него просто другой уровень надёжности и отклика, в его случаях он как раз прав - роль отладочного кода играют тесты. Отладочные Non Zerro Cost механизмы в продакшн это обычно ширпотреб, дёшево и сердито - с которым как я понимаю он и не работал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2017, 22:33 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_ruAnatoly MoskovskyТаким образом, код на исключениях выглядит намого проще и понятнее, потому что есть возможность элементарно отделить весь отладочный код от прикладного, и я этим воспользовался в этим примере. На кодах возврата это невозможно.По моему грустному опыту, попытки назвать "отладочным" код, остающийся в боевом экзешнике --- это обычно попытки обосновать меньшую тщательность отладки этого "отладочного" кода. А программулине и юзерам потом по барабану, как назывался тот код, который привёл к ошибке --- "отладочный" или ещё как. А как бы вы назвали этот код? И как обычно называете остающийся в боевом экзешнике код, который обрабатывает серьёзные ошибки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2017, 17:59 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyWhite Owlнадо будет каждый вызов SQL* функции обернуть в отдельную функцию/метод типа: И что, руки отвалятся один раз такие оберки сделать? Да и print_odbc_error, это не обертка что ли? Двойные стандарты? Не надо путать обертки и вынос повторяющегося кода в функцию. Anatoly MoskovskyWhite OwlА еще, в этом коде кучка ошибок :) Он не аналогичен моему... Я не нанимался отлаживать код. Вопрос был как будет выглядеть код на исключениях. Ответ получен.Да, получен... Где-то так на троечку. Видно что студент что-то знает по теме, но задача решена все-же неправильно. Anatoly MoskovskyWhite OwlНо в большой программе далеко не всегда нужно обращать внимание на SQL_SUCCESS_WITH_INFO При необходимости этот вопрос решаются элементарно.И как именно? Добавлением параметра в обертку? Или выключением-включением verbose флага? Anatoly MoskovskyТаким образом, код на исключениях выглядит намого проще и понятнее, потому что есть возможность элементарно отделить весь отладочный код от прикладного, и я этим воспользовался в этим примере. На кодах возврата это невозможно.Ну с чего вдруг невозможно то??? Продемонстрированное отделение отладочного кода от прикладного основано целиком на обертке функции. Делаем обертку на кодах возврата и получаем точно ту-же функциональность что и "невозможна". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2017, 19:04 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Вася Уткинiv_an_ruпропущено... По моему грустному опыту, попытки назвать "отладочным" код, остающийся в боевом экзешнике --- это обычно попытки обосновать меньшую тщательность отладки этого "отладочного" кода. А программулине и юзерам потом по барабану, как назывался тот код, который привёл к ошибке --- "отладочный" или ещё как. А как бы вы назвали этот код? И как обычно называете остающийся в боевом экзешнике код, который обрабатывает серьёзные ошибки?Да никак :) Во-первых, серьёзная ошибка обрабатывается директором пользователя, когда он пишет вендору письмо, что не будет продлять лицензию, или непосредственно юзером, который в открытом мэйллисте посылает вендора к митохондриальной праматери. А код в экзешние может обрабатывать особые случаи. Во-вторых, у нас в русском устоялось кривое понимание exception как то "исключение", которое "чрезвычайное" или "диковинное", хотя вообще-то оно просто вариант из "правило-исключение", оно не более, чем "не самая последняя ветка" в дереве правил. Изначальную дею окончательно похоронил уродский синтаксис try-catch, в котором catch почему-то оказался после try, хотя в любой основанной на продукциях / правилах переписывания / name-it-yourself системе исключения из общих правил пишутся, само собой, перед общими правилами, просто потому, что условия для применения исключений проверяются до применения общего правила. В третьих, когда терминология успешно переведена с русского языка на русский, становится нагляднее простая мысль. Код для обнаружения/обработки особых случаев ничем принципиально не отличается от кода, работающего в случае, если ничего особого нет (либо если "особость" ситуации вовремя не обнаружена, и NULL-ёвый указатель на неоткрытый файл ехидно ухмыляется в ожидании fwrite()). И никакого особого названия он поэтому не требует, достаточно сказать, чем этот код занимается. Это может быть код журналирования событий, код монитора, код перераспределения ресурсов на лету, код системы кортроля доступа, код защиты данных от скрытой порчи, код для плавной деградации, код для того, код для сего или код для всего этого разом :) И только "отладочного" кода там нет, потому что он на одну половину обёрнут в #ifdef DEBUG, а на вторую --- в #ifndef NDEBUG, и в любом случае в релизе его вообще нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2017, 19:21 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Addxlog_hereПредполагается, что строк одинаково или почти одинаково, понятность тоже не отличается. Преимущества на C: думаю, скорость и большая универсальность (C понимают и некоторые другие языки). Преимущества на C++: больше всяких новинок (начиная с C++11), больше манёвров для изменений. Кто что думает? Замечательный критерий выбора ЯП - число строк и "понятность". Предлагаю: Например: f1(ln(число строк кода)) + f2(критерий понятности, от 1 до 10) меньше 1 - C, больше 1 - C++, а если единица - пиши на ассемблере. С предложениями опоздал. Есть в Метриках Холстеда: - Difficulty - Time to understand Кстати сорцы С и С++ с исключениями я-бы предложил прогнать через анализатор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2017, 19:58 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
White OwlНе надо путать обертки и вынос повторяющегося кода в функцию. Так в данном случае обертка имеет несколько назначений. Одно из них - это устранение дублирования кода. Потому что в оригинальном примере примерно половина кода - это дублирование конструкции Код: plaintext 1. 2. То, что вас это не смущает, и вы копипастите этот паттерн по всему проекту, вместо того чтобы вынести в функцию (тут даже не про исключения речь, а просто об элементарном повторном использовании кода), вполне объясняет ваше непонимание почему код, который, я привел, намного более простой, читаемый и сопровождаемый. Не удивлюсь если вообще большинство кода в ваших проектах - копипаста в индусском стиле. White OwlИ как именно? Добавлением параметра в обертку? Или выключением-включением verbose флага? Вы даже не хотите капельку подумать. Понимаю. Копипаста проще. Скопировал - отредактировал. Нафиг проектировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2017, 21:28 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Предлагаю не скатываться до обидок. Оба подхода имеют право на жизнь - квалификация спорщиков это только подтверждает. Тем не менее, подолью маслица в огонь - на каком фреймворке базируетесь - те методики и стоит применять. А если пишется с нуля - каждый себе господин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 00:31 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_ruВася Уткинпропущено... А как бы вы назвали этот код? И как обычно называете остающийся в боевом экзешнике код, который обрабатывает серьёзные ошибки?Да никак :) Во-первых, серьёзная ошибка обрабатывается директором пользователя, когда он пишет вендору письмо, что не будет продлять лицензию, или непосредственно юзером, который в открытом мэйллисте посылает вендора к митохондриальной праматери. А код в экзешние может обрабатывать особые случаи. Во-вторых, у нас в русском устоялось кривое понимание exception как то "исключение", которое "чрезвычайное" или "диковинное", хотя вообще-то оно просто вариант из "правило-исключение", оно не более, чем "не самая последняя ветка" в дереве правил. Изначальную дею окончательно похоронил уродский синтаксис try-catch, в котором catch почему-то оказался после try, хотя в любой основанной на продукциях / правилах переписывания / name-it-yourself системе исключения из общих правил пишутся, само собой, перед общими правилами, просто потому, что условия для применения исключений проверяются до применения общего правила . В третьих, когда терминология успешно переведена с русского языка на русский, становится нагляднее простая мысль. Код для обнаружения/обработки особых случаев ничем принципиально не отличается от кода, работающего в случае, если ничего особого нет (либо если "особость" ситуации вовремя не обнаружена, и NULL-ёвый указатель на неоткрытый файл ехидно ухмыляется в ожидании fwrite()). И никакого особого названия он поэтому не требует, достаточно сказать, чем этот код занимается. Это может быть код журналирования событий, код монитора, код перераспределения ресурсов на лету, код системы кортроля доступа, код защиты данных от скрытой порчи, код для плавной деградации, код для того, код для сего или код для всего этого разом :) И только "отладочного" кода там нет, потому что он на одну половину обёрнут в #ifdef DEBUG, а на вторую --- в #ifndef NDEBUG, и в любом случае в релизе его вообще нет. Ну вот, взяли и назвали часть какого-то кода: "Код для обнаружения/обработки особых случаев", хотя он ничем и не отличается от остального :) В общем-то да, это разные вещи: отладочный код одно, а код, который генерирует внятные сообщения для включения их пользователями в баг-репорты - это другое - логирование ошибок. Кстати, а как-то можно изменить синтаксис try-catch, чтобы программа сначала проверяла исключения из правил, а только потом выполняла правила - содержимое блока try? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 01:05 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Мне тоже кажется странным сетование Ивана по поводу блока catch? Что за принцип name-it-yourself? Как по его мнению должен выглядеть наш пример с ODBC ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 01:16 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonЧто за принцип name-it-yourself?Это не принцип, это просто оборот речи, "называйте это так, как вам удобнее, суть все равно не меняется". maytonКак по его мнению должен выглядеть наш пример с ODBC ?По его мнению (или Его высочайшему мнению? :), ODBC --- часть инфраструктуры вокруг SQL и "...PL", правильно? Логично посмотреть, а как примеры вроде вот этого соединения с ODBC оформляются в этих самых "...PL"? А там всё как раз логично, сначала catch-блоки, потом try-код. Код: plsql 1. 2. 3. 4. 5. 6. И только в совсем-совсем убогих и древних начинается кондовый фортрановский бардак: Код: plsql 1. 2. 3. 4. и фортрановость заключается в том, что --- либо для обработчиков не находится никакого места в коде, кроме как в хвосте, что некрасиво, --- либо нужен goto сразу после всех whenever, что ещё менее красиво и требует лишней перфокарты. То есть код структурирован от частных случаев к общим. Сравните с надоевшим всем Код: plaintext 1. 2. 3. 4. 5. Это не значит, что код должен быть структурирован так в абсолютно всех случаях, "главное правило дизайна гласит, что из любого правила дизайна бывают исключения", но обычный программист может всю жизнь проработать, так ни разу и не наткнувшись на необходимость в другой логике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 06:25 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Вася УткинНу вот, взяли и назвали часть какого-то кода: "Код для обнаружения/обработки особых случаев", хотя он ничем и не отличается от остального :)Вы правы, стилистический ляп. Надо было написать "ветка для обнаружения/обработки особых случаев...", тем более что дерево правил уже было помянуто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 06:31 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskydbpatchчто элементарнее может быть NDEBUG и assert(), какие еще исключения? Ждем теперь реализацию того же кода на ассертах. Ну чисто чтоб поржать над убогими сишниками ))) ты лично можешь начинать смеяться прямо сейчас, не вижу принципиальной разницы, и так и так - это беспричинный смех, признак сам знаешь чего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 15:21 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_rudbpatch, Интересно, что из моего комментария было написано так двусмысленно, что дало вам повод написать этот ответ? Особенно если коммент про код, остающийся в релизном экзешнике, а ответ --- про "говорят про необходимость удаления отладочного кода" (цвет мой). авторПо моему грустному опыту, попытки назвать "отладочным" код, не совсем было понятно, оставляете ли вы отладночный код, не оставляете, и с чем вообще был там неуспешный или даже успешный опыт. на собственной практике можно сказать - доля assert() и NDEBUG в любом проекте более 10к строк со временем объективно стремится к нулю - то, что раньше считалось assert()-ом в условиях большого проекта без возможности соблюдения контрактов рано или поздно перекочевывает в верификации ввода (т.е. становится неотключаемым в релизе), а всякие стресс и перф. тесты просто выносятся в отдельные модули. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 15:27 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_ruЛогично посмотреть, а как примеры вроде вот этого соединения с ODBC оформляются в этих самых "...PL"? А там всё как раз логично сначала catch-блоки, потом try-код. Вот с этого момента - непонятно. Что логично? Сначала catch-блоки? Почему? Где хотя-бы рациональное объяснение? Goto "назад" это логично? Или логично следование традициям pascal-подобным языкам где есть блок "declare" ... ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2017, 21:25 |
|
||
|
|

start [/forum/search_topic.php?author=set+integrity&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
174ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 713ms |
| total: | 1008ms |

| 0 / 0 |
