Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\
S>те когда это еще Си с классами, а вот после этого стал уже С++
Очень просто, когда не пытаются выпихнуть обработку данных в complile-time и использовать шаблонные не поназначению, а просто пишут код которые решает поставленнуюю задачу, вы без иде можете сказать какой тип у переменной — это C с классами.
А вот когда у вас кругом header-only, шаблон на шалоне, везде где только можно move-семантика, смарт поинтеры, для компиляции нужно топовое железо, огромное количество кода которой не решает задау, а делает "удобнее", "правильнее" и "всеобъемлюще", при этом создаётся больше проблем чем решается и любая незначительная опечатка приводит к неочевидной ошибке компиляции которую надо еще самому долго вкуривать — вот тут уже следует насторажиться видимо современный C++ где-то рядом.
Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\ S>те когда это еще Си с классами, а вот после этого стал уже С++
С с классами изначально и был С++.
Потом уже пришли люди которые вернули греческую и римскую культуры назад в варварство и средневековье. Дикари compile time. Это было еще терпимо. Просто слушаешь шизиков киваешь улыбаешься, пока кто не вызовет доктора. Но потом дно стало еще хуже потому что туда стали заходить люди из микрозофт.
Они стали говорить — мы сейчас вам сделаем тут си щарп — вариадики все это, смарт поинтеры. Когда у них спрашивает зачем языку с ручным управлением памяти смарт поинтеры, они отвечают — ну как — мы же не учились управлять памятью в кулинарных техникумах. Грэйт джаб гайз!!!
Просто пользуйте С++ 11 с ООП и все. stl неплох в базе но к нему есть вопросы кое что там пользовать можно.
Здравствуйте, sergey2b, Вы писали: S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\ S>те когда это еще Си с классами, а вот после этого стал уже С++
Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
коммент
На С++ этого рубежа можно (и нужно) достичь, примерно, за неделю разработки.
Если не поможет, будем действовать током... 600 Вольт (C)
Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\
Попытаюсь выразить моё ИМХО, чтобы совсем уж не свалиться в КСВ...
Так, если три кита ООП это:
1) инкапсуляция
2) наследование
3) полиморфизм
Значит, Си с классами — это только первый шаг, когда кроме инкапсуляции, ничего другого (пока???) не умеют...
Достаточно точное определение: https://toster.ru/q/124001
S>те когда это еще Си с классами, а вот после этого стал уже С++
Вот когда поняли, что такое абстрактный базовый класс и чисто виртуальный метод...
Тогда пора бежать в магазин за бутылкой — справлять новоселье в доме С++
Ну а понимание концепции RTTI и всяких там dynamic_cast<...>() — это вообще праздник
Здравствуйте, -MyXa-, Вы писали:
... MX>Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
1) Это далеко не всегда так;
2) Сильно зависит от оборудования (я считаю, что компилировать проект нужно всегда на шустром SSD, а не на HDD).
Так, на современном компе проект на несколько человеко-лет с вполне даже C++11/14/17 уложится в это время,
особенно если в процессе рефакторинга прогеры выбрасывали ненужную хрень из проекта
MX>На С++ этого рубежа можно (и нужно) достичь, примерно, за неделю разработки.
Также очень спорное утверждение. Тем более спорное — насчет нужно:
обычно всё-таки стараешься решить поставленную задачу, а не просто раздуть объем полученного кода...
Здравствуйте, -MyXa-, Вы писали:
MX>Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
Сильно зависит от проекта. Я видел крупный проект на чистом Си, который собирается гораздо дольше.
Здравствуйте, kov_serg, Вы писали:
_>Очень просто, когда не пытаются выпихнуть обработку данных в complile-time и использовать шаблонные не поназначению, а просто пишут код которые решает поставленнуюю задачу, вы без иде можете сказать какой тип у переменной — это C с классами.
Конечно, там почти все
void*
А также лапша из макросов, функции по 500+ строк, goto exit, куча похожего кода который делает почти тоже самое и прочие "радости".
_>А вот когда у вас кругом header-only, шаблон на шалоне, везде где только можно move-семантика, смарт поинтеры, для компиляции нужно топовое железо, огромное количество кода которой не решает задау, а делает "удобнее", "правильнее" и "всеобъемлюще", при этом создаётся больше проблем чем решается и любая незначительная опечатка приводит к неочевидной ошибке компиляции которую надо еще самому долго вкуривать — вот тут уже следует насторажиться видимо современный C++ где-то рядом.
Для большинства задач можно и без крайностей. В общем случае такие "крайности" дают остальным нормальные кросс-платформенные строки, контейнеры, доступ к файловой системе и т.д. с минимально возможными издержками.
Здравствуйте, σ, Вы писали:
S>>Прочел соседнию ветку S>>объясните плиз чем Си с классами отличаеться от C++\
S>>те когда это еще Си с классами, а вот после этого стал уже С++
σ>См. Страуструп "Дизайн и эволюция языка C++" раздел 3.1 "От C with Classes к C++".
Чёткой грани нет. Например, кто-то считает, что использование virtual member functions это уже С++, хотя есть проекты на Си, которые вполне успешно эмулируют vtbl через массив + макросы. Большинство остальных элементов С++ тоже так или иначе реализуются на чистом Си или с раширешниями (например, RAII через аттрибут переменной __cleanup). Другое дело, что компилятор С++ может при прочих равных гарантиировать какую-то долю целостности. Я считаю более корректно — говорить "на проекте используется подмножество С++" с указаем того, что используется.
Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\
S>те когда это еще Си с классами, а вот после этого стал уже С++
Чёткой грани нет. Например, кто-то считает, что использование virtual member functions это уже С++, хотя есть проекты на Си, которые вполне успешно эмулируют vtbl через массив + макросы. Большинство остальных элементов С++ тоже так или иначе реализуются на чистом Си или с раширешниями (например, RAII через аттрибут переменной __cleanup). Другое дело, что компилятор С++ может при прочих равных гарантиировать какую-то долю целостности. Я считаю более корректно — говорить "на проекте используется подмножество С++" с указаем того, что используется.
Здравствуйте, Skorodum, Вы писали:
S>Для большинства задач можно и без крайностей. В общем случае такие "крайности" дают остальным нормальные кросс-платформенные строки, контейнеры, доступ к файловой системе и т.д. с минимально возможными издержками.
Про кросс-платформенный доступ к ФС смешно. Как открыть на винде файл с юникодным именем?
Но в целом я не спорю, кстати, большинство наворотов в языке по делу. Просто часто программисты используют их по другому делу, неподходящему
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Про кросс-платформенный доступ к ФС смешно. Как открыть на винде файл с юникодным именем?
OpenFileW(), fwopen().
В C++17 появилась библиотека std::filesystem, которая умеет преобразовывать std::wstring в путь в кодировке ОС, а так-же умеет работать с UTF-8, UTF-16 и UTF-32.
Здравствуйте, AleksandrN, Вы писали:
AN>OpenFileW(), fwopen().
Это не совместимо
AN>В C++17 появилась библиотека std::filesystem, которая умеет преобразовывать std::wstring в путь в кодировке ОС, а так-же умеет работать с UTF-8, UTF-16 и UTF-32.
AN>NTFS хранит имя файла в юникоде.
У винды, понятно, что всё в порядке с именами. Имена, кстати, могут ни в какую кодировку не укладываться, кроме юникода. Например каталог польский, а файл русский...
Так как мне написать совместимый код, который из текстового конфигурационника читает путь к файлу и возвращает istream ?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>У винды, понятно, что всё в порядке с именами. Имена, кстати, могут ни в какую кодировку не укладываться, кроме юникода. Например каталог польский, а файл русский...
E>Так как мне написать совместимый код, который из текстового конфигурационника читает путь к файлу и возвращает istream ?
Небольшую обёртку написать.
Реализация ifstream в MSVC++ содержит конструкторы и функции open() с параметрами wchar_t* и std::wstring. Поэтому — реализовывай следующим образом:
Конфигурацию хранить в UTF-8. Под Виндовс конвертировать строку в wstring, под Linux — в кодировку текущей локали (сейчас обычно везде UTF-8). Сконвертированную строку используй в ifstream.
Без #ifdef не обойтись, но платформозависимого кода будет немного.
Здравствуйте, AleksandrN, Вы писали:
AN>Без #ifdef не обойтись, но платформозависимого кода будет немного.
Ха, в таком режиме я и без STL умею...
Это про сто про совместимый доступ к файлам.
Если истории с юникодными именами файлов мало, можно задуматься над тем на какой платформе когда увеличивается длина файла на диске, когда мы открываем его на запись, потом делаем seek за конец, потом туда пишем
И т. д...
Ещё, кстати, можно задуматься над значением выражений вроде 155 >> 128
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, -MyXa-, Вы писали:
MX>Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
Не-а. У нас был проект многолетний, там сишная часть собиралась на HT-процах 20 минут. Но это был именно "ANSI C" для железяк и классический "C с классами" для десктопной части — там даже STL с таким боем удалось протолкнуть для работы с векторами и мэпами, что мама не горюй (ваш код никто не поймёт! да и вы сами тоже через N месяцев!)
Здравствуйте, AlexGin, Вы писали:
AG>Так, если три кита ООП это: AG>1) инкапсуляция AG>2) наследование AG>3) полиморфизм
AG>Значит, Си с классами — это только первый шаг, когда кроме инкапсуляции, ничего другого (пока???) не умеют...
AG>Достаточно точное определение: AG>https://toster.ru/q/124001
S>>те когда это еще Си с классами, а вот после этого стал уже С++
AG>Вот когда поняли, что такое абстрактный базовый класс и чисто виртуальный метод... AG> AG>Тогда пора бежать в магазин за бутылкой — справлять новоселье в доме С++
Гы-гы-гы, это называется "перестал быть джуном"
Настоящий С++ это именно шаблоны и всё такое, когда программа пишет сама себя. (если что, то я его точно знаю на Hello-world уровне)
Здравствуйте, Mr.Delphist, Вы писали:
MD>Не-а. У нас был проект многолетний, там сишная часть собиралась на HT-процах 20 минут. Но это был именно "ANSI C" для железяк и классический "C с классами" для десктопной части — там даже STL с таким боем удалось протолкнуть для работы с векторами и мэпами, что мама не горюй (ваш код никто не поймёт! да и вы сами тоже через N месяцев!)
20 минут — это ещё ничего.
Я участвовал в проекте, где проект собирался 8 (прописью — ВОСЕМЬ) часов.
Да, да и там не было ничего сложнее STL-я.
>объясните плиз чем Си с классами отличаеться от C++\ S>те когда это еще Си с классами, а вот после этого стал уже С++
Говнокод на С++, написанный С-шником -- это "С с классами".
Коды возврата вместо исключений.
Возврат значений через указатель на результат в параметре.
Указатели на коллбэки вместо полиморфизма.
Макросы вместо шаблонов.
И так далее.
