Здравствуйте, alex_public, Вы писали:
_>Что-то ты тут бредишь...
Хамовато.
_>1. Компиляторы не имеет никакого отношения ни к каким "Go To Declaration" или "Go To Definition". Они занимаются исключительно преобразованием исходных кодов в исполняемые и всё.
Это в нормальных языках. В C++ исходные коды шаблонов компилятор автора библиотеки в испольняемые файлы не преобразует. Библиотека поставляются пользователю в текстовом виде как есть.
_>А то, что ты описываешь — это работа IDE, у которых для этих целей есть свои анализаторы кода.
Могут быть свои, могуть быть общие. В Visual Studio двигаются в сторону использования платформы Roslyn как для собственно компиляции, так и сервисов анализа кода.
_>Уточни про какую конкретную IDE ты пишешь
Выше уже уточнял: MSVS Community 2017 RC в режиме C++17.
_>...и какие конкретно примеры в ней работают не так, как тебе нравится.
Навигация по разным функциям в Boost Graph Library и в окрестности.
_>Возможно тебе подскажут IDE, которая делает всё как надо.
Надо не мне, а топикстартеру, который озвучивал Visual C++.
_>Естественно речь про лидеров в данной области, а не про всякие убогие IDE.
А можно список лидеров и неубогих IDE? Я проверю, если не поленюсь (и если бесплатно).
Глаза у меня добрые, но рубашка — смирительная!
Re[9]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Очень примерно. Потому что макросы, шаблонные выкрутасы и т.п. все это счастье ломают на корню. Для С++ подногого уровня инструмент сделать невозможно в принципе, в силу самого языка.
"Невозможно в принципе" означает неоднозначность компилятора или как понимать?
Здравствуйте, lpd, Вы писали:
lpd>Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит. lpd>Если одновременных клиентов тысячи, то быстродействия C# не хватит. lpd>...быстродействия C# не хватит.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, itslave, Вы писали:
I>>Возьми свои букмарки и посчитай, сколько веб серверов написаны на С++. Начни с РСДН.
Q>Нет, начни со StackOverflow
StackOverflow — это просто обработать один запрос и либо положить пост в базу, либо выдать посты из базы. В нагруженных серверах(например, когда клиентами являются мобильные пользователи, VoIP) может быть постоянный обмен обмен пакетами, запросами, обработка данных. В таких случаях быстродействие языка играет роль.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
209,420,973 (+61,336,090) HTTP requests to our load balancer
66,294,789 (+30,199,477) of those were page loads
1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB) of HTTP traffic sent
569,449,470,023 (+282,874,825,991) bytes (569 GB) total received
3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB) total sent
504,816,843 (+170,244,740) SQL Queries (from HTTP requests alone)
5,831,683,114 (+5,418,818,063) Redis hits
17,158,874 (not tracked in 2013) Elastic searches
3,661,134 (+57,716) Tag Engine requests
607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries
10,396,073 (-88,950,843) ms (2.8 hours) spent on Redis hits
147,018,571 (+14,634,512) ms (40.8 hours) spent on Tag Engine requests
1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net
22.71 (-5.29) ms average (19.12 ms in ASP.Net) for 49,180,275 question page renders
11.80 (-53.2) ms average (8.81 ms in ASP.Net) for 6,370,076 home page renders
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, lpd, Вы писали:
lpd>>StackOverflow — это просто обработать один запрос и либо положить пост в базу, либо выдать посты из базы.
Q>Статистика за один день:
Q>607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries Q>1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net Q>[/q]
Видим, что основное время затрачено именно на обработку ASP.Net. То есть, не все идеально даже в этом случае.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Qbit86, Вы писали:
Q>Стадия компиляции не выявит ошибку даже в пользовательском коде, если у пользователя есть свой метод `baz()`, вызова которого из библиотечного кода он не ожидает. Ведь он ожидает, что согласно документации будет вызываться `bar()`.
Ошибки перегрузки ловятся тестами, а не компилятором, ваш КО.
Такая же ошибка могла быть и не в шаблонном коде, если у целевого Т есть некий baz, помимо bar. Без тестирования ф-ии foo эти рассуждения ни о чем.
V>>Более того, в С++ легко проверить наличие нужного метода/методов даже в декларативном стиле уже имеющимися ср-вами языка (т.е. ср-в языка достаточно для разработки библиотечных приблуд требуемой функциональности). Q>Это ты не мне расскажи, а Страуструпу. А то он не в курсе, что концепты не нужны: http://www.stroustrup.com/good_concepts.pdf
1. Я не против любых будущих улучшений языка С++, которые не будут нарушать его строгость и последовательность.
2. Речь шла о том, что многое можно делать уже сейчас.
3. Концепт не спасёт от ошибки перегрузки в твоём примере насчет bar/baz.
Последнее утверждение раскрывать требуется?
V>>В общем, когда речь идёт о реализации параметрического полиморфизма в C# vs C++ — то тут что-либо обсуждать сложно, т.к. у этих языков явно разные весовые категории в плане такого полиморфизма. Q>Да, выражать констрейнты номинативно через типы — не лучший подход. Конечно, шаблоны в C++ мощнее (в этом же смысле генерация через T4 ещё «мощнее»). Но они непроверяемые. Вот код на C#, аналогичный приведённому выше плюсовому: Q>
interface IBarable
Q>{
Q> void Bar();
Q>}
Q>...
Q>static void Foo<T>(T t) where T: IBarable
Q>{
Q> t.Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
Q>}
Q>
При наличии IBarable.Baz не ловится.
Ну и, в том же дотнете гораздо чаще случаются ошибки, когда вызывается не та сигнатура Bar, что ожидал разработчик. Тут только тесты помогут, повторюсь, которые должны проверить все ветки кода.
Q>Тут ошибка не только будет сразу подчёркнута в IDE, но ещё и по точке intellisense выдаст список допустимых ограничениями методов. Могут ли такое в C++ упомянутые «имеющиеся ср-ва языка в декларативном стиле, с полтыка найденные на этом сайте»?
В С++ intellisense уж точно не предложит никакого baz. ))
Ну и, опять повторюсь, что ограничения в стиле C# организовать можно:
using namespace std;
#define where(A, Predicate, B) \
static_assert(Predicate<A, B>::value, "Predicate "#A" "#Predicate" "#B" is not satisfied")
template<typename T>
struct A {
void foo() {}
};
template<typename T>
struct B {
where(A<T>, is_base_of, T);
void bar(T * t) { t->foo(); } // ok
};
struct C : A<C> {};
struct D {};
B<C> bc; // ok
B<D> bd; // error C2338: Predicate A<T> is_base_of T is not satisfied
Можно и помощнее ограничения задавать, ес-но, см. <type_traits>.
Или можно на основе is_base_of сделать предикат is_derived_from, поменяв аргументы-типы местами (для дотнетчиков так привычней).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, AlexRK, Вы писали:
_>>>А большую часть ПО возможно создавать как на C++, так и на C#. И соответственно тут уже возникает вопрос выбора с точки зрения бизнес эффективности. ARK>>Вот этот самый выбор, как мне кажется, не имеет смысла. Если именно С++ не требуется, то просто берется C#.
_>Ну вот возьми набор ПО на своём домашнем компьютере (хотя конечно комп разработчика далёк от среднего, но для простейшей прикидки пойдёт) и посчитай какой процент написан на C#. А получив эту цифру обдумай кто является не прав, ты со своей позицией или вся остальная IT индустрия. )))
Ну на моем то полно своих в том числе и 1С использующий библиотеки .net.
А вот , что касается приложений, то я думаю, что больше проблема в обфускации, которую кардинально решает .net Native.
И которых будет значительно больше c популярностью UWP и поддерживаемых платформ и оборудования.
Согласно слухам, для поддержки 4K разработчикам потребуется приложить минимальные усилия, если их игры уже являются частью Universal Windows Platform (UWP). Якобы любой проект, выпущенный на UWP в Windows 10, сможет исполняться на следующей Xbox в разрешении 4K. Другими словами, игры Gears of War 4, ReCore, Forza Horizon 3 или Rise of the Tomb Raider на Scorpio должны выглядеть не хуже, чем сегодня на ПК в разрешении 4K. Microsoft считает, что кроссплатформенные игры, в которые разработчики уже внедрили 4K-оптимизации для PS4 Pro получат аналогичные преимущества и на платформе Scorpio.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, lpd, Вы писали:
_>>Что ты называешь прямым управлением памятью? Например локальная переменная на стеке (самый правильный способ работы с данными в современном C++) — это прямое управление или нет? ) Или ты имеешь в виду вызовы new/delete? Если последнее, то как раз в правильном современном приложение на C++ их может не быть вообще. И при этом производительность будет не хуже ручного ассемблерного кода. ))) lpd>Под прямым управлением памятью я имею ввиду new/delete и указатели, которые пытаются исключить. Но ценой этого оказывается усложнение языка разными типами ссылок и правилами их преобразования.
Всё верно. Это и есть направление развития современного C++. Он даёт полную автоматизацию работы с памятью и другими ресурсами при этом без малейших потерь в производительности. Т.е. в этом смысле он существенно превосходит и древний C и современные управляемые языки. А ценой этого является требование повышенной квалификации программистов.
lpd>Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++.
Ну естественно в ffmpeg написанном на C (и ассемблере) не используются последние новинки C++. ))) А как ты хотел то? )
lpd>Вот лямбды и потоки — да, полезны. Было бы лучше, если бы C++ развивался не в сторону теоретического улучшения языка, как краткой записи абстрактных операций над абстрактными данными, а в сторону расширения области применения и сближения по удобству всего процесса разработки с Java-фреймворками и инфраструктурой, без излишнего усложнения.
Как раз Java стиль является максимально не эффективным и современный C++ развивается в прямо противоположном направление. Но если хочется именно такого, то оно в мире C++ тоже давно есть. Называется Qt. Там как раз наблюдается Java стиль во всём, но для GUI эта не эффективность не так страшна. И кстати стать "программистом на Qt" довольно просто. )))
Re[17]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Klikujiskaaan, Вы писали:
_>>Тебе нужны пруфы на то, что поисковые движки в Яндексе и Гугле написаны на C++? Это же давным давно общеизвестная информация. Ты совсем не интересуешься происходящем в индустрии? ) K>Пруфы на "Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки" неси. ))))))))))))))))))))))))))))))))))))))))
А это не моя фраза, так что доказывать её я не собираюсь. Я лишь указал тебе, что подобные фреймворки уже давно существуют и активно используются. Но очевидно, что для вытеснения C#/Java они не предназначены в силу своей узкой специализации. Вытесняют C#/Java в области веба скорее всякие js/python/ruby и прочие php. )))
Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++. _>Ну естественно в ffmpeg написанном на C (и ассемблере) не используются последние новинки C++. ))) А как ты хотел то? )
Скорость копирования DDR-памяти порядка 10Гбайт/сек, и делать move всех мелких объектов нет никакого смысла. Речь о том, что ffmpeg это тот самый редкий случай, когда затраты времени на копирование могут играть роль. И там простые буфера памяти — даже не классы контейнеров. Мы видим, что в реализациях алгоритмов, где move-семантика может понадобиться, ей нет места, и может не быть места даже ООП.
Я не могу придумать ни одного примера программы, для которой move-семантика была бы реально нужна.
Кроме того, помним, что ООП нужен для моделирования объектов — в основном, для наглядности архитектуры. Понятие указателя наглядно, как наглядно и понятие ссылки. А что такое rvalue-ссылка? Это какой-то синтаксический хак, позволяющий поставить && и изменить поведение программы.
Может не нужно реализовывать в C++ нереализуемое, и оставить и объекты, и старое доброе ручное управление памятью — для тех случаев, когда оно нужно? C++, в том числе, ценен схожестью c C и близостью к ассемблеру/оборудованию — и в этом его конек с точки зрения эффективности.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>А это не моя фраза, так что доказывать её я не собираюсь. Я лишь указал тебе, что подобные фреймворки уже давно существуют и активно используются. Но очевидно, что для вытеснения C#/Java они не предназначены в силу своей узкой специализации. Вытесняют C#/Java в области веба скорее всякие js/python/ruby и прочие php. )))
Т.е. ты рот открыл даже не прочитав на что отвечаешь, яснопонятно.
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
ARK>Но понятно, что standalone приложения на C# пишутся довольно редко, с этим никто не спорит.
Вообще то как раз с этим ты и спорил. Иначе как тогда понять твою фразу "Если именно С++ не требуется, то просто берется C#."?
ARK>Но, ИМХО, в данном случае вполне уместно говорить, что требования к упомянутым мной приложениям исключают применение C#, т.к. в большинстве из них нужна приличная скорость.
Почти все перечисленные тобой приложения можно написать и на C++ и на C#. Да, на C# они будут более убогими, но всё же работать будут. Так что под указанный мною шаг1 это не подходит.
Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
ARK>>Но понятно, что standalone приложения на C# пишутся довольно редко, с этим никто не спорит. _>Вообще то как раз с этим ты и спорил. Иначе как тогда понять твою фразу "Если именно С++ не требуется, то просто берется C#."?
Я бы не стал смешивать в одну кучу разработку на заказ с целью извлечения прибыли (о чем речь в этой теме) и создание программ энтузиастами "для души". Во втором случае никаких правил нет, кто чего знает или любит, тот на том и пишет, независимо от того, оптимально оно или нет.
Среди перечисленных мной приложений коммерческими являются только Skype и iTunes (ну и Firefox в каком-то смысле). Все они по разным причинам в не могут быть созданы на C#, в основном из-за кроссплатформенности.
_>Почти все перечисленные тобой приложения можно написать и на C++ и на C#. Да, на C# они будут более убогими, но всё же работать будут. Так что под указанный мною шаг1 это не подходит.
Если их в принципе можно написать на C#, то они будут не хуже. Не просто "работать будут", а не будет никакой разницы с С++.
Re[11]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, itslave, Вы писали:
_>>Вообще то все топовые веб-сервера (nginx, Apache, IIS и т.п.) и все топовые РСУБД (PostgreSQL, MySQl, SQL Server, Oracle и т.п.) написаны на C/C++. Так что не очень понятно о чём собственно речь. ))) I>Речь, как заметил аффтар выше по треду, о сферических веб приложениях в вакууме. Ессна же использующих и субд и веб сервера, написанные н С/С++, равно как операционные системы, написанные на С, драйвера, возможно написанные на ассемблере, схемотехнические решения (компы) и так далее.
ОС, драйверы и т.д. — это уже другой вопрос, связанный с универсальным доступом к произвольному железу. А вот веб — это классическая прикладная задача, которая упрощённо (если не рассматривать промежуточную сетевую инфраструктуру) представляет собой классическое клиент-серверное приложение. В качестве сервера у нас тут выступают http-демоны (написанные на C/C++), кастомизируемые скриптами (которые пишутся на множестве языков) под конкретный сайт. А в качестве клиента у нас выступают браузеры (написанные на C++) и кастомизируемые скриптами (которые пока пишутся на монопольном JS, но надеюсь с приходом WebAssembly это изменится) под конкретный сайт.
I>И так, конкретные веб приложения проще, быстрей и дешевле педалить на управляемых языках, вне зависимости от количества конкурентных пользователей — перфоманс языка программирование ничто по сравнению с перфомансом используемых компонентов.
Если ты под веб-приложением подразумеваешь набор этих самых серверных и клиентских скриптов, то полностью с тобой согласен (ну точнее есть исключения типа Гугла, Яндекса и т.п. но это уже редкие случаи). Разве что ещё уточню, что на так называемых скриптовых языках (js/python/ruby и даже убогий php) это делается ещё быстрее и дешевле.
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, itslave, Вы писали:
_>>Ну вот возьми набор ПО на своём домашнем компьютере (хотя конечно комп разработчика далёк от среднего, но для простейшей прикидки пойдёт) и посчитай какой процент написан на C#. А получив эту цифру обдумай кто является не прав, ты со своей позицией или вся остальная IT индустрия. ))) I>Возьми свои букмарки и посчитай, сколько веб серверов написаны на С++. Начни с РСДН. А получив эту цифру обдумай, где же сейчас бизнес живет.
Вообще то мы уже обсудили, что на каждом из них как раз работает сервер написанный на C/C++. И на РСДН в том числе (там же IIS, правильно?). Но даже если говорить исключительно о серверных скриптах, то применяя твой подход получим, что веб живёт в основном в мире php. )))
P.S. Я так и не понял, зачем подняли вопрос веба в теме про десктопные приложения для винды?
Здравствуйте, Qbit86, Вы писали:
_>>Что-то ты тут бредишь... Q>Хамовато.
А по твоему утверждение о том, что в VisualStudio навигация под коду реализуется компилятором C++ можно назвать чем-то иным кроме бреда? )
_>>1. Компиляторы не имеет никакого отношения ни к каким "Go To Declaration" или "Go To Definition". Они занимаются исключительно преобразованием исходных кодов в исполняемые и всё. Q>Это в нормальных языках. В C++ исходные коды шаблонов компилятор автора библиотеки в испольняемые файлы не преобразует. Библиотека поставляются пользователю в текстовом виде как есть.
Если под пользователем ты имеешь в виду программиста, использующего библиотеку, то да, всё верно. Только какое это имеет отношение к моему утверждению? )
_>>А то, что ты описываешь — это работа IDE, у которых для этих целей есть свои анализаторы кода. Q>Могут быть свои, могуть быть общие. В Visual Studio двигаются в сторону использования платформы Roslyn как для собственно компиляции, так и сервисов анализа кода.
Вот когда будет так работать, тогда и будешь об этом упоминать. Не говоря уже о том, что непонятно какое отношение имеет Roslyn к навигации по коду в C++, про мифические недостатки которой ты тут писал.
_>>Уточни про какую конкретную IDE ты пишешь Q>Выше уже уточнял: MSVS Community 2017 RC в режиме C++17.
VS является приемлемой IDE для C++ только после установки набора дополнений. Типа VisualAssist, VisualGDB, Resharper C++ и т.п. В голом виде она убога.
_>>...и какие конкретно примеры в ней работают не так, как тебе нравится. Q>Навигация по разным функциям в Boost Graph Library и в окрестности.
Ну можно конкретный пример кода, который у тебя работает не так как надо? ) И соответственно с описание того, как тебе надо.
_>>Естественно речь про лидеров в данной области, а не про всякие убогие IDE. Q>А можно список лидеров и неубогих IDE? Я проверю, если не поленюсь (и если бесплатно).
Netbeans, CLion, Eclipse, QtCreator. У последнего специфические свойства — анализатор вроде не полный, но при этом есть некоторые возможности рефакторинга, работающий поудобнее тех, у которых анализатор полноценный. Так что частенько с помощью него работать удобнее всего, но это тема для другого разговора.
Здравствуйте, Qbit86, Вы писали:
I>>Возьми свои букмарки и посчитай, сколько веб серверов написаны на С++. Начни с РСДН. Q>Нет, начни со StackOverflow
Кстати, на этом форуме не так давно обсуждалась архитектура StackOverflow (в теме про тормознутость Linq в роли ORM). Так вот там всё довольно любопытно. Изначально у них была классическая архитектура в стиле C#, но она жутко тормозила (их сервера с трудом тянули нагрузку в разы меньшую нынешней). А потом они произвели существенную оптимизацию (https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/) и всё стало отлично. Так вот помимо обсуждаемого отказа от Linq, они сделали ещё много принципиальных изменений и наверное главным было активное использование Redis'a (надо ли напоминать на чём он написан?), который и держит сейчас всю основную нагрузку на их сервер.
