Здравствуйте, Kluev, Вы писали:
K>За этим "логичным" решением стоит целый лес граблей, ладно когда его не видит обычный разработчик, но когда "близорукость" у создателей стандарт пиши пропало.
За любым решением стоит целый лес граблей. Разница между нами в том, что вы безоговорочно считаете свою точку зрения единственно правильной, тогда как я считаю, что оба подхода имеют право на существование и у каждого есть плюсы и минусы. В C++ исторически сложилось так. И многие действующие разработчики до сих пор не видят в этом проблемы.
В Java сложилось по другому. Так изначально беззнаковых чисел вообще не было (а может и сейчас нет). Посему сделать беззнаковые индексы там нельзя было в принципе. Так же Java никогда не ориентировалась, например, на 16-битовые платформы. Тогда как C++ вполне себе существовал и работал на таких.
Здравствуйте, AlexRK, Вы писали:
ARK>И дизреспект so5team за тупые наезды, хамство и переходы на личности.
Простите мне мой французский, но когда человек безапеляционно заявляет что:
* пространства имен не решают ни одной проблемы, а взамен можно использовать префиксы;
* iostreams были сделаны "на спор";
* STL попал в стандарт минуя продакшен;
* что размеры и индексы могут быть представлены только знаковыми целыми и никак иначе;
* не может привести ни одного внятного примера в обоснование своего же тезиса,
то разговор можно вести только о том, почему на высказывания этого свято уверенного в непогрешимости собственного мнения персонажа вообще стоить обращать внимание.
Технический спор -- это обмен аргументами. Когда же вместо аргументов используется "Конечно, считаю правильным и единственно верным." и "Да и сама проблема не сложнее выеденного яйца." + "Нет никаких проблем чтобы сделать опережающее описание следующим образом:" (при том, что здесь уже была цитата от человека, который описывал, как комитет обсуждал этот вопрос и почему решил ничего не менять, т.к. все далеко не так просто, как кажется Kluev-у), то остается только указать человеку на его поведение. Т.е. перейти на личности.
Ну и если кого-то в Интернете обижает, что его мнение не ценят и с ним не желают расшаркиваться в ненужных любезностях, то это странно. По меньшей мере.
Здравствуйте, so5team, Вы писали:
S>Любопытно. В сообщении, на которое вы ответили, был вопрос о том, где можно прочитать про признание ошибки. Так же, без упреков в чью-то сторону, было сказано, что есть люди, который находят смысл в беззнаковых индексах и размерах.
S>Ничего конструктивного и полезного вы не сказали, но зачем-то завели речь про "жрать говно".
Я не буду доказывать, что якобы мой комментарий про говно корректен, очевидно, что это не так.
Тут где-то в соседней теме уже изрядно пофлеймили на тему беззнаковых индексов, которые даже обрытный цикл заставляют писать через какие-то странные идиомы, а я устал.
Здравствуйте, T4r4sB, Вы писали:
TB>Тут где-то в соседней теме уже изрядно пофлеймили на тему беззнаковых индексов, которые даже обрытный цикл заставляют писать через какие-то странные идиомы, а я устал.
TB>http://rsdn.org/forum/flame.comp/7728838.flat.1
Во-первых, сам по себе спор на RSDN ничего не доказывает. У одних свое мнение, у других другое. Точно так же можно бесконечно спорить про big endian vs little endian. С таким же примерно итогом.
Во-вторых, безотносительно того, какого мнения придерживаетесь лично вы, мне интересно узнать про подтверждение вот этих ваших слов:
Здравствуйте, so5team, Вы писали:
S>Во-вторых, безотносительно того, какого мнения придерживаетесь лично вы, мне интересно узнать про подтверждение вот этих ваших слов:
S>
Вообще-то они уже признали, что это была ошибка.
Там в той теме я где-то выкладывал видос с мёртвым страусом, который про это упоминал.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>За этим "логичным" решением стоит целый лес граблей, ладно когда его не видит обычный разработчик, но когда "близорукость" у создателей стандарт пиши пропало.
S>За любым решением стоит целый лес граблей. Разница между нами в том, что вы безоговорочно считаете свою точку зрения единственно правильной, тогда как я считаю, что оба подхода имеют право на существование и у каждого есть плюсы и минусы. В C++ исторически сложилось так. И многие действующие разработчики до сих пор не видят в этом проблемы.
Это не значит, что все решения одинаково плохие. Минусов у беззнаковых индексов больше. Знаковые можно упрекнуть лишь в том, что они адресуют в два раза меньше.
S>В Java сложилось по другому. Так изначально беззнаковых чисел вообще не было (а может и сейчас нет). Посему сделать беззнаковые индексы там нельзя было в принципе. Так же Java никогда не ориентировалась, например, на 16-битовые платформы. Тогда как C++ вполне себе существовал и работал на таких.
На 16-ти битах в условиях нехватки оперативной памяти stl последнее, что понадобится программисту. Поэтому говорить, что беззнаковый индекс был сделан с оглядкой на 16-битные архитектуры. Мне кажется, что это просто смешно.
Здравствуйте, Kluev, Вы писали:
K>Это не значит, что все решения одинаково плохие. Минусов у беззнаковых индексов больше. Знаковые можно упрекнуть лишь в том, что они адресуют в два раза меньше.
Повторю еще раз что это значит: это значит, что вы считаете свое мнение единственно верным.
Причем, складывается ощущение, что во многом потому, что вы недостаточно широко смотрите по сторонам.
Здравствуйте, so5team, Вы писали:
TB>>Там в той теме я где-то выкладывал видос с мёртвым страусом, который про это упоминал.
S>Есть какая-то особая доблесть в том, чтобы за глаза обзывать так немолодого человека, который вообще ни сном ни духом про RSDN-овские разборки?
Да ладно, это уже давно прилипшее погоняло, ничего обидного тут нет, как и желания обидеть страуса
K>На 16-ти битах в условиях нехватки оперативной памяти stl последнее, что понадобится программисту. Поэтому говорить, что беззнаковый индекс был сделан с оглядкой на 16-битные архитектуры. Мне кажется, что это просто смешно.
Ну, STMка хоть и 32ух битная, но памяти там бывает весьма мало. На младших чуть ли не 4 кб оперативы (ну, как минимум, 32 кб точно есть камешки). И ничего, вполне STL используется. Был бы C++ для C51, тоже за милую душу использовал бы stl.
А уж во времена становления C++ 16битные платформы вполне себе мейн стрим были. Так что твой аргумент точно фтопку
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>И дизреспект so5team за тупые наезды, хамство и переходы на личности.
S>Простите мне мой французский, но когда человек безапеляционно заявляет что:
S>* пространства имен не решают ни одной проблемы, а взамен можно использовать префиксы;
Именно так господа. В с++ пространства имен не более чем синтаксический сахар без которого прекрасно можно жить и многие так и делают.
Языку больше нужна полноценная поддержка библиотек которая сейчас полностью отсутствует. Нет ни стандартного формата проектов, ни механизмов поддержки библиотек таких как: интерфейсы, общий базовый класс для полиморфных объектов, отказ от препроцессора и т.д и т.п. В результате многие библиотеки для С++ делают header only, что является форменным извращением. А полноценные невозможно установить и использовать без танцев с бубном.
В одной из книг страуструп посетовал, что они ждали появления тысяч библиотек классов для С++, а этого не произошло. А что он собственно сделал для того чтобы это произошло? Наводнил язык бесполезными и недоделанными фичами. И неймспейсы одна из них.
S>* iostreams были сделаны "на спор";
Именно так. Какая разница, что страуструп спорил не с человеком а с книгой? Это уже называется не разработка, а шоу нарциссо. Удивительно что находятся программисты которые пытаются получившийся продукт на хлеб мазать.
S>* STL попал в стандарт минуя продакшен;
Тот продакшон может уже давным давно разорился и даже эха не осталось. А в уважающих себя продакшонах к stl относились весьма настороженно
The Unreal Engine's avoidance of the C++ standard library's containers is primarily historical. C++ was standardized in 1998, the same year we shipped the first Unreal Engine game.
Back then, the standard libraries were controversial, poorly-implemented, and very inconsistent between platforms. They made very aggressive use of new C++ features that **hadn't yet been production-proven**, and had some significant problems interoperating with C libraries. For example, std::vector wasn't guaranteed to be contiguous, so passing an array to a C library like DirectX could potentially involve creating a temporary copy of it.
S>* что размеры и индексы могут быть представлены только знаковыми целыми и никак иначе;
Именно так! Потенциальные грабли нужно устранять, даже ценой двухкратного сокращения диапазона индексов. С++ же спроектирован в погоне за ветряными мельницами, чтобы каждая написанная строка кода давалась программисту кровью и потом. Чтобы вместо того чтобы просто писать работающий код, программист обдумывал бы каждый оператор, не будет ли там смешанной арифметики, переполнения и т.д и т.п.
Человек который имеет другую точку зрения, конечно имеет на нее полное право, но по сути является садомазохистом и не подходит для принятия общественно значимых решений по моральным качествам.
S>* не может привести ни одного внятного примера в обоснование своего же тезиса,
Тезисы я приводил и не один раз. может просто шоры нужно снять с глаз?
S>Технический спор -- это обмен аргументами. Когда же вместо аргументов используется "Конечно, считаю правильным и единственно верным." и "Да и сама проблема не сложнее выеденного яйца." + "Нет никаких проблем чтобы сделать опережающее описание следующим образом:" (при том, что здесь уже была цитата от человека, который описывал, как комитет обсуждал этот вопрос и почему решил ничего не менять, т.к. все далеко не так просто, как кажется Kluev-у), то остается только указать человеку на его поведение. Т.е. перейти на личности.
Комитет вообще-то решил прорабатывать дальше. Как обычно двинули проблему в долгий ящик.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Kluev, Вы писали:
K>>На 16-ти битах в условиях нехватки оперативной памяти stl последнее, что понадобится программисту. Поэтому говорить, что беззнаковый индекс был сделан с оглядкой на 16-битные архитектуры. Мне кажется, что это просто смешно.
M>Ну, STMка хоть и 32ух битная, но памяти там бывает весьма мало. На младших чуть ли не 4 кб оперативы (ну, как минимум, 32 кб точно есть камешки). И ничего, вполне STL используется. Был бы C++ для C51, тоже за милую душу использовал бы stl.
M>А уж во времена становления C++ 16битные платформы вполне себе мейн стрим были. Так что твой аргумент точно фтопку
К тому времени как представили stl 32бита уже 8 лет были мейнстримом.
Здравствуйте, Kluev, Вы писали:
S>>* пространства имен не решают ни одной проблемы, а взамен можно использовать префиксы;
K>Именно так господа. В с++ пространства имен не более чем синтаксический сахар без которого прекрасно можно жить и многие так и делают.
Здравствуйте, Kluev, Вы писали:
K>Неверно. Пространство имен класса очевидно присутствует в опережающем описании. Вот оно:
K>
K>classstorage;
K>
K>Поэтому нет никаких проблем с объявлением вложенного класса.
В общем, я просмотрел инфу по поводу forward nested class declaration и беру свои слова обратно. Я согласен с Kluev — все проблемы, которые якобы возникают от такого нововведения смехотворны. Возникающие ошибки (типа защищённого или приватного последующего определения вложенного класса или отсутствия одного из определений в доступных для компиляции единицах трансляции) описываются стандартными сообщениями компилятора/линкера. Вот здесь вердикт Trip Report: C++ Standards Meeting in Jacksonville, February 2016
Proposals for which further work is encouraged:
...
Forward declarations of nested classes. This would allow things like X::A* to appear in a header without requiring a definition for X to also appear in the header (forward-declarations of X and X::A will be sufficient). EWG found the use case compelling, because currently a lot of class definitions to appear in headers only because interfaces defined in the header use pointers or references to nested classes of the type. Several details still need to be worked out. (For example, what happens if a definition of X does not appear in any other translation unit (TU)? What happens if a definition of X appears in another TU, but does not define a nested class A? What happens if it does define a nested class A, but it’s private? The answer to some or all of these may have to be “ill-formed, no diagnostic required”, because diagnosing errors of this sort would require significant linker support.)
Но никто этим предложением не занимался, видимо все обходятся friend class'ами и данное предложение не толкают активно.
И добавлю относительно комитета, это ИМХО и оно никак не связано с вышеупомянутыми вложенными классами. Ниже по ветке я постил "другое" мнение о пути развития C++. Добавлю лишь, что у сегодняшнего комитета полностью отсутствует стратегическое целепологание, а точнее "недемократическая" компетентная группа способная принимать окончательные волевые стратегические решения о пути развития языка. Отсюда принятие фич ради фич и фич, которые интенсивнее педалируют без оглядки на развитие самого языка, на изменение подходов к программированию на этом языке, на современные требования к интеграции языка в инфраструктуру разработки.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, YuriV
S>Может тогда вы приведете пример ситуации, где невозможность сделать forward declaration для вложенного типа является реальной проблемой?
S>У Kluev-а пока не получилось.
А она и не является таковой. Здесь вопрос чисто академический — почему не дать такую возможность, если она выглядит логично и не несёт серьёзных трудностей в реализации? Я никогда не сталкивался с нуждой так ревностно контролировать включение хидеров и так упорото прятать реализацию. Тем более, лично мне, непонятно зачем использовать классы если данные из них будут обрабатываться отдельными функциями, не методами, которым нужно обеспечить доступ к этим данным. Если внутри вызываются методы класса, то я вижу один вариант — это предоставление кода без детализации внутренней структуры (даже интерфейсов классов), все потроха, в т.ч. декларации и определения классов находятся внутри библиотеки, наружу торчит только набор сигнатур функций. Это и сейчас делается спокойно, только с фиксацией интерфейсов классов. Лично мне это не нужно, поэтому с такой проблемой я никогда не сталкивался. Если эту возможность ввести, то 99.9(9)% процентов программеров её не заметят. Короче с точки зрения чистоты языка такая возможность нужна, с точки зрения прагматики — мне безразлично.
Здравствуйте, YuriV, Вы писали:
YV>Если эту возможность ввести, то 99.9(9)% процентов программеров её не заметят.
В том-то и дело, что на практике проблемы-то и нет. И даже в тех редких случаях, когда что-то подобное требуется, то есть способы это обойти.
YV>Короче с точки зрения чистоты языка такая возможность нужна, с точки зрения прагматики — мне безразлично.
С другой стороны, C++ и так сборная солянка всякого разного и разнообразного. Добавлять что-то новое опасно, если это реально не нужно.
Яркий пример: uniform intialization syntax. Вроде бы хорошую штуку сделали. Но хотели как лучше, а получилось как всегда.
S>С другой стороны, C++ и так сборная солянка всякого разного и разнообразного. Добавлять что-то новое опасно, если это реально не нужно.
Не добавлять новое, а исправлять баги. Не хотят исправлять, пусть честно объявляют вложенные классы deprecated, чтобы программисты не попадались на грабли.
TB>Там в той теме я где-то выкладывал видос с мёртвым страусом, который про это упоминал.
Страуструп, конечно, голова, но все-таки не великодушный пожизненный диктатор. И его мнение в очередной войне тупо- и остроконечников не решающее. Я недавно читал где-то дискуссию про одно из его предложений в стандарт, которая свелась к тому, что авторитет не должен превалировать над техническими аргументами.
Я думаю, компромисс с введением `std::ssize()` не принесет удовлетворения тем кто привык использовать int для индексов — Они сделали дерьмо опять
Здравствуйте, YuriV, Вы писали:
YV>В общем, я просмотрел инфу по поводу forward nested class declaration и беру свои слова обратно. Я согласен с Kluev — все проблемы, которые якобы возникают от такого нововведения смехотворны. Возникающие ошибки (типа защищённого или приватного последующего определения вложенного класса или отсутствия одного из определений в доступных для компиляции единицах трансляции) описываются стандартными сообщениями компилятора/линкера. Вот здесь вердикт Trip Report: C++ Standards Meeting in Jacksonville, February 2016
.. YV>Но никто этим предложением не занимался, видимо все обходятся friend class'ами и данное предложение не толкают активно.
Так в чем загвоздка, подберите упавшее знамя, и вперёд, в комитет, дорабатывать эту важную вещь! Может быть даже РГ21 вам поможет в проталкивании...
YV>И добавлю относительно комитета, это ИМХО и оно никак не связано с вышеупомянутыми вложенными классами. Ниже по ветке я постил "другое" мнение о пути развития C++. Добавлю лишь, что у сегодняшнего комитета полностью отсутствует стратегическое целепологание, а точнее "недемократическая" компетентная группа способная принимать окончательные волевые стратегические решения о пути развития языка. Отсюда принятие фич ради фич и фич, которые интенсивнее педалируют без оглядки на развитие самого языка, на изменение подходов к программированию на этом языке, на современные требования к интеграции языка в инфраструктуру разработки.
А у вас есть такой стратегический план? Было бы любопытно ознакомиться с этим документом.
