Да, и если честно, класс имплементирующий 10 интерфейсов сильно напоминает God Class, это мало коррелирует с принципами SOLID. Я б такой класс делать не стал. Принцип единственной отвесьвенности еще никто не отменял.
Виртуальное наследование нужно использовать только в слуяае ромбовидных наследований. В случае множественного наследования абстрактных классов(читай интерфейсов) используется обычное наследование.
1. Иногда библиотека не нужна, а достаточно небольшого его подмножества, в таком случае велосипед в полне может иметь место.
2. Когда ты можешь, не напрягаясь, в свой проект добавить новую зависимость, в 90% случаев ты не будешь задумываться о последствиях — а последствия, например — попытка собрать тестовое angular2 приложение притаскивает около 100Mb всякой херни на лоакальный диск, в долгосрочных проетах это не допустимо. Каждая зависимость должна быть обдумана, проанализирована, и признана годной, в таком варианте, текущая реализация внесения зависимостей в C++ вполне оправдана.
boolinq как пример. Не без проблем конечно, но реализовано все множество linq над колекциями(не linq->sql или entity), в своих внутренних проектах использовал, в продуктовых решили ждать ренджи.
А если я хочу навесить второй интерфейс на Derived? А если я хочу, чтобы Base был POD, а интерфейс реализовывался в Derived, но использовал реализации функций Base? А что делать, если интерфейсов несколько, некоторые из которых включены по нескольку раз? CRTP не от хорошей жизни используется.
При желании все эти требования можно реализовать, в С++11 есть using, есть виртуальное наследование(для случаев ромбовидного наследования), в конце концов наследование не панацея, есть икапсуляция.
Изначально я хотел сказать, что в C++ достаточно инструментов для реализации любых прихотей архитектора. Даже на этом этапе его развития.
В дополнение скажу, сейчас мне приходится писать практически в равных частях код на C++ и на C#, и если в C++ мне чаще всего не хватает возможностей и удобств которые дает .NET фареймвок, то в С# мне часто не хватает именно особенностей C++ как языка.
Без чего в плюсах жить реально тяжело — это без Linq. Так и чешутся руки писать Where().Select().Order() etc… Ждем ренжес :)
Интерфейсы — этот инструмент задания(декларации) полиморфного поведения объекта во время исполнения, концепты в C++ — это инструмент декларации требований к типу передоваемому как аргумент шаблона, и их проверка на этапе компиляции. У вас до сих пор в C# есть возможность привести любой объект к любому интерфейсу(типу) и попытаться на нем чтото вызвать, компилятор вам тут не помешает.
ваш пример на С++ просто реализовывается по другому
template <typename IT>
class Base :public IT
{
public:
void Perform() { }
};
class IFace
{
public:
virtual void Perform() = 0;
};
class Derived :public Base<IFace>
{
};
А что касается vtable, не думаю что в C# нет ее аналога.
По поводу сети, С++ реализаций сетевых библиотек сейчас вагон и маленькая тележка, низкоуровневые — boost,qt,libevent, POCO. Высокоуровневые — websocketpp, restcpp(casablanсa), qt, POCO. Это только то что вспомнил и чем приходилось пользоваться. Да и в стандарте вот-вот что то примут.
Выстрелы в конечности есть в любом языке, ошибку в логике приложения можно допустить всегда. С++ в этом плане дает больше свобод нежели другие языки, но я бы не сказал что прямо на много. Да, за циклом жизни объектов выделенных на куче нужно следить самостоятельно(и то, в прошлом веке), но сборщик мусора не всегда в этом помощник, мне как то легче не становится, что объект инкапсулирующий соединение к БД, умрет когдато, после того как я его потеряю, а чтобы освободить соединение все равно надо вызвать Dispose, и чем это не ручное управление?
Указатели? да есть возможность подарваться, но можно и минимизировать работу с ними.
Зато пописав на С++ начинаешь больше задумываться именно об архитектуре приложения, почему этот объет должен жить доглго, а этот должен умирать быстро, почему этот объект владеет другим а не наоборот, итд…
Да, но посмотрев пример на Go с сумированием разнотипных списков из статьи, как то начинаешь задумываться, что лучше уж так как в C++ чем так…
А все остальное — это на любителя. С++ это инструмент для долгосрочных больших проектов, в таких проекта менеджер пакетов будет скорее принсить вред, так как будет провацировать вносить лишние зависимости, а в долгосрочных проектах — это зло, иногда цикл жизни проекта больше, чем библиотеки которую можно притащить из менеджера пакетов.
Может я чего то не понимаю, чем класс с чисто виртуальными методами в С++ отличается от интерфейсов в C#, не в смысле реализации в архитектуром смысле.
Вот смотрю я а все эти новомодные языки, смотрю на старый добрый C++ и не понимаю, чего там людям не хватает? Любые парадигмы, на выбор, пиши как хочешь. Обобщается все. Как хочешь. главное чтобы воображения и фантазии хватало. Не ужели действительно проблема в том, что он многим кажется сложным????
На самом деле косвенные методы определения гипокликемии(но не гипер, при гиппокликемии пульс сильно учащаяется) вполне реальны, да они будут не очень точны, но все равно могут помочь. Например во время сна, а всего-то нужен фитнес-браслет иземряющий пульс и сопоставляющий его с физической активностью за некоторый промежуток времени, и издающий вибросигнал в качестве предупреждения, после предупреждения можно померять сахар и простым глюкометром.
Я давно жду какой ни будь фитнес браслет с возможностью исполнять на нем код, чтобы поиграться с ним.
Это ужасно! Более жуткого приложения я не видел.
1. качаем приложение, запускаем, попадаем на страницу аутентификации, где предлагают ввести номер телефона, и показывают код моей страны. Когда я тапаю на поле для ввода, код моей страны чудесным образом меняется на US. Ищем мою страну в длинющем списке…
2. Вводим номер телефона, меня приветствуют и предлагают ввести пароль, пароль который принимается на сайте тут не принимается.
3. Пробуем восстановить пароль — требуют email, вводим email — говорят, что этот email не связан с эти телефоном.
4. Ок, идем на сайт, в профиль, пытаемся там висать телефон — болт — там поле телефона не редактируемо.
5. Идем на телефон — пробуем зайти при помощи аккаунта facebook — выскаивает страница где отображены все мои актуальные данные, включая телефон, нжимаем далее — требует пароль, пароль не принимается.
6. Идем на сайт пробем менять пароль, пароль меняется через подтверждение на email, идем в пункт 1 — все по кругу.
7. Идем на сайт в поисках связи с поддержкой — везде написанно — воспользуйтесь помощью в приложении.
Занавес.
Давно наблюдаю за этим плагином под VS, но пока от его использования останавливает одно — есть куча сборок (кроскомпиляторов) GCC под windows, при этом компилирущих не только под x86 но и например под arm, но прикрутить такой кроскомпиятор к этому плагину пока что, увы ни как:( А это очень сильно ограничивает сферу применения, например у меня есть проект, целевая платформа которого — ARM Linux(raspbery pi, orange pi, итп), но он использует boost, и собирать его на arm linux, просто нереально долго, а иногда и памяти не хватает компилятору:( Если бы можно было настроить кроскомпиляцию при помощи VS а отладку на целевой платформе… Мечты…
Сам термин может и есть, но по сути — фильтр тривиален. Вообще да, согласованный фильтр — это фильтр который для заданного типа сигнала, обеспечивает на выходе максимальное соотношение сигнал/шум.
А разве вы использововали «согласованный фильтр»? Для простого сигнала, насколько я помню такого термина не вводят, так для обычного прямоугольного радиоимпульса соглавованным является простейший полосовой фильтр со спектральной характеристикой максимально соответствующей спектру прямоугольного радиоимпульса — sin(x)/x. Понятие согласованного фильра вводится для сложных сигналов, у которы база B>>1. Суть в том что отклик на выходе соглаванного фильтра повторяет автокореляционную функцию сигнала, что существенно повышает соотношение сигнал/шум. Интересно было бы посмотреть на такие эксперименты, например сравнение нейронной сети для распознания сигналов на основе М-последовательностей.
Мне кажется что в этой статье есть заблуждение. Когда говорят что компилятор C++ «лучше, выше, быстрее» имеют в виду не конеретный код, работающий с конкретными типами, как в примере приведенном в статье, а имеют в виду гораздо более общие случаи.
А приведенном коде (который кстати совсем не а C++), производится работа по сортировке массивов заданного типа, и именно это дает возможность переписать этот код на ассемблере с выигрыщем в произовдительности и (возможно) свободном от ошибок. А теперь представьте что у вас эти Item разные, имееют разные китерии сравнениия, да и вообще у вас не Item а например Peoples, или еще чтото… На C — вы будете пытаться это обобщить через void* и предикаты (и имеете шанс запутаться), на asm вы уже запутаетесь в косвенной адресации и предикатах, шаблонные же алгоритмы на C++ сгенирируют за вас вполне корректный код, который работает по фиксированным отступам в пямяти, со знанием размеров объектов и членов, именно по тому что КОМПИЛЯТОР ЗНАЕТ ТИП и именно это поможет быть этому коду оптимальным.
2. Когда ты можешь, не напрягаясь, в свой проект добавить новую зависимость, в 90% случаев ты не будешь задумываться о последствиях — а последствия, например — попытка собрать тестовое angular2 приложение притаскивает около 100Mb всякой херни на лоакальный диск, в долгосрочных проетах это не допустимо. Каждая зависимость должна быть обдумана, проанализирована, и признана годной, в таком варианте, текущая реализация внесения зависимостей в C++ вполне оправдана.
При желании все эти требования можно реализовать, в С++11 есть using, есть виртуальное наследование(для случаев ромбовидного наследования), в конце концов наследование не панацея, есть икапсуляция.
Изначально я хотел сказать, что в C++ достаточно инструментов для реализации любых прихотей архитектора. Даже на этом этапе его развития.
В дополнение скажу, сейчас мне приходится писать практически в равных частях код на C++ и на C#, и если в C++ мне чаще всего не хватает возможностей и удобств которые дает .NET фареймвок, то в С# мне часто не хватает именно особенностей C++ как языка.
Без чего в плюсах жить реально тяжело — это без Linq. Так и чешутся руки писать Where().Select().Order() etc… Ждем ренжес :)
ваш пример на С++ просто реализовывается по другому
А что касается vtable, не думаю что в C# нет ее аналога.
Выстрелы в конечности есть в любом языке, ошибку в логике приложения можно допустить всегда. С++ в этом плане дает больше свобод нежели другие языки, но я бы не сказал что прямо на много. Да, за циклом жизни объектов выделенных на куче нужно следить самостоятельно(и то, в прошлом веке), но сборщик мусора не всегда в этом помощник, мне как то легче не становится, что объект инкапсулирующий соединение к БД, умрет когдато, после того как я его потеряю, а чтобы освободить соединение все равно надо вызвать Dispose, и чем это не ручное управление?
Указатели? да есть возможность подарваться, но можно и минимизировать работу с ними.
Зато пописав на С++ начинаешь больше задумываться именно об архитектуре приложения, почему этот объет должен жить доглго, а этот должен умирать быстро, почему этот объект владеет другим а не наоборот, итд…
А все остальное — это на любителя. С++ это инструмент для долгосрочных больших проектов, в таких проекта менеджер пакетов будет скорее принсить вред, так как будет провацировать вносить лишние зависимости, а в долгосрочных проектах — это зло, иногда цикл жизни проекта больше, чем библиотеки которую можно притащить из менеджера пакетов.
Я давно жду какой ни будь фитнес браслет с возможностью исполнять на нем код, чтобы поиграться с ним.
1. качаем приложение, запускаем, попадаем на страницу аутентификации, где предлагают ввести номер телефона, и показывают код моей страны. Когда я тапаю на поле для ввода, код моей страны чудесным образом меняется на US. Ищем мою страну в длинющем списке…
2. Вводим номер телефона, меня приветствуют и предлагают ввести пароль, пароль который принимается на сайте тут не принимается.
3. Пробуем восстановить пароль — требуют email, вводим email — говорят, что этот email не связан с эти телефоном.
4. Ок, идем на сайт, в профиль, пытаемся там висать телефон — болт — там поле телефона не редактируемо.
5. Идем на телефон — пробуем зайти при помощи аккаунта facebook — выскаивает страница где отображены все мои актуальные данные, включая телефон, нжимаем далее — требует пароль, пароль не принимается.
6. Идем на сайт пробем менять пароль, пароль меняется через подтверждение на email, идем в пункт 1 — все по кругу.
7. Идем на сайт в поисках связи с поддержкой — везде написанно — воспользуйтесь помощью в приложении.
Занавес.
А приведенном коде (который кстати совсем не а C++), производится работа по сортировке массивов заданного типа, и именно это дает возможность переписать этот код на ассемблере с выигрыщем в произовдительности и (возможно) свободном от ошибок. А теперь представьте что у вас эти Item разные, имееют разные китерии сравнениия, да и вообще у вас не Item а например Peoples, или еще чтото… На C — вы будете пытаться это обобщить через void* и предикаты (и имеете шанс запутаться), на asm вы уже запутаетесь в косвенной адресации и предикатах, шаблонные же алгоритмы на C++ сгенирируют за вас вполне корректный код, который работает по фиксированным отступам в пямяти, со знанием размеров объектов и членов, именно по тому что КОМПИЛЯТОР ЗНАЕТ ТИП и именно это поможет быть этому коду оптимальным.