Есть ряд полезных мыслей, хорошо изложенных. Причем по моему мнению это больше относится к самому подходу к работе — ведению документации, написанию отдельных консольных программ чтобы оттестировать алгоритмы. Подобный порядок вызывает уважение. Но при этом изложен ряд спорных с ООП-утверждений.
Итак, Бункер не выдаёт наружу подробности своей реализации. При этом, он сам выводит себя в интерфейс, сам обрабатывает нажатия на свои контролы, сам выполняет всю работу, которая требует знания о том, как он устроен. Наружу открываются функции-члены, которые просят класс выполнить ту или иную работу: выведи себя в интерфейс, обработай нажатие мышки, сохрани себя в XML и т.д.
Если с сущностью выполняется много операций — то интерфейс класса превратиться в мясо. Поэтому сериализацию и подобные операции имеет смысл разнести как минимум по разным интерфейсам, а порой и по вспомогательным классам. А насчет «выведи себя в интерфейс» — по моему мнению вообще за гранью добра и зла.
Сколько человек зарабатывает — он обычно знает, все-таки прибыль считать приятнее. А вот по поводу того сколько тратит и на что — обычно если финансы не прижимают, то и не знает.
Всякое бывает. Помню года 4 назад пришлось мне разбираться в хтмплн-ом отчете с джаваскриптами, где все функции принимали параметр c именем O и назывались f1, f2, f3… Что при отсутствии типизации весьма доставляло.
Насколько я понимаю, то с чем занимался любовными утехами автор — это реальный проект. В котором надо было улучшить производительность. Видимо кого-то-таки не устраивало, что считалось 30 секунд вместо 0,3. И этот кто-то — начальство.
Все по делу, любой человек, который занимался оптимизацией подтвердит :)
Единственное замечание — попытка повторного использования счетчиков в циклах вкупе for private из open mp. Зачем, если можно объявлять счетчик в каждом цикле и он автоматически будет объявлен приватным при распараллеливании? Ну и заодно дать счетчикам осмысленные имена.
Он хорош. Честное слово, очень хорош. Если бы вместо F# был бы он — то я бы с удовольствием писал на нем. А так — никто не даст в коммерческом проекте использовать малоизвестный не поддерживаемый майкрософтом язык.
C# тоже позволяет это делать, если разрешить режим unsafe.
Но при этом все выделение и освобождение памяти все равно отдано на откуп GC. А если будет много объектов, к которым будет доступ по указателям — то это сделает невозможной дефрагментацию кучи.
И судя по моему опыту модули, написанные на C++/CLI порой медленнее, чем те же самые модули, написанные на чистом C#
Знаете, на ассемблере можно написать так, что будет работать медленнее, чем на пхп… Тут вопрос в уровне познаний того, кто писал. В общем случае C++ CLI предоставляет больший простор для написания оптимального кода, важно им правильно распорядиться.
Если распределение точек не случайное, а такое что соседние точки расположены по близким индексам, то написать алгоритм, справляющийся за O(nlogn) — несложно, сам такой реализовывал. В противном случае нужно применять динамическое кеширование, для итеративны алгоритмов, например.
Хм, резоное замечание, только хеллоуворлд ничем не интересен. Возможно, имеет смысл привести реальный пример простенького приложения, которое показывает преимущества языка, благо такое есть под рукой.
Это не идеология, скорее попытка аргументированного разъяснения для чего эта штуковина полезна, для чего — нет. Может не совсем удачно получилось, все-таки первый опыт написания статьи.
Спасибо, очень интересное решение, как минимум в плане отсутствия написания одинакового кода. Правда к подобным ухищрение приводит печальное отсутствие макросов образца Nemerle.
Если народу будет интересно и хватит кармы — то в следующей статье буду раскрывать тонкости, которые остались за кадром.
В целом, изучение С++ CLI сводится именно к пониманию синтаксиса и этих тонкостей, если знать как устроен классический С++ и дотнет, ибо больше там и нет ничего.
В принципе, чтобы изучить совсем просто — лучше да, знать один из языков .Net-стека. А насчет того, чтобы возиться — если нужна производительность или доступ к плюсовому коду, то уж придется разбираться.
Вообще язык очень специфический, но свои задачи решает очень красиво. Я вообще плюсами серьезно начал из-за него заниматься:)
Если это так — то это торжество маразма. Не говоря уж о том, что показатели приборов лучше разместить там, где обычно стоит приборная панель. Можно сколько угодно переворачивать представление от автомобиля, но там засветка будет минимальная.
Хотелось бы видеть фото вместе с приборной панелью, потому как сейчас непонятно почему приборная панель и навигация отображаются на одном дисплее. Или это не так?
Если с сущностью выполняется много операций — то интерфейс класса превратиться в мясо. Поэтому сериализацию и подобные операции имеет смысл разнести как минимум по разным интерфейсам, а порой и по вспомогательным классам. А насчет «выведи себя в интерфейс» — по моему мнению вообще за гранью добра и зла.
Единственное замечание — попытка повторного использования счетчиков в циклах вкупе for private из open mp. Зачем, если можно объявлять счетчик в каждом цикле и он автоматически будет объявлен приватным при распараллеливании? Ну и заодно дать счетчикам осмысленные имена.
Но при этом все выделение и освобождение памяти все равно отдано на откуп GC. А если будет много объектов, к которым будет доступ по указателям — то это сделает невозможной дефрагментацию кучи.
Знаете, на ассемблере можно написать так, что будет работать медленнее, чем на пхп… Тут вопрос в уровне познаний того, кто писал. В общем случае C++ CLI предоставляет больший простор для написания оптимального кода, важно им правильно распорядиться.
В целом, изучение С++ CLI сводится именно к пониманию синтаксиса и этих тонкостей, если знать как устроен классический С++ и дотнет, ибо больше там и нет ничего.
Вообще язык очень специфический, но свои задачи решает очень красиво. Я вообще плюсами серьезно начал из-за него заниматься:)