1. C++ / Говнокод #6998

    +153

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    if(FirstDot == 0 && LastDot == 0)
    			NoDots = true;
    		else
    			if(FirstDot != 0 && LastDot == 0)
    				throw gcnew System::Exception("Левый коррелятор начал работу, правый - нет.");
    			else
    				if(FirstDot == 0 && LastDot != 0)
    					throw gcnew System::Exception("Правый коррелятор начал работу, левый - нет.");
    				else
    					if(FirstDot != 0 && LastDot != 0)
    						if(FirstDot == LastDot)
    							NoDots = true;
    						else
    							NoDots = false;
    					else
    						throw gcnew System::Exception("WTF?");

    Нужно определить, есть на графике точки или нет. Человек решил подстраховаться и рассмотреть все возможные (и невозможные) варианты.

    Запостил: ScumCoder, 19 Июня 2011

    Комментарии (46) RSS

    • Это не С++. Это С++\CLI. Добро пожаловать в Кучу.
      Ответить
      • В g++ тоже дохрена расширений, и чего теперь. Чистого с++ вообще не бывает. Только недавно - вон, стандарту еле-еле научились.
        Ответить
        • использование расширений - тот ещё говнокод.
          Ответить
          • оправдано, когда стандартный с++ не позволяет. напр. сборки мусора и интеропа с CLR (кто знает, может нужный функционал реализован только в .net-библиотеке?) в стандартом с++ нету, вот и используют C++/CLI-расширение. в реальном мире отталкиваются от практической надобности, а не личных вкусов, нравится или нет. C++/CLI - не говнокод, а вполне себе интересный (главное, что рабочий) инструмент - кто ещё умеет одновременно компилировать bytecode и native-код и seamlessly их интегрировать? (и я это говорю как не самый большой любитель .net)
            Ответить
            • >оправдано, когда стандартный с++ не позволяет. напр. сборки мусора
              Лол, что? Смартпоинтеры частный случай сборки мусора. С таким же успехом можно реализовать и полнофункциональную сборку мусора.
              Ответить
              • смарт-пойнтеры не масштабирумы -- в серьёзных неигрушечных системах куча будет фрагментироваться

                конечно лучше использовать смартпойнтеры + ручные мемпулы только потому что субъективно C++/CLI не нравится.
                Ответить
                • >в серьёзных неигрушечных системах куча будет фрагментироваться
                  Ну дак дефрагментируй кучу при сборке мусора. В чём проблема, то? Остановил все потоки и подменил все GC-указатели на новые значения.

                  А вообще сборка мусора на фиг не сдалась. Нет ни одной задачи, в которой есть острая необходимость использовать сборку мусора.
                  Ответить
                  • >Нет ни одной задачи, в которой есть острая необходимость использовать сборку мусора.

                    99% сайтов написаны с использованием сборки мусора
                    Ответить
                    • >99% сайтов написаны с использованием сборки мусора
                      Это не значит, что она там была критически необходима.

                      И уж точно глупость писать сайты на С++\CLI, если вдруг вы уготовили для него такое применение.
                      Неудачно приводить такой пример для демонстрации необходимости в С++ сборки мусора.
                      Ответить
                  • >Ну дак дефрагментируй кучу при сборке мусора. В чём проблема, то? Остановил все потоки и подменил все GC-указатели на новые значения.

                    в с++ это невозможно.
                    Ответить
                    • >в с++ это невозможно.
                      Я специально для Вас сейчас сильно упрощу реализацию сборки мусора.
                      Допустим написан шаблонный класс C++ GCPointer<PointedType> представляющий собой указатель, поддерживающий сборку мусора.
                      Допустим пора произвести компактирование (в вашем лексиконе дефрагментацию) кучи.
                      Мы останавливаем все потоки. Понятно что я сильно утрирую, но проходимся по списку все GCPointer'ов и перемещаем все блоки в куче в нужные позиции, при этом подменяя указатели GCPointer'ов на нужные.
                      В списке GCPointer'ы регистрируются при конструировании.
                      Я, конечно, сильно упростил, но это что-бы Вам было понятно.
                      Почитайте хотя бы
                      Элджер Джефф. С++. Библиотека программиста
                      http://www.twirpx.com/file/19224/
                      Ответить
            • >и интеропа с CLR (кто знает, может нужный функционал реализован только в .net-библиотеке?)
              ну значит пиши на .нет языке, а не сращивай костылями 2 противоположные парадигмы.
              Ответить
              • >ну значит пиши на .нет языке, а не сращивай костылями 2 противоположные парадигмы.

                дурашка, C++/CLI используется для интеропа, это называется не костыли, а обычный glue code между родным кодом и foreign code. в любой системе оно используется, в явном и неявном виде. плюс C++/CLI в том что он позволяет соединить две библиотеки -- legacy на c++ и нечто на .NET - в единое целое. В .net есть P/Invoke но он cumbersome при использовании с c++ (нужно городить дохрена обёрток через extern "C"), ну и C++/CLI быстрее в плане вызова native-функций из .net, чем P/Invoke.

                минус в том что mixed assemblies вроде не поддерживается в моно.
                Ответить
                • >mixed assemblies вроде не поддерживается в моно
                  Не вроде, а точно не поддерживается.
                  Ответить
                • >дурашка
                  Аргументы закончились?
                  Ответить
                • >обычный glue code между родным кодом и foreign code.
                  А я как-бы намекаю, что glue code почти не нужен.
                  Ответить
                  • кому С мало, а с.нет - много, может попробовать D, там как раз мультипарадигменное программирование, т.е. "кто как привык"
                    Ответить
                  • >А я как-бы намекаю, что glue code почти не нужен.

                    нуну. дуй обратно в институт, хелловорды клепать
                    Ответить
                    • Единственная причина, при которой я бы стал использовать С++\КЛИ - это поддержка старого кода.
                      Начинать на костылях новый проект я бы не стал.
                      С++\КЛИ уже с 2005 года не поддерживается майкрософтом. Они просто перетаскивают его из студии в студию для поддержки старых проектов, не меняя его. Однажды совсем уберут.
                      Тем более этот С++\CLI создаёт дополнительные проблемы\несовместимости для перехода на 64х битные ос, а майкрософту это явно не нужно.
                      Ответить
                • Уж лучше использовать P/Invoke, чем терять кроссплатформенность приложений и получать необходимость таскать со своей программой не хилый по размеру vc_redist. А таскать его нужно, ибо в отличии от .net FrameWork обычно он на машине клиента не стоит.
                  Ответить
                  • судят по ситуации, а не по абстрактным мутным размышлениями хелловорлдщика
                    Ответить
            • >в стандартом с++ нету
              В сторонних библиотеках в стандартном С++ уже реализовано гораздо больше, чем есть во всех версиях .нет фреймворка вместе взятых.
              Ответить
              • консервативный libgc - говёный сборщик
                Ответить
                • Я говорю о другом: Всё давно реализовано до .net и причин сращивать .нет фреймворк сборки с C++ нет.
                  Ответить
            • >C++/CLI
              >(главное, что рабочий)
              Особенно на любой платформе, где не стоит Windows и vc_redist одновременно.
              Ответить
              • >Особенно на любой платформе, где не стоит Windows и vc_redist одновременно
                оно не будет работать аж на 1% платформ, чтоза ужос, что за ужос (а редист в сетап кладётся)
                Ответить
                • >1% платформ
                  MAC'и, линуховые сервера всего Интернета и часть мобил не учитываем?
                  Ответить
                  • это как раз 1%
                    Ответить
                    • http://www.macinews.ru/news/dolya-mac-na-rynke-ssha-vyrosla-s-86-do-94/
                      Ну да, так уж и 1%. Ну ну.
                      А линуксовых серверов в Инете подавляющая часть.
                      Ответить
          • т.е. с++ c расширениями от gcc тоже в кучу, да?
            ок, запомню.
            Ответить
            • >т.е. с++ c расширениями от gcc тоже в кучу, да?
              Нет, конечно. Раз использование расширений - говнокод, то пожалуйте выложить его в раздел С++.
              gcc не другой язык, а компилятор языка С++, так что по разделу подходит.
              C++/CLI же - новый язык, имеющий свою спецификацию и стандарт, написанный майкрософтом, а не комитетом стандартизации С++. Более того, есть конструкции из С++, которые С++\CLI даже не компилирует, что и ожидаемо.
              Ответить
              • дурашка, C++/CLI -- обычный superset ISO C++, так же как и g++ с gcc-расширениями. качественного различия между ними нет. количественное только, может быть.

                >Более того, есть конструкции из С++, которые С++\CLI даже не компилирует, что и ожидаемо.
                ой да ладно, почти все компиляторы кроме, пожалуй, Comeau, что-нибудь комилируют не так из стандарта, это не значит что это не С++.
                Ответить
                • >Comeau, что-нибудь комилируют не так из стандарта,
                  Комеяу некоторые вещи не компилирует из-за ошибок в реализации стандарта, а С++\CLI не компилирует некоторые вещи согласно "убогому" стандарту Микрософта.
                  Ответить
                  • >убогий/неубогий

                    очень объективно
                    Ответить
                    • >очень объективно
                      По делу что-то есть?
                      Извини, отредактировать пост и убрать прилагательное уже не могу.

                      Назвать по другому это нельзя. Обрезали часть стандартных возможностей С++, накрутили свои возможности и дали новое название языку С++\CLI.
                      Ответить
                    • Эх, признаюсь. Однажды, когда был хелоуворлдщиком в области С++\CLI, тоже оказался под впечатлением от языка С++\CLI. И даже где-то здесь в периоды становления сайта говнокода яростно его защищал. С тех пор за несколько С++\CLI проектов - впечатления от него как-то поутихли, нашёл множество изьянов...
                      Ответить
                    • Сейчас, ещё на этапе проектирования, стараюсь подобрать правильный инструмент, что-бы потом не пришлось брать одну библиотеку из одного языка, а вторую из другого.
                      Если с самого начала выбран такой язык, на котором есть все необходимые для разработки библиотеки и инструменты - glue code становится не нужен (не нужны костыли для сращивания библиотек на разных языках).
                      Ответить
    • Вариации на тему
      if (i == 0){
      ...
      } else if (i != 0){
      ...
      } else throw "Какого хрена?!"
      Ответить
      • NaN
        Ответить
      • про перегрузки не забываем :)
        Ответить
        • В этом случае еще больший ГК. Не гуд перегружать операторы так, что их действие становится неочевидным или не привычным.
          Ответить
    • показать все, что скрытоvanished
      Ответить
    • показать все, что скрытоvanished
      Ответить
    • показать все, что скрытоvanished
      Ответить

    Добавить комментарий