Здравствуйте, AlexGin, Вы писали:
AG>А почему сразу не взять Qt и творить на плюсах с удовольствием?
Дык, ровно наоборот. ))
QT унутре устарел еще примерно в 2002-2003-х годах, когда все популярные компиляторы стали примерно одинаково поддерживать частичную специализацию и библиотечную инстанциацию шаблонов, но при этом внутренняя философия этой библиотеки не была пересмотрена.
QT — это же не только GUI, это куча оберток на нейтивными АПИ сетки, файлов, прмитивов синхронизации, таймеров и т.д. и т.п.
Потому и стали аналогичные либы из "молодого" (на тот момент) буста более популярны в те же года, что QT явно не дотягивал до понятия "библиотека для С++".
Здравствуйте, sergey2b, Вы писали:
KP>>Модель памяти Qt из 90-х прошлого века. Это главная проблема. S>я не работал с Qt объясни пожалуйста, что ты имееш ввиду
Я имею ввиду активное использование `new` без умных указателей, что является плохим тоном в современном C++. Так же Qt активно использует парадигму дочерних объектов, когда ты вроде сделал голое `new` и не сделал `delete`, но объект магически удалится так как является дочерним для кого-то там. А может и не удалиться, и это надо знать, либо вылавливать. Дремучие 90-е, короче
Здравствуйте, vdimas, Вы писали:
V>QT унутре устарел еще примерно в 2002-2003-х годах, когда все популярные компиляторы стали примерно одинаково поддерживать частичную специализацию и библиотечную инстанциацию шаблонов, но при этом внутренняя философия этой библиотеки не была пересмотрена.
Так как новые пакеты (скажем так — minor version) Qt выходят каждые пол-года, то данная информация уже потеряла актуальность.
Здравствуйте, AlexGin, Вы писали:
V>>QT унутре устарел еще примерно в 2002-2003-х годах, когда все популярные компиляторы стали примерно одинаково поддерживать частичную специализацию и библиотечную инстанциацию шаблонов, но при этом внутренняя философия этой библиотеки не была пересмотрена. AG>Так как новые пакеты (скажем так — minor version) Qt выходят каждые пол-года, то данная информация уже потеряла актуальность.
Да хоть каждый день пусть пакеты выходят.
Пока с ними не приходит обновления архитектуры — это ни о чём.
V>>QT — это же не только GUI, это куча оберток на нейтивными АПИ сетки, файлов, прмитивов синхронизации, таймеров и т.д. и т.п. V>>Потому и стали аналогичные либы из "молодого" (на тот момент) буста более популярны в те же года, что QT явно не дотягивал до понятия "библиотека для С++". AG>Спасибо, я в курсе. AG>Занимаюсь на Qt последние три года.
Я последние 20 лет за этой либу слежу — ничего не меняется.
Шлак и есть шлак.
Да, этот шлак "вылизали", пофиксили баги, заставили выглядеть достойной картинкой и работать на большем кол-ве платформ.
Но рвотный рефлекс никуда не делся.
Именно поэтому когда-то появились wxWidgets поверх SDL и бинд GTK на С++.
Где-то даже обидно от всей этой ситуации.
Здравствуйте, sergey2b, Вы писали:
D>>Потом возвращаешься на .NET, и вспоминаешь как кошмар. В общем я пару раз подумаю прежде чем на плюсах что-то писать, и если можно без него обойтись я так и сделаю.
S>а дефрагментатор или компилятор на C# написать сможете
А в чём проблема? Для дефрагментатора у винды вроде есть API. Логику на C# может и надёжней написать будет.
Здравствуйте, Shmj, Вы писали:
S>C#/Java — очень чистые и красивые языки. Если сравнить с C++ — это как дикая природа (C++) с кучей опасностей и нагромождений и красивый ухоженный парк (C#).
S>Да, C++ технологически и надежнее (можно гарантировать что и через 10 и через 20 лет он будет использоваться) и намного шире по спектру применения. Но, подозреваю, что чисто психологически перейти не возможно. Можно только так C++ -> C# и потом опять C++.
Если был до шарпа опыт языков низкого уровня — то думаю запросто. Если небыло, да еще разработчику лет 35 и лет 15 опыта шарпа — то на указателях запросто можно споткнуться и никогда не встать. такие понятия нужно как можно раньше впитывать.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, AlexGin, Вы писали:
AG>>То есть, в сухом остатке проверки на CLANG?
KP>Не Clang, а clang-tidy, это самостоятельное приложение не являющееся компилятором.
Ясно, здесь я просто подумал насчёт CLANG компилятора. Инерция подсознания
AG>>Кстати, для Linux — можно применять также и gcc?
KP>Не понял вопроса. На Linux GCC – основной компилятор, где скорее при желании можно применять Clang.
Да, я именно о том, что Qt под Linux в основном предполагает компилятор GCC — по крайней мере менеджеры пакетов Debian и Ubuntu-Linux
обычно предлагают вариант под GCC (g++).
Здравствуйте, Shmj, Вы писали:
S>C#/Java — очень чистые и красивые языки. Если сравнить с C++ — это как дикая природа (C++) с кучей опасностей и нагромождений и красивый ухоженный парк (C#).
S>Да, C++ технологически и надежнее (можно гарантировать что и через 10 и через 20 лет он будет использоваться) и намного шире по спектру применения. Но, подозреваю, что чисто психологически перейти не возможно. Можно только так C++ -> C# и потом опять C++.
Переходил, основные проблемы были не от языка как такового (у него, кстати, хватает плюсов ), а скорее от обвязки, которую приходилось использовать — среда строго eclipse, где автодополнение не могло нормально выводить типы, стандартные библиотеки частично не работали (при попытке использовать auto_ptr из стандарта программа падала), valgrind на стороне эмулятора не позволял добавить исключения для стандартной библиотеки (10000+ сообщений — попробуй найти проблему, facepalm), сама библиотека GUI после Java вызывала тошноту (крайне неудобно модифицировать что-либо). Ну и документация была с огромными пробелами.
В общем, нет смысла говорить "Как вы перешли с одного языка на другой" без упоминания фрэймворков и обвязки всего этого — сами языки, обычно, проблемы не вызывают.
ЗЫ RAII в С++ мне очень нравится, крайне не хватает подобного в шарпе (это только для примера, насчёт lock в курсе):
Здравствуйте, Grizzli, Вы писали:
G>Если был до шарпа опыт языков низкого уровня — то думаю запросто. Если небыло, да еще разработчику лет 35 и лет 15 опыта шарпа — то на указателях запросто можно споткнуться и никогда не встать. такие понятия нужно как можно раньше впитывать.
А можно поинтересоваться, что в этих указателях такого? В шарпе до черта передается по ссылке. По существу это тот же указатель, только для него определена адресная арифметика, нельзя к ссылке что то прибавить и потом получить значения. Но при этом, если выделять память под огроменный массив байт, то индекс массива будет практически 100 процентным указателем. Единственное отличие — если выйдешь за границу массива — тебе исключение кинется, а не будет не пойми что. То есть от тебя просто требуют в плюсах к большей внимательности, ибо банальная опечатка может проявиться хрен знает когда.
И какой бы ты гуру ни был, а при прямых небезопасных операций с указателями ты рано или поздно ошибешься. Соответственно даже плюсовики стараются этой адресной арифметикой практически не пользоваться. А юзают итераторы, смартпоинтеры и тому подобное. Тоже самое, что в управляемых языках по существу, там тоже оперируют чаще всего более высокими абстракциями, чем простые массивы. Единственное — синтаксис поприятнее и покороче выглядит. Соответственно просто опытный разработчик на плюсах, который всякие *(&(***&(i+1))+10)[5] который писал только в институте, а потом избегал такое дерьмо как только мог — он лет через 15 тоже будет в черти каком шоке, когда в коде такое увидит. А когда успокоится и начнет из приличных слов говорить не только предлоги, захочет еще и поубивать захочет тех, кто такое додумался написать .
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Grizzli, Вы писали:
G>>Если был до шарпа опыт языков низкого уровня — то думаю запросто. Если небыло, да еще разработчику лет 35 и лет 15 опыта шарпа — то на указателях запросто можно споткнуться и никогда не встать. такие понятия нужно как можно раньше впитывать. E>А можно поинтересоваться, что в этих указателях такого? В шарпе до черта передается по ссылке.
Передается, но делается это очень мяганько, настолько, что можно 15 лет проработать и даже особо не думать о том как там и где и что передается.
А в си — указатель на указатель, да еще и арифметика по этому всемУ, утечки и проходы по памяти как следствие — если сходу все это не впитал — потом может быть нелегко для понимания.
Здравствуйте, Grizzli, Вы писали:
G>А в си — указатель на указатель, да еще и арифметика по этому всемУ, утечки и проходы по памяти как следствие — если сходу все это не впитал — потом может быть нелегко для понимания.
Так то в С, а речь то про С++
Здравствуйте, Grizzli, Вы писали:
G>Передается, но делается это очень мяганько, настолько, что можно 15 лет проработать и даже особо не думать о том как там и где и что передается. G>А в си — указатель на указатель, да еще и арифметика по этому всемУ, утечки и проходы по памяти как следствие — если сходу все это не впитал — потом может быть нелегко для понимания.
Всё таки речь идёт о С++, а в нём также как и в C# стараются поменьше видеть указателей в коде.
Кроме того в C# есть указатели если кто-то по ним скучает https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/unsafe-code-pointers/pointer-types
Здравствуйте, Somescout, Вы писали:
S>ЗЫ RAII в С++ мне очень нравится, крайне не хватает подобного в шарпе (это только для примера, насчёт lock в курсе): S>
S>{
S> MutexGuard lock(mutex);
S> /// do something
S>}
S>
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В шарпе для гардов есть using.
Знаю, и в целом оно даже похоже, но сама идея что объект автоматически уничтожается при выходе из области видимости мне нравится. Фактически в C++ при использовании таких объектов нельзя сделать ошибку — очистка ресурсов гарантирована всегда.
Здравствуйте, Somescout, Вы писали:
S>Знаю, и в целом оно даже похоже, но сама идея что объект автоматически уничтожается при выходе из области видимости мне нравится. Фактически в C++ при использовании таких объектов нельзя сделать ошибку — очистка ресурсов гарантирована всегда.
Читаемость кода это не улучшает. И если при управлении памятью это еще сносно, так как слишком много этого управления, то в случае со всякими гардами явное выделение скоупа оператором лучше.
G>Если был до шарпа опыт языков низкого уровня — то думаю запросто. Если небыло, да еще разработчику лет 35 и лет 15 опыта шарпа — то на указателях запросто можно споткнуться и никогда не встать. такие понятия нужно как можно раньше впитывать.
Указатели как раз-таки не самое сложное в C++. Потому что нормальные разрабочики избегают использования адресной арифметики в коде на С++, используются векторы, итераторы из STL или Boost.
Другие фишки будут корежить мозг:
— Множественное наследование классов в С++ (хотя нормальные разработчики и в С++ избегают такой фишки)
— Различия между generic C# & templates в C++
— Отсутствие LINQ (хотя ХЗ, может уже и есть LINQ)
— Отсутствие Expression tree
— Отсутствие reflection.
— Отсутствие событий как единицы синтаксиса.
Список можно продолжать и продолжать...
В общем ломка будет очень сильной, но не смертельной ;)
P.S. Другой вопрос — за чем? В финансы, высокочастотный трейдинг или куда хочешь пойти?
