LINUX.ORG.RU

В C++20 появятся виртуальные функции!

 


0

4

Несколько часов назад в драфт стандарта были смёржены коммиты, определяющие термин «виртуальная функция». До сих пор такого определения не было.

★★★

Последнее исправление: utf8nowhere (всего исправлений: 1)

Ответ на: комментарий от eao197

Затем, чтобы можно было производить вычисления в compile-time и затем использовать их контексте, где требуется константа. Например, при объявлении C-шных массивов. Или параметризации шаблонов скалярами. Скажем:

Я бы еще добавил, что при помощи constexpr можно делать переносимые и читаемые генераторы масок для выравнивания указателей/размеров у буфферов данных в том же реал-тайм сегменте. При этом сохраняя и читаемость, и zero-cost, и краткость, и переносимость на разные аппаратные платформы. Но только консерваторы не способны понять нужность той или иной фичи - «не надо! это новомодный хлам»

Dudraug ★★★★★
()
Ответ на: комментарий от eao197

раз уж его добавили и им пользуются, то кому-то он был сильно нужен

стандарты пишутся не потому, что какому-то васе захотелось вдруг какую-то фичу. а потому, что есть реальная насущная необходимость. в этом и проблема бешеного принтера.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Dudraug

Да много чего полезного можно делать. Это когда constexpr в компиляторе нет, тогда и кажется, что не проблема писать в духе 1990-х.

Только мы, походу, пытаемся это донести человеку, который constexpr даже и не пробовал.

eao197 ★★★★★
()
Ответ на: комментарий от Dudraug

маски всегда задавались константами. и с этим не было никаких проблем. ни с переносимостью, ни с читабельностью. вот дофига лет с этим работала и никогда не было проблем. даже на микроконтроллерах. так что можно натягивать сову на глобус, но это не обоснование.

Iron_Bug ★★★★★
()
Ответ на: комментарий от eao197

И зачем есть C, когда есть ассемблер.

Не, ну С понятно зачем — затем, что процессорных архитектур больше одной. Его поэтому и называют «переносимый ассемблер».

А вот без крестов при наличии сишечки обойтись в принципе можно... если не интересует производительность труда программиста и читаемость/сопровождаемость полученных портянок :)

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от eao197

который constexpr даже и не пробовал.

внезапно! наконец-то дошло. потому что за тридцать лет он никогда даже не был нужен. ура. вы начали что-то понимать.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

ура. вы начали что-то понимать.

Да, собственно, всегда были подозрения, что вы и C++а нормального никогда не видели. Не говоря уже про использование современного C++.

eao197 ★★★★★
()
Ответ на: комментарий от hobbit

читабельность и на сишечке можно обеспечить. вполне себе красивый код в кернеле. никто не жалуется. в большинстве случаев даже комментарии не нужны. при грамотном аккуратном коде он легко читается. а сделать нечитабельную фигню на плюсах гораздо проще, чем на сишечке, если уж говорить о синтаксисе :)

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

может, так у нас дальше пойдёт веселуха: в хирургию надо всё больше людей.

не надо передергивать. Очевидно, что если появятся крутые роботы/станки которые могут делать операции, но ими надо управлять через пульт, для обучения работы с которым не надо учиться 8 лет, то очевидно будут набирать простых ребят и туда.

не может непрофессионал писать код.

Более простые ребята - тоже профессионалы. Они делают работу? Делают. Им платят деньги? Платят. Их продукт востребованн рынком? Да. Очевидно, что большая часть глюков в ПО - это вина менеджмента, а не отдельных кодеров. Это же такие простые истины. Код пишет команда, по определенному плану, с определенными ресурсами, с определенным разделением задач, организацией комуникаций и климате в компании, гибкость в смене стратегий и подходов на ходу. Это влияет на качество кода куда сильнее, чем мнимое гиковство.

Dudraug ★★★★★
()
Ответ на: комментарий от hobbit

если не интересует производительность труда программиста и читаемость/сопровождаемость полученных портянок :)

и если при этом не важны сроки и бюджеты.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

нет. я-то его как раз видела. с самого его начала и во всей истории его развития. и понимаю, что «использование современного С++» в 99.99% случаев просто ничем не обосновано. а на практике оно вылезает в ещё большие тормоза, чем классический 98й. хотя теоретически вроде бы там пытались в паре мест что-то оптимтизировать.

в общем, я вижу секту хипстеров-любителей синтаксического сахара. это не опасно, просто глупо. опасно то, что вы защищаете говнокодеров. ещё опаснее то, что комитет пытается лебезить перед говнокодерами и смело несёт в стандарт всякий хлам. ну, это их проблемы. я просто наблюдаю деградацию кода в опенсорце (в корпорациях она тоже есть, просто код не видно). а когда-то, на 98-м, писали очень даже приличный код. и никто не плакал про недостаток фич. всё решалось и работало в сотни раз быстрее.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

маски всегда задавались константами. и с этим не было никаких проблем. ни с переносимостью

constexpr и есть константа.

Только удобненькая.

ни с переносимостью

А вот это не правда. Там или нет переносимости, или говнокод адовый, или надежда на особенности компилятора(что он подсчитает а компайл-тайм то что по стандарту не обязан).

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

Более простые ребята - тоже профессионалы.

профессионал - это профессионал. «тоже» тут неуместно. либо человек программист, либо нет. по крайней мере, в рамках реальных проектов, а не студенческих курсовых. может быть недостаток опыта. но не банальное неумение работы с языком. одного говнокодера в команде хватит, чтобы запороть весь проект.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Dudraug

А можно написать кучу говнокода из ифдефов.

и что ты имеешь против ifdef'ов? писал когда-нибудь кроссплатформу? под разные архитектуры и компиляторы? попробуй на досуге.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

с самого его начала и во всей истории его развития

Даже если за отсчет брать публичный релиз C++ в 1985-ом году, то сильно сомнительно, что в свои 9-10 лет вы могли видеть C++, да еще в СССР. Не говоря уже про еще более раннюю историю.

Так что вы в очередной раз пытаетесь надуть щеки.

и понимаю

С чего бы вам верить?

eao197 ★★★★★
()
Ответ на: комментарий от Iron_Bug

и что ты имеешь против ifdef'ов? писал когда-нибудь кроссплатформу? попробуй на досуге.

Писал, именно поэтому и ругаю. В си++ можно обойтись например буквально парочкой ифдефов в паре хэдеров и мейкфайлов, а остальное разделение специчиного кода сделать через темплейты. Внезапно да?

Dudraug ★★★★★
()
Ответ на: комментарий от eao197

в свои 9-10 лет вы могли видеть C++

именно тогда я и начала его изучать. именно в СССР. на настоящем PC, дома, а не на каком-нибудь спектруме в компьютерном классе.

правда, сначала был С и ассемблер. С++ я начала изучать, когда уже был борланд С++ первой версии. но тем не менее. все первые стандарты я помню. и могу сравнивать. в 13-14 лет я его уже преподавала своим одноклассникам в лицее.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

нет. если код падает в одной мелкой функции, то он падает.

Если код падает, то очевидно, что это не занчит что проект завален. Есть же тестирование(различного уровня), багфиксинг, ревью. Очевидно, что в НОРМАЛЬНОЙ команде один малоопытный, или плохо знающий язык человек не способен завалить проект=)

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

а в си можно просто разнести платформо- или архитектурно-зависимый код в разные файлы. пример - кернел. внезапно, да? так что темплейты тут не нужны. от слова совсем. я всё к этому и веду. что можно сделать просто и красиво. а можно наворачивать кучу ненужно и это не будет ни грамма читабельнее, или быстрее.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

именно тогда я и начала его изучать. именно в СССР. на настоящем PC, дома

правда, сначала был С и ассемблер. С++ я начала изучать, когда уже был борланд С++ первой версии.

ЧТД, вы не видели C++ «с самого начала его развития».

все первые стандарты я помню.

«Все первые» — это единственный от 1998-го?

eao197 ★★★★★
()
Ответ на: комментарий от Dudraug

да, багфиксинг, ревью. нужно больше профессионалов, чтобы править код говнокодера! всё это известные бояны от дешёвых манагеров. но это не работает. по факту, говнокодера проще уволить, чем править за ним его косяки. но таки есть вероятность, что миллион обезьянок за клавиатурами могут написать кернел. наверное, могут. теория вероятностей - штука неоспоримая.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Опять какое-то передергивание. Я уже устал. Ну оставайтесь жить в 20 веке. Только рынок все иначе рассудит.

Dudraug ★★★★★
()
Ответ на: комментарий от eao197

ЧТД, вы не видели C++ «с самого начала его развития».

ну, возможно, пару самых первых компиляторов я пропустила. что не добавляет вам ни одного пункта.

«Все первые» — это единственный от 1998-го?

и то, что было до него! а до него С++ существовал более десяти лет. хотя и в несколько разных реализациях.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Dudraug

хорошо. договорились :)

только вот процессоры сейчас упёрлись в потолок и почему-то все побежали искать тех, кто умеет писать качественный код. рынок рассудит.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

что не добавляет вам ни одного пункта.

Мне? Это вы постоянно прокалываетесь в своих утверждениях.

и то, что было до него! а до него С++ существовал более десяти лет. хотя и в несколько разных реализациях.

Девушка, у слова «стандарт» есть вполне конкретное значение. И, может для вас это станет сюрпризом, первый стандарт (подчеркнем, стандарт) C++ появился в 1998-ом.

До этого стандартов C++ не было. Было несколько версий C++, описанных в разных книгах Б.Страуструпа. Но это не стандарты.

Кстати говоря, тот C++, который вам достался в Turbo C++ 1.0, уже отличался от C++, описанного в самом первом издании «Языка программирования C++». Хотя вряд ли вы Turbo C++ 1.0 видели, скорее уже сразу Borland C++ 2.0.

eao197 ★★★★★
()
Ответ на: комментарий от Dudraug

А можно на шаблонах такой быдлокод нагенерить, что вообще треш!

Кресты позволяют значительно вольней быдлокодить и больше себе в ногу пуль загнать, чем сишечка!

anonymous
()
Ответ на: комментарий от Dudraug

Увы, рынку нужны быдлокодеры. Чтобы на каком-нибудь пхытоне наковыряли за тарелку риса дерьма, которое со скрипом поработает пару недель... А там нового быдлокодера найдут.

anonymous
()
Ответ на: комментарий от eao197

в разных книгах Б.Страуструпа

а ещё были at&t-шные мануалы. даже в этом вашем фидо.

вряд ли вы Turbo C++ 1.0 видели

почему бы и нет? третий-то на дискету не влезал...

anonymous
()
Ответ на: комментарий от Iron_Bug

только вот процессоры сейчас упёрлись в потолок .

Ну это далеко от правды, куда расти еще есть. Да и потенциал приличный, просто подходы к разработки процов для пробивания «потолка» немного(сильно) отличаются от тех к которым все привыкли за последние лет 20-30.

и почему-то все побежали искать тех, кто умеет писать качественный код.

Не все, а некоторые. Это во-первых. А во-вторых никтому им этого не запрещает, никто не говорит, что топ-инженеры не нужны, никто даже не мешает писать на си++ качественный код, и что вообще главное(разрыв мозга прямо!) никто не запрещает НЕ использовать новомодные фичи с++. Только это никак не влияет на то, что фичи нужны рынку, как и средненькие специалисты.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

насчёт прорыва в технологиях процов в ближайшие N лет - маловероятно. скорее, будет топтание на месте и размножение ядер.

что никто не запрещает не юзать что-то ненужное - с этим соглашусь. с этим никогда проблем не было. просто вопрос был в целом о курсе комитета. а так, если не нужны все навороты - сишечка всегда есть под рукой.

Iron_Bug ★★★★★
()
Ответ на: комментарий от eao197

Тем более, что за такие вещи, как variadic templates, move semantic, constexpr, noexcept, enum class, static if и еще кучу всякого разного им только спасибо сказать остается.

+!

А ещё за variant, optional, thread, атомики<>, мемори ордер и всё прочее.

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

А ещё за variant, optional, thread, атомики<>, мемори ордер и всё прочее.

Да все уже и вспомнить сразу сложно. Вот, скажем, уже по ходу «разговора» с Iron_Bug вспомнилось: вывод типа функции. Тривиальный пример для C++14:

template<typename T, typename U> auto sum(T a, U b) { return (a+b); }
Бесполезно даже просить Iron_Bug изобразить это на C++98.

eao197 ★★★★★
()
Ответ на: комментарий от Iron_Bug

остальное же в большинстве своём - «защита от дурака». и она не нужна.

например? почти и не припомню какие там защиты от дурака появились в новых стандартах, настолько несущественны эти изменения на общем фоне

next_time ★★★★★
()
Ответ на: комментарий от Iron_Bug

а в си можно просто разнести платформо- или архитектурно-зависимый код в разные файлы

нельзя. можно средствами cmake + C и от первого элемента данной связки тянет блевать

next_time ★★★★★
()
Ответ на: комментарий от eao197

тешьте себя дальше. но в 98-м (и до него) и не такое писали. но я больше в этом сраче участвовать не буду. борьба с детсадовцами не доставляет. у меня есть свои дела. а такие задачки можете порешать в качестве домашней работы. подсказка: везде можно избавиться от auto, он никогда не был нужен. это как раз костыль для неосиляторов номер один.

Iron_Bug ★★★★★
()
Ответ на: комментарий от next_time

почти и не припомню какие там защиты от дурака появились в новых стандартах

Как минимум:

range for. Мало того, что кода позволяет писать меньше, так еще и безопаснее получается.

override. Защищает от ошибок, например, когда формат виртуального метода в базовом классе меняется, а в производном — нет.

enum class. Особенно когда компилятор вменяемый и проверяет полноту switch-ей. Но не только.

Ну и move semantic + =delete позволяют явным образом описывать moveable классы. Например, обертки вокруг каких-то ресурсов.

eao197 ★★★★★
()
Ответ на: комментарий от Iron_Bug

я-то его как раз видела. с самого его начала и во всей истории его развития.

Не могу не напомнить в связи с этим:

Модули в C (комментарий)

Iron_Bug> детка, перегрузка функций в С была и в 80-е. мамой клянусь.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

одсказка: везде можно избавиться от auto, он никогда не был нужен.

Ахринеть. Вы даже не поняли сути приведенного примера.

Зато 20+ опыта, отличное владение C++, бла-бла-бла. Ыксперд, однако.

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Iron_Bug> детка, перегрузка функций в С была и в 80-е. мамой клянусь.

Шедеврально!

Она же реально какая-то поехавшая, причем совсем.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Сейчас средствами gcc можно легко в С делать перегрузку, но раньше - да, ее не было.

В любом случае, перегрузка функций не нужна. И она только усложняет чтение кода.

anonymous
()
Ответ на: комментарий от anonymous

Сейчас средствами gcc можно легко в С делать перегрузку

Имеются в виду какие-то расширения GCC или стандартный _Generic? Если второе - нифига не легко.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да, тот самый _Generic. Делается элементарно:

#include <stdio.h>
#include <stdint.h>

#define FUNC(arg) _Generic(arg, uint16_t: funcu, int32_t: funci)(arg)

void funcu(uint16_t arg){
    printf("uint16_t: %u\n", arg);
}

void funci(int32_t arg){
    printf("int32_t: %d\n", arg);
}

int main(){
    uint16_t u = 32;
    int32_t i = -50333;
    FUNC(u);
    FUNC(i);
    return 0;
}
В итоге разворачивается в то же самое говно, как и перегрузка функций в крестах (но, возможно, чуть поменьше итоговый бинарь будет и чуть поменьше будет тупить).

И так везде: все дерьмо из С++ по-человечески делается на сях ручками. Итоговый бинарник будет меньше по размеру, меньше будет жрать памяти и шустрей работать. Да, писать надо будет не неделю, а месяц. Но кого это волнует? Лично мне это только в плюс!

anonymous
()
Ответ на: комментарий от anonymous

Да, тот самый _Generic. Делается элементарно:

Элементарно делаются элементарные вещи. А функция от нескольких аргументов - уже не так элементарно. Не говоря уже о том, что для добавления новой функции мало добавить саму функцию - надо еще поправить _Generic.

И так везде: все дерьмо из С++ по-человечески делается на сях ручками.

Ты эти сказки рассказывай тем, кто на Си не программировал.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Да я ж тебе говорю: никому в здравом уме перегружать функции не понадобится!

anonymous
()
Ответ на: комментарий от Dudraug

для _гарантий_ того, что некое выражение будет подсчитано на этапе компиляции и не будет жрать такты процессора в рантайме

Кстати, такой _гарантии_ нет(я, по крайней мере, не нашёл)

Deleted
()
Ответ на: комментарий от Dudraug

Мимокрокодил, читаю вашу сантабарбару, скажу про:

кучу говнокода из ифдефов

В ифдефы пишем только инклюды, в файлах, которые инклюдятся, еще раз ифдефаемся и в теле ифдефа пишем одинаковый интерфейс с разной реализацией. При компиляции, собираться будут все, но те, которые не попали в ифдеф условия будут пустышками и не займут места в бинаре.

deep-purple ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.