[C++] Перегрузка [][]
таких операторов в с++ нет 
А можно ли их каким-либо образом объявить, ввести?
Хм. Можно, наверное, передавать оператору [] структуру из двух элементов. Надо попробовать
ну можно, почему бы нет... на первую скобку оператором выдаётся другой класс, у которого скобка уже по-другому перегружена, ну и так далее...
Можно ли перегрузить операторыВ языке C вообще нельзя перегрузить операторы
Исправился
Можно ли перегрузить операторы [][], [][][] и т.д.?
А можно ли их каким-либо образом объявить, ввести?в C++ никакие другие операторы, кроме уже имеющихся ввести нельзя
обеспечить функциональность таких многоиндексных "операторов" довольно легко - созданием вспомогательных классов и перегрузкой operator[](index_type) для них, сам подумай как.
действительно проще сделать один индекс и перегрузить operator[](index_type а еще проще и пожалуй лучше перегрузить operatorindex1_type,index2_type,...) - можно передавать много индексов.
Точно 
А лучше почитать Thinking in Java и понять, что перегрузка операторов - это зло.
если не знать, что такое профайлер - то да
А лучше почитать Thinking in Java и понять, что перегрузка операторов - это зло.Лучше сразу по визуалбейсику для профессионалов тогда советуй...
не волнуйся, через пару лет они добавят туда и перегрузку операторов в особо извращённой форме, и перепишут TiJ
Java - зло. Я понял это в полной мере, когда увидел, что JDownloader занимает аж 55 (!) метров. И еще тормозит.
Да, зато тебе удобно было его разрабатывать.
Да, зато тебе удобно было его разрабатывать.
Я уверен, что JDownloader занимает на порядки меньше места.
вместе со своей прогой в инсталлятор включил и виртуальную машину Java, чтобы тебе не приходилось возиться и устанавливать ее вручную из инета или из сетки.
Тормозит не JDownloader, а сетка и винда. Можешь попробовать качать три-четыре фильма одновременно стандартными средствами - будет еще хуже, поверь (но и без возможности докачки и использования зеркал).
Зря ты так, короче...
вместе со своей прогой в инсталлятор включил и виртуальную машину Java, чтобы тебе не приходилось возиться и устанавливать ее вручную из инета или из сетки.
Тормозит не JDownloader, а сетка и винда. Можешь попробовать качать три-четыре фильма одновременно стандартными средствами - будет еще хуже, поверь (но и без возможности докачки и использования зеркал).
Зря ты так, короче...
Вот так:А лучше почитать Thinking in Java и понять, что перегрузка операторов - это зло.если не знать, что такое профайлер - то да
Если я знаю, что такое профайлер, то я тут же должен понять, что перегрузка операторов - это хорошо, видимо, потому что метод, определенный как оператор, должен работать быстрее.
Или так:
Перегрузка операторов это хорошо, потому что этого нет в Java. А все, чего нет в Java - хорошо, потому что она (java) тормозная.
Вообще я здесь не хотел сказать, что Java круче всех. Я сам так не считаю. Но то, что переусердствовать (а это многие любят) с перегрузкой операторов не следует - это точно.
не туда.
основные возвражения против операторов в TIJ - это то, что когда программист использует перегруженный оператор, то он при этом может легко не заметить, на сколько тяжелый код при этом вызывается.
но для того, чтобы реально видеть, какие места работают медленно/тяжело, как раз профайлер и существует.
соответственно, если программист умеет использовать и активно использует профайлер, то основная проблема перегруженных операторов исчезает.
основные возвражения против операторов в TIJ - это то, что когда программист использует перегруженный оператор, то он при этом может легко не заметить, на сколько тяжелый код при этом вызывается.
но для того, чтобы реально видеть, какие места работают медленно/тяжело, как раз профайлер и существует.
соответственно, если программист умеет использовать и активно использует профайлер, то основная проблема перегруженных операторов исчезает.
Да, перегруженные операторы - это очень хитроумная попытка программиста-писателя(ПП) обмануть программиста-читателя(ПЧ). Под видом безобидной квадратной скобочки может скрываться всё, что угодно - от решения задачи о собственных числах линейного оператора до получения содержимого веб-страницы из интернета.
- Одну проблему уже указал: от ПЧ тщательно скрывается истинное время работы оператора.
- Вторая проблема в том, что ПЧ поймет семантику работы оператора в силу своих умственных способностей. И практика показывает, что ПП и ПЧ часто думают по-разному, что приводит к ошибкам, многократному перечитыванию лишнего кода и т. д.
- Одну проблему уже указал: от ПЧ тщательно скрывается истинное время работы оператора.
- Вторая проблема в том, что ПЧ поймет семантику работы оператора в силу своих умственных способностей. И практика показывает, что ПП и ПЧ часто думают по-разному, что приводит к ошибкам, многократному перечитыванию лишнего кода и т. д.
Ладно, был не прав. Не знал.
А разве нельзя было сделать, чтобы инсталлятор определял наличие ВМ и не инсталлил ее, если она уже есть?
А разве нельзя было сделать, чтобы инсталлятор определял наличие ВМ и не инсталлил ее, если она уже есть?
те же виртуальные вызовы - намного сильнее запутывают чтение программы,
но это не повод говорить, что надо на уровне языка - запретить виртуальные вызовы
ps
вообще - перегруженные операторы - это инструмент, и им надо просто правильно пользоваться.
но это не повод говорить, что надо на уровне языка - запретить виртуальные вызовы
ps
вообще - перегруженные операторы - это инструмент, и им надо просто правильно пользоваться.
Под видом безобидной квадратной скобочки может скрываться всё, что угодноНе аргумент. Под функций "sin" тоже может скрываться "format c:" ну и что с того? Обычно не скрывается...
Кстати, а такой ещё вопрос:
Какие-нить среды разработки для С++ позволяют, щёлкнув по оператору, посмотреть как и где он перегружен?
Просто увидев в коде вызов sin в IDEA, я могу:
1. нажать ctrl+Q и посмотреть явадоки по нему (или же даже внешнюю документацию)
2. нажить ctrl+shift+i и пропосмотреть в появившемся окошке тело функции
3. нажать ctrl+b и перейти к описанию функции
4. на крайняк, даже могу посмотреть граф вызовов, порождённый обращением к этой функции
Так что возможность недопонимания сути работы функции сводится, практически, к нулю.
Можно ли тоже самое сказать о перегрузке оператора?
З.Ы.:
на С++ давно не прогал, так что просто не знаю, до чего дошли IDE;)
Какие-нить среды разработки для С++ позволяют, щёлкнув по оператору, посмотреть как и где он перегружен?
Просто увидев в коде вызов sin в IDEA, я могу:
1. нажать ctrl+Q и посмотреть явадоки по нему (или же даже внешнюю документацию)
2. нажить ctrl+shift+i и пропосмотреть в появившемся окошке тело функции
3. нажать ctrl+b и перейти к описанию функции
4. на крайняк, даже могу посмотреть граф вызовов, порождённый обращением к этой функции
Так что возможность недопонимания сути работы функции сводится, практически, к нулю.
Можно ли тоже самое сказать о перегрузке оператора?
З.Ы.:
на С++ давно не прогал, так что просто не знаю, до чего дошли IDE;)
Но то, что переусердствовать (а это многие любят) с перегрузкой операторов не следует - это точно.согласен на все 100
перегрузка операторов предназначена прежде всего для краткости и интуитивной понятности записи вызова функции.
А когда лепят их везде пока операторы не кончатся - это уже маразм.
Да, перегруженные операторы - это очень хитроумная попытка программиста-писателя(ПП) обмануть программиста-читателя(ПЧ). Под видом безобидной квадратной скобочки может скрываться всё, что угодно - от решения задачи о собственных числах линейного оператора до получения содержимого веб-страницы из интернета.Если ПП вместо написания интуитивно понятной и легко читаемой программы пытается обмануть ПЧ, он - идиот или вредитель.
- Одну проблему уже указал: от ПЧ тщательно скрывается истинное время работы оператора.
- Вторая проблема в том, что ПЧ поймет семантику работы оператора в силу своих умственных способностей. И практика показывает, что ПП и ПЧ часто думают по-разному, что приводит к ошибкам, многократному перечитыванию лишнего кода и т. д.
Обе проблемы - не проблемы вообще, это просто дополнительная ответственность, возлагаемая на ПП, использующего перегруженные операторы (а в C и C++ на программистов очень часто возлагается гораздо бОльшая ответственность: мусор не собирается чтение/запись за границы массива не отслеживается - и все это правильно, придумывание подходящих имен для интерфейсных и внешних идентификаторов - тоже целиком забота программиста и в точности такая же ответственность как уместная перегрузка операторов, потому что перегрузка оператора - это разновидность выбора имени функции).
По поводу первого пункта пример из стандарта: почему-то operator[](index_type) перегружен для контейнеров std::vector<>,std::map<>, но не перегружен для std::list<>. Угадайте почему?
По поводу второй проблемы: если ПП перегрузил оператор так, что его вызов читается неоднозначно, то есть тупой ПЧ может понять его неправильно (не путать с вообще не понять то это ошибка ПП.
Используя почти любую фичу произвольного языка программирования, можно все написать через задницу.
Если некоторые программисты идиоты, это не значит, что нужно лишать язык программирования функциональности, которая может быть полезна в руках компетентных программистов.
А эти два вышенаписанных аргумента касаются например обычного наследования классов (первый аргумент как в плане ожидаемого размера объекта, так и в плане времени работы конструктора/деструктора, например) в той же степени как и перегрузки операторов. То же самое: при правильном использовании - никаких проблем, а при идиотском использовании - те же самые проблемы. И никакой принципиально новой функциональности наследование тоже не добавляет как и перегрузка операторов и функций.
Насчёт п.4 не знаю, но 1.-3. есть в MSVS + VAssistX
Да, перегруженные операторы - это очень хитроумная попытка программиста-писателя(ПП) обмануть программиста-читателя(ПЧ). Под видом безобидной квадратной скобочки может скрываться всё, что угодно - от решения задачи о собственных числах линейного оператора до получения содержимого веб-страницы из интернета.Аналогично - с пропертями. Проперти надо запретить! И get_Zzz/set_Zzz - тоже, потому что это устойчивая конструкция, имеющая семантику пропертей! Гы гы гы.
- Одну проблему уже указал: от ПЧ тщательно скрывается истинное время работы оператора.
Так вот, если Программист-Писатель - мудак, то исправить это досадное свойство ограничивая возможности языка всё равно не удастся. А нормальные программисты не пишут тяжеловесных пропертей и операторов. Равно как и не пишут операторов с неочевидной семантикой, как, впрочем, и проперти с сайд-эффектами. А если и пишут что-то не вполне очевидное, то только когда действительно необходимо и тщательно документируют везде, где только можно ("включают в контракт", как было написано в какой-то книжке по жаве, кстати) - например, как в случае Control.get_Handle, который создаёт хэндл если тот ещё не создан.
(гг, руел почти то же самое сказал)
Согласен с тобой - проперти тоже нужно запретить как неявные конструкции
То есть ты полагаешь, что с развитием ЯП развиваются и ПП ?
Как раз наоборот. Средний уровень программистов падает с каждым годом, так как их (программистов) стоновится как собак нерезаных. Соответственно, ЯП, претендующий на то, чтобы быть популярным, должен обезопасить творение ПП от самого ПП.
Как раз наоборот. Средний уровень программистов падает с каждым годом, так как их (программистов) стоновится как собак нерезаных. Соответственно, ЯП, претендующий на то, чтобы быть популярным, должен обезопасить творение ПП от самого ПП
.Я уверен, что для большинства посетителей этого топика не составит проблем использвание неявных конструкций, и они будут использовать эти конструкции правильно. Но так нельзя сказать о многих других псведо и мета программистах (переквалифицировавшихся инженеров-сантехников 12 разряда, например). И этих середнячков большинство...
Ну и о чем это говорит. Просто сейчас лучше развиты технологии, используя которые пользу могут приносить и "слабые" программисты.
С другой стороны средний уровень повышается. Так как повышаются требование к функциональности софта и повышается его сложность. На qbasic сегодня особо не попишешь. Сегодня VB6 прграммисты ООП учат.
С другой стороны средний уровень повышается. Так как повышаются требование к функциональности софта и повышается его сложность. На qbasic сегодня особо не попишешь. Сегодня VB6 прграммисты ООП учат.
Но так нельзя сказать о многих других псведо и мета программистах (переквалифицировавшихся инженеров-сантехников 12 разряда, например). И этих середнячков большинство...Ошибка того, кто их заставил писать такой код. Такие программисты должны не писать классы со свойствами и т.д., а использовать эти классы, которые будут писать "нормальные" программисты. И использовать их проще, когда есть свойства и т.д.
Но эту ошибку исправить тяжело, а исправить ошибку незащищенного от дурака ЯП легко.
Предлагаю создать
С# professional edition
и
C# santehnik edition
Предлагаю создать
С# professional edition
и
C# santehnik edition
Но эту ошибку исправить тяжело, а исправить ошибку незащищенного от дурака ЯП легко.Почему тяжело. Есть два варианта:
1) Правильно распределять работу между программистами: одни формы ваяют, другие важные компоненты.
2) Настроить FxCop - аналог Code Inspection в IDEA (зачем кастрировать язык).
>> других псведо и мета программистах (переквалифицировавшихся инженеров-сантехников 12 разряда, например). И этих середнячков большинство...
Брателло, ты путаешь программиста и кодера. Большинство - кодеров. И если менеджер разрешил кодеру разработать интерфейс класса, а кодер написал хуйню - виноват менеджер.
Слуушай, чувак! А ведь ты в чём-то прав! Пожалуй, действительно можно сказать, что жава - это шарп для говнопрограммеров. Да. Точно.
Брателло, ты путаешь программиста и кодера. Большинство - кодеров. И если менеджер разрешил кодеру разработать интерфейс класса, а кодер написал хуйню - виноват менеджер.
Слуушай, чувак! А ведь ты в чём-то прав! Пожалуй, действительно можно сказать, что жава - это шарп для говнопрограммеров. Да. Точно.
C# santehnik edition == Java !
Всё, теперь я знаю, что такое жава
Не флуди! Голденай все правильно сказал.
Программисту-сантехнику нельзя давать в руки перегрузку операторов, проперти и другие потенциально опасные вещи. Так написано в книжке Thinking In Java (How To Be Successful Sun Technician, гыгы) - по словам Голденая, не моим. Поэтому в Правильной Жаве таких вещей и нет (говорят, сейчас разработчики жавы отклонились от генеральной линии).
Программисту-сантехнику нельзя давать в руки перегрузку операторов, проперти и другие потенциально опасные вещи. Так написано в книжке Thinking In Java (How To Be Successful Sun Technician, гыгы) - по словам Голденая, не моим. Поэтому в Правильной Жаве таких вещей и нет (говорят, сейчас разработчики жавы отклонились от генеральной линии).
То есть ты полагаешь, что с развитием ЯП развиваются и ПП ?нет, конечно
я не слепой
Соответственно, ЯП, претендующий на то, чтобы быть популярным, должен обезопасить творение ПП от самого ПП"Обезопасить насколько это целесообразно", я бы сказал.
Идеологически я частично согласен с этим утверждением, с оговорками: (1) недопустимо заведомо жертвовать скоростью работы конечного продукта (например "защита от дурака" на уровне спецификации ЯП типа проверки границ массива (2) недопустимо ограничение возможности применения ЯП, (3) недопустимо жертвовать продуктивностью ПП (разного уровня компетентности (4) недопустимо жертвовать читабельностью кода, (5) недопустимо сильно усложнять работу авторов компиляторов, (6) недопустимо жертвовать простотой изучения ЯП.
Короче я убежденный сторонник всеобъемлющей логичности, краткости и простоты ЯП (для разработчиков компиляторов, обучающихся, ПП и ПЧ) в совокупности с универсальной мощью и безопасностью в использовании (в том числе сантехниками) - все условия выполнимы на достаточном уровне одновременно.
Но в действительности популярные ЯП имеют свою историю развития, которая ложится тяжким грузом как на функциональность данного ЯП, так и на восприятие его программистами. Например функции ...printf/...scanf в языке C++ выглядят крайне нелепо, да и в C ИМХО вся библиотека ввода/вывода выглядит нелепо, в самих языках много крайне важной функциональности отсутствует (видимо ради чьего-то представления о портируемости) и т.п.
Но так нельзя сказать о многих других псведо и мета программистах (переквалифицировавшихся инженеров-сантехников 12 разряда, например). И этих середнячков большинство...Ошибка того, кто их заставил писать такой код. Такие программисты должны не писать классы со свойствами и т.д., а использовать эти классы, которые будут писать "нормальные" программисты. И использовать их проще, когда есть свойства и т.д.
Но эту ошибку исправить тяжело, а исправить ошибку незащищенного от дурака ЯП легко.неужели?
Что легко? Придумать свой "защищенный" ЯП, реализовать его, переучить в него всех сантехников и переписать всю нужную функциональность, которая уже написана на "незащищенных" ЯП? Да уж легче не куда - куда труднее нанять несколько квалифицированных прогеров, толпу "сантехников" и толково распределить между ними обязанности. Гыгы.
Вообще-то в принципе придумать хороший ЯП не проблема и даже написать компилятор для него не очень трудно. Но вот только одна беда: кому он нафиг нужен, т.е. кто на нем будет прогать кроме его автора?
Даже эта проблема в принципе решаема высококвалифицированными дальновидными программистами со стратегическим мышлением, представлением о грамотном маркетинге и огромным количеством финансовых и информационных ресурсов, которые идеалистически настроены и стремятся прежде всего обеспечивать прогресс, оптимизируя труд программистов во всем мире. Думаю уже проблема очевидна: те у кого есть финансовые ресурсы обычно настроены их сохранить и приумножить (потому они у них и есть т.е. далеко не идеалистически: оптимизировать работу своих программистов и минимизировать продуктивность конкурентов (включая потенциальных) либо обратить ее в свою пользу, а вот те, кто настроен идеалистически у того финансовых ресурсов обычно нет и даже если есть - их быстро не станет.
Я в основном говорю об универсальных ЯП, позиционируемых как универсальные, и C# и Java к ним не относятся.
Узкоспециализированные языки (или использующиеся как таковые) имеют весьма ограниченные перспективы ИМХО.
Ты просто привык, что если написано
то туда надо заглянуть, если лезут баги, потому что баги могут водиться в функции.
А вот в проперти и тем более в перегруженный оператор ты полезешь далеко не всегда, например, потому что ты можешь и не знать про перегрузку. Между тем, в функциях тоже могут быть неслабые side effects, которые ты сразу-то и не заметишь.
Проперти и перегрузка операторов повышает читабельность, таким образом ты можешь фтыкнуть и асилить бОльший объем действий исключительно за счет уменьшения количества видимого текста.
Если ПП захочет наебать ПЧ, он это сделает легко и без напряга (надо сказать, что он и себя тоже наебет, потому что забудет про свои собственные косяки к тому моменту, когда что-то понадобится исправить).
В общем, польза неявных конструкций в том, что пользователь (и часто это ты сам, через несколько дней) твоего класса может писать более выразительный код. Естественно, что это накладывает на тебя, как на автора, ответственность по написанию максимально прозрачного и надежного кода внутри реализации неявной конструкции.
Путем кастрации язык можно улучшить в плане надежности для небольших программ, но при этом в серьезных проектах его применять будет неудобно из-за большого количества кода.
Это как разговаривать буквами, а не словами. Маленькую порцию инфы передашь очень надежно (как менты номера автомобильные друг другу гооворят - Маша, Ефим 9 - 8 - 7, Клавдия а вот рассказывать что-нибудь длинное - ты заебешься языком работать, а слушающий потеряет суть в середине твоего повествования
объект.имяФункции
то туда надо заглянуть, если лезут баги, потому что баги могут водиться в функции.
А вот в проперти и тем более в перегруженный оператор ты полезешь далеко не всегда, например, потому что ты можешь и не знать про перегрузку. Между тем, в функциях тоже могут быть неслабые side effects, которые ты сразу-то и не заметишь.
Проперти и перегрузка операторов повышает читабельность, таким образом ты можешь фтыкнуть и асилить бОльший объем действий исключительно за счет уменьшения количества видимого текста.
Если ПП захочет наебать ПЧ, он это сделает легко и без напряга (надо сказать, что он и себя тоже наебет, потому что забудет про свои собственные косяки к тому моменту, когда что-то понадобится исправить).
В общем, польза неявных конструкций в том, что пользователь (и часто это ты сам, через несколько дней) твоего класса может писать более выразительный код. Естественно, что это накладывает на тебя, как на автора, ответственность по написанию максимально прозрачного и надежного кода внутри реализации неявной конструкции.
Путем кастрации язык можно улучшить в плане надежности для небольших программ, но при этом в серьезных проектах его применять будет неудобно из-за большого количества кода.
Это как разговаривать буквами, а не словами. Маленькую порцию инфы передашь очень надежно (как менты номера автомобильные друг другу гооворят - Маша, Ефим 9 - 8 - 7, Клавдия а вот рассказывать что-нибудь длинное - ты заебешься языком работать, а слушающий потеряет суть в середине твоего повествования
Путем кастрации язык можно улучшить в плане надежности для небольших программ, но при этом в серьезных проектах его применять будет неудобно из-за большого количества кода.На что уходит максимальное количество времени при разработе ПО? Время уходит на исправление ошибок. И чем больше проект, тем больше времени уходит на багфиксы (и время это растет нелинейно!)
Баги бывают простые и сложные. Сложные баги неявны.
И тут нам на помощь приходят неявные конструкции! Они героическими усилиями скрывают и без того спрятанные ошибки в коде!
Поэтому я бы сказал наоборот: "Путем кастрации язык можно улучшить в плане надежности для больших программ, а в небольших проектах его применять будет неудобно - ведь проще воспользоваться ультракомпактным прологом "
Знаешь, у меня, кажется, ни разу не было ошибок, связанных с неявной работой перегруженных операторов или пропертей. Вот что-то не припомню ни одного, честно.
Да, пару раз приходилось рефлектором лезть в мскорлиб, дабы осознать, каким образом следует что-нибудь использовать для оптимальной производительности.
Ещё DateTime, например, достаточно криво документирован - там на самом деле внутри один лонг со 100нс тиками, но снаружи это совершенно неочевидно, так что вот такой код
DateTime zzz = DateTime.Now;
DateTime tmp = zzz - new TimeSpan(zzz.Hours, zzz.Minutes, zzz.Seconds, zzz.Milliseconds);
if (zzz.Date == tmp) { ... }
выглядит вполне логично (поскольку прямого доступа к оставшейся части тиков там нет но срабатывает рандомным образом. Но это как бы не вполне относится к теме.
Так что, сдаётся мне, ты просто неумно теоретизируешь, совершенно в духе Отца Ублюдочных Языков Вирта.
Да, пару раз приходилось рефлектором лезть в мскорлиб, дабы осознать, каким образом следует что-нибудь использовать для оптимальной производительности.
Ещё DateTime, например, достаточно криво документирован - там на самом деле внутри один лонг со 100нс тиками, но снаружи это совершенно неочевидно, так что вот такой код
DateTime zzz = DateTime.Now;
DateTime tmp = zzz - new TimeSpan(zzz.Hours, zzz.Minutes, zzz.Seconds, zzz.Milliseconds);
if (zzz.Date == tmp) { ... }
выглядит вполне логично (поскольку прямого доступа к оставшейся части тиков там нет но срабатывает рандомным образом. Но это как бы не вполне относится к теме.
Так что, сдаётся мне, ты просто неумно теоретизируешь, совершенно в духе Отца Ублюдочных Языков Вирта.
Оставить комментарий
erotic
Можно ли перегрузить операторы [][], [][][] и т.д.?