- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 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?");
Нужно определить, есть на графике точки или нет. Человек решил подстраховаться и рассмотреть все возможные (и невозможные) варианты.
guest 19.06.2011 20:15 # +3
carsten 20.06.2011 07:24 # −2
guest 20.06.2011 13:24 # 0
carsten 21.06.2011 16:23 # 0
guest 21.06.2011 16:50 # 0
Лол, что? Смартпоинтеры частный случай сборки мусора. С таким же успехом можно реализовать и полнофункциональную сборку мусора.
carsten 21.06.2011 19:04 # 0
конечно лучше использовать смартпойнтеры + ручные мемпулы только потому что субъективно C++/CLI не нравится.
guest 21.06.2011 22:17 # −1
Ну дак дефрагментируй кучу при сборке мусора. В чём проблема, то? Остановил все потоки и подменил все GC-указатели на новые значения.
А вообще сборка мусора на фиг не сдалась. Нет ни одной задачи, в которой есть острая необходимость использовать сборку мусора.
carsten 22.06.2011 11:06 # 0
99% сайтов написаны с использованием сборки мусора
guest 22.06.2011 12:18 # 0
Это не значит, что она там была критически необходима.
И уж точно глупость писать сайты на С++\CLI, если вдруг вы уготовили для него такое применение.
Неудачно приводить такой пример для демонстрации необходимости в С++ сборки мусора.
carsten 22.06.2011 11:09 # 0
в с++ это невозможно.
guest 22.06.2011 12:36 # 0
Я специально для Вас сейчас сильно упрощу реализацию сборки мусора.
Допустим написан шаблонный класс C++ GCPointer<PointedType> представляющий собой указатель, поддерживающий сборку мусора.
Допустим пора произвести компактирование (в вашем лексиконе дефрагментацию) кучи.
Мы останавливаем все потоки. Понятно что я сильно утрирую, но проходимся по списку все GCPointer'ов и перемещаем все блоки в куче в нужные позиции, при этом подменяя указатели GCPointer'ов на нужные.
В списке GCPointer'ы регистрируются при конструировании.
Я, конечно, сильно упростил, но это что-бы Вам было понятно.
Почитайте хотя бы
Элджер Джефф. С++. Библиотека программиста
guest 21.06.2011 16:52 # −1
ну значит пиши на .нет языке, а не сращивай костылями 2 противоположные парадигмы.
carsten 21.06.2011 19:08 # 0
дурашка, 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 вроде не поддерживается в моно.
guest 21.06.2011 22:19 # 0
Не вроде, а точно не поддерживается.
guest 21.06.2011 22:22 # 0
Аргументы закончились?
guest 21.06.2011 22:23 # 0
А я как-бы намекаю, что glue code почти не нужен.
Lure Of Chaos 21.06.2011 23:04 # 0
carsten 22.06.2011 11:06 # 0
нуну. дуй обратно в институт, хелловорды клепать
guest 22.06.2011 12:45 # 0
Начинать на костылях новый проект я бы не стал.
С++\КЛИ уже с 2005 года не поддерживается майкрософтом. Они просто перетаскивают его из студии в студию для поддержки старых проектов, не меняя его. Однажды совсем уберут.
Тем более этот С++\CLI создаёт дополнительные проблемы\несовместимости для перехода на 64х битные ос, а майкрософту это явно не нужно.
guest 21.06.2011 23:40 # 0
carsten 22.06.2011 11:08 # 0
guest 22.06.2011 12:39 # 0
Спс, КЭП.
guest 21.06.2011 16:54 # 0
В сторонних библиотеках в стандартном С++ уже реализовано гораздо больше, чем есть во всех версиях .нет фреймворка вместе взятых.
carsten 21.06.2011 19:05 # 0
guest 21.06.2011 22:21 # 0
guest 21.06.2011 16:56 # 0
>(главное, что рабочий)
Особенно на любой платформе, где не стоит Windows и vc_redist одновременно.
carsten 21.06.2011 19:02 # 0
оно не будет работать аж на 1% платформ, чтоза ужос, что за ужос (а редист в сетап кладётся)
guest 21.06.2011 22:26 # +1
MAC'и, линуховые сервера всего Интернета и часть мобил не учитываем?
carsten 22.06.2011 11:07 # 0
guest 22.06.2011 12:12 # 0
А линуксовых серверов в Инете подавляющая часть. Ну да, так уж и 1%. Ну ну.
carsten 21.06.2011 16:25 # 0
ок, запомню.
guest 21.06.2011 17:00 # 0
Нет, конечно. Раз использование расширений - говнокод, то пожалуйте выложить его в раздел С++.
gcc не другой язык, а компилятор языка С++, так что по разделу подходит.
C++/CLI же - новый язык, имеющий свою спецификацию и стандарт, написанный майкрософтом, а не комитетом стандартизации С++. Более того, есть конструкции из С++, которые С++\CLI даже не компилирует, что и ожидаемо.
carsten 21.06.2011 19:12 # 0
>Более того, есть конструкции из С++, которые С++\CLI даже не компилирует, что и ожидаемо.
ой да ладно, почти все компиляторы кроме, пожалуй, Comeau, что-нибудь комилируют не так из стандарта, это не значит что это не С++.
guest 21.06.2011 22:30 # 0
Комеяу некоторые вещи не компилирует из-за ошибок в реализации стандарта, а С++\CLI не компилирует некоторые вещи согласно "убогому" стандарту Микрософта.
carsten 22.06.2011 11:09 # 0
очень объективно
guest 22.06.2011 12:49 # 0
По делу что-то есть?
Извини, отредактировать пост и убрать прилагательное уже не могу.
Назвать по другому это нельзя. Обрезали часть стандартных возможностей С++, накрутили свои возможности и дали новое название языку С++\CLI.
guest 22.06.2011 12:55 # 0
guest 22.06.2011 12:59 # 0
Если с самого начала выбран такой язык, на котором есть все необходимые для разработки библиотеки и инструменты - glue code становится не нужен (не нужны костыли для сращивания библиотек на разных языках).
ctm 20.06.2011 06:37 # +5
if (i == 0){
...
} else if (i != 0){
...
} else throw "Какого хрена?!"
roman-kashitsyn 20.06.2011 08:51 # +1
ctm 20.06.2011 13:18 # 0
absolut 20.06.2011 09:17 # +1
ctm 22.06.2011 06:35 # 0
guest8 08.04.2019 20:58 # −999
guest8 09.04.2019 11:00 # −999
guest8 09.04.2019 18:07 # −999