Здравствуйте, Quintanar, Вы писали:
A>>А Си++ вообще довольно много свободы даёт и требует мозгов чтобы этой свободой надлежащим образом распорядится. Например та же адресная арифметика. Кому эта свобода бьёт в голову, те на Си++ не пишите. Кто же заставляет?
[...]
Q>Ну все, пошла обычная песня. Любители С++ уперлись в некую мнимую свободу С++ и в упор не видят, что есть и другие виды свободы. Например, свобода не думать об управлении памятью, свобода не думать, что означает данная закорючка в данном контексте, свобода не разбирать километровые объявления шаблонных типов и т.д.
Слушай, давай уж обобщим до одного: "свобода не думать". Ну дык этаких "свободных разумов" хватает и без того. Прям девать некуда.
Q>Полную свободу предоставляет, кстати, не С++, а С — на нем можно реализовать все, что угодно, без нелепых ограничений С++.
Не. Ассемблер — вот выбор по-настоящему свободных людей!
Q>Что вам приходит в голову, ведомо только вам одному. То, что вы считаете логичным и понятным, может оказаться совершенно нелогичным и непонятным для других.
В точку.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
Q>>Ну все, пошла обычная песня. Любители С++ уперлись в некую мнимую свободу С++ и в упор не видят, что есть и другие виды свободы. Например, свобода не думать об управлении памятью, свобода не думать, что означает данная закорючка в данном контексте, свобода не разбирать километровые объявления шаблонных типов и т.д.
ГВ>Слушай, давай уж обобщим до одного: "свобода не думать". Ну дык этаких "свободных разумов" хватает и без того. Прям девать некуда.
Это С++ так на вас влияет? Ведь ясно же, что имелась в виду свобода не думать о мелочах, а заняться более серьезными делами.
Q>>Полную свободу предоставляет, кстати, не С++, а С — на нем можно реализовать все, что угодно, без нелепых ограничений С++. ГВ>Не. Ассемблер — вот выбор по-настоящему свободных людей!
Здравствуйте, Quintanar, Вы писали:
Q>Бла-бла-бла. Один кофе только у любителей С++. Другие выбирают между разными языками и смотрят как реализованы идеи там.
Я активно пишу на Си++, C#, PHP и даже недавно на Паскале опять пришлось. Уж в чём в чём, а в том что я не знаю других языков обвинить меня точно нельзя. У Си++ есть недостатки, но перегрузка операторов не входит в их число.
A>>Нет. У меня есть образование. Например по формуле F = am я понимаю, что сила равная произведению ускорения на массу. Q>Да ну. Как раз наоборот, вы застряли на уровне ньютоновской механики
Я говорил о том, что F это обозначение силы, а m массы и для того чтобы читать чужие формулы не нужно осбо договариваться, нужно просто пользоваться общепринятыми обозначениями. Точно так же мне не придёт в голову для сложения двух чисел использовать %.
Q>Да не отстой, поскольку ее фактически нет и каждый вправе сделать свою.
А в праве не делать. Не хочется? Не делай! Если мне понадобится GC я всегда смогу его организовать и для Си++ или воспользоватся готовой реализацией(и кстати та что в .Net мягко говоря не лучшая). Зато мне никто GC не навязывает.
Q>Вопреки сложившемуся мнению, программы можно писать вообще без ООП, хотя это, конечно, требует несколько большего интеллекта.
Угу. На ассемблере. И перегрузки операторов там нету
Q>Странно слышать это от сторонника языка, где нельзя даже создать новый оператор.
Зачем мне новый? В Си++ 10 унарных и 32 бинарных оператора которые можно перегрузить не считая () который может принимать любое количество аргументов. Я думаю, что из 43-х значков вполне можно выбрать тот, который по душе. А на большее просто ASCII символов не хватит.
Здравствуйте, Quintanar, Вы писали:
Q>Это С++ так на вас влияет? Ведь ясно же, что имелась в виду свобода не думать о мелочах, а заняться более серьезными делами.
А я и не думаю о мелочах Если дурак-коллега не решил, что & это способ конкатекации строк, то я о мелочах типа "а какое действие выполняет этот перегруженный оператор?" вообще не думаю.
Здравствуйте, Quintanar, Вы писали:
Q>>>Ну все, пошла обычная песня. Любители С++ уперлись в некую мнимую свободу С++ и в упор не видят, что есть и другие виды свободы. Например, свобода не думать об управлении памятью, свобода не думать, что означает данная закорючка в данном контексте, свобода не разбирать километровые объявления шаблонных типов и т.д.
ГВ>>Слушай, давай уж обобщим до одного: "свобода не думать". Ну дык этаких "свободных разумов" хватает и без того. Прям девать некуда. Q>Это С++ так на вас влияет?
Нет. Только текст постинга. Плюс несложное лексическое обобщение. Хотел не обидеть, но обратить внимание на закономерность, показавшуюся мне забавной.
Q> Ведь ясно же, что имелась в виду свобода не думать о мелочах, а заняться более серьезными делами.
Дело-то как раз в том, что на плюсовиков (по моим наблюдениям) перечисленные мелочи не так уж сильно и влияют, если речь идёт о серьёзных делах. И "километровые объявления шаблонных типов" — не проблема, а естественное следствие самих шаблонов (не хочешь — не пользуй). И управление памятью — не проблема, а полезная фича. А закорючки... у любого языка свои закорючки. Даже у LISP.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, adontz, Вы писали:
A>Я активно пишу на Си++, C#, PHP и даже недавно на Паскале опять пришлось. Уж в чём в чём, а в том что я не знаю других языков обвинить меня точно нельзя. У Си++ есть недостатки, но перегрузка операторов не входит в их число.
А по-моему, входит. Не перегрузка как таковая, а то, что перегружено может быть все, что угодно, без разбора.
A>Я говорил о том, что F это обозначение силы, а m массы и для того чтобы читать чужие формулы не нужно осбо договариваться, нужно просто пользоваться общепринятыми обозначениями. Точно так же мне не придёт в голову для сложения двух чисел использовать %.
Ну использовать + для "сложения" строк вам же приходит в голову, хотя конкатенация строк к сложению никакого отношения не имеет.
A>А в праве не делать. Не хочется? Не делай! Если мне понадобится GC я всегда смогу его организовать и для Си++ или воспользоватся готовой реализацией(и кстати та что в .Net мягко говоря не лучшая). Зато мне никто GC не навязывает.
Адаптированный к недружелюбному компилятору GC менее эффективен. А навязывает, не навязывает, разбирайтесь с апологетами .NET. Для императивного стиля GC менее необходим, нельзя не согласиться, хотя реализация продвинутых приемов типа continuations или closures без GC затруднительна.
A>Зачем мне новый? В Си++ 10 унарных и 32 бинарных оператора которые можно перегрузить не считая () который может принимать любое количество аргументов. Я думаю, что из 43-х значков вполне можно выбрать тот, который по душе. А на большее просто ASCII символов не хватит.
Ну а банальный foreach реализовать нельзя. Или таки можно в виде огромной груды шаблонов?
Здравствуйте, Quintanar, Вы писали:
Q>Странно слышать это от сторонника языка, где нельзя даже создать новый оператор. С++ учиться и учиться гибкости у того же Lisp'a.
А как ими пользоваться? Ну, создам я оператор '**' и автоматически потеряю возможность двойного разыменования указателя, например. Lisp требует все операторы разделять пробелами и Lisp-машине по барабану, какие символы использованы в определении "оператора". У C++ другая грамматика — отсюда и другие возможности по созданию операторов. Так что, претензия мимо кассы.
С другой стороны, ASCII не хватит для того, чтобы передать всё богатство обозначений операторов, используемых в математике — для этого есть другие средства.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Дело-то как раз в том, что на плюсовиков (по моим наблюдениям) перечисленные мелочи не так уж сильно и влияют, если речь идёт о серьёзных делах. И "километровые объявления шаблонных типов" — не проблема, а естественное следствие самих шаблонов (не хочешь — не пользуй). И управление памятью — не проблема, а полезная фича. А закорючки... у любого языка свои закорючки. Даже у LISP.
Скажите честно, зачем вам управлять памятью? Вы пишете real time систему или игру, на худой конец? Ведь математик не изобретает каждый раз все с нуля, а использует имеющийся базис, чтобы идти вперед и не иметь дела с посторонними в общем-то вещами. И так везде. Если сильно надо, можно откатиться назад и пересмотреть основы — написать свой GC, свою систему классов и т.п. Но как правило, это не нужно.
Здравствуйте, Геннадий Васильев, Вы писали:
Q>>Странно слышать это от сторонника языка, где нельзя даже создать новый оператор. С++ учиться и учиться гибкости у того же Lisp'a.
ГВ>А как ими пользоваться? Ну, создам я оператор '**' и автоматически потеряю возможность двойного разыменования указателя, например. Lisp требует все операторы разделять пробелами и Lisp-машине по барабану, какие символы использованы в определении "оператора". У C++ другая грамматика — отсюда и другие возможности по созданию операторов. Так что, претензия мимо кассы.
Здравствуйте, Quintanar, Вы писали:
A>>Я активно пишу на Си++, C#, PHP и даже недавно на Паскале опять пришлось. Уж в чём в чём, а в том что я не знаю других языков обвинить меня точно нельзя. У Си++ есть недостатки, но перегрузка операторов не входит в их число. Q>А по-моему, входит. Не перегрузка как таковая, а то, что перегружено может быть все, что угодно, без разбора.
Это восходит к "проблеме дурака". Так от них везде проблемы! Есть такой хороший закон Мерфи: "Напишите программу, которой сможет пользоваться даже дурак и только дурак захочет ей пользоваться".
На том же Lisp тоже можно наворотить "от души" — совершенно недуракоустойчивый язык. Ну и?
[...]
Q>Ну а банальный foreach реализовать нельзя. Или таки можно в виде огромной груды шаблонов?
Какой конкретно foreach нужен? "Абстрактного" foreach не бывает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Quintanar, Вы писали:
ГВ>>Дело-то как раз в том, что на плюсовиков (по моим наблюдениям) перечисленные мелочи не так уж сильно и влияют, если речь идёт о серьёзных делах. И "километровые объявления шаблонных типов" — не проблема, а естественное следствие самих шаблонов (не хочешь — не пользуй). И управление памятью — не проблема, а полезная фича. А закорючки... у любого языка свои закорючки. Даже у LISP.
Q>Скажите честно, зачем вам управлять памятью?
Нравится. Ага, именно так.
Q> Вы пишете real time систему или игру, на худой конец? Ведь математик не изобретает каждый раз все с нуля, а использует имеющийся базис, чтобы идти вперед и не иметь дела с посторонними в общем-то вещами.
Мне не мешает управление памятью. Наоборот — красивое решение содержит в себе элегантное управление памятью (вернее — жизненным циклом объектов, а не памятью как таковой) как неотъемлемую часть. И не надо сравнивать с математикой — любая формула из ВМ включает в себя элементарные операции сложения/умножения.
Q> И так везде. Если сильно надо, можно откатиться назад и пересмотреть основы — написать свой GC, свою систему классов и т.п. Но как правило, это не нужно.
Точно также, как мне редко нужен GC, если я пишу на C++.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Quintanar,
> Скажите честно, зачем вам управлять памятью?
Управление памятью — составная часть управления временем жизни объектов. Первое в большинстве случаев само по себе имеет небольшое значение (хотя иногда тоже может стать важным), второе же важно значительно чаще, т.к. связано с разнообразными внешними по отношению к программе ресурсами: файлы, сокеты, различные handles операционной системы, соединения с базой данных и т.п. — короче, всевозможные ресурсы, которые нужно освобождать вовремя и вне зависимости от возникновения исключительных ситуаций. И в этом деле помощь языка в детерминированном разрушении очень помогает.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Трурль, Вы писали:
Т>>Могло быть и что-то вроде Т>>
Т>>std::cout.print("My data: " ).print(my_data).print(", your data: ").print(your_data).nl.flush;
Т>>
E>Как раз и нет. Ведь print -- это метод std::ofstream и как же мне добавить перегрузку метода print в класс std::ofstream для своего типа?
Ну, для ofstream не получится, а вообще:
class my_stream
{
public:
template<typename T>
my_stream &print(const T &rhs)
{
::print_to_stream(stream_, rhs); // Это - глобальная функция.
}
private:
some_stream_type stream_;
};
Останется только специализировать ::print_to_stream дл своих типов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
class my_stream
{
public:
template<typename T>
my_stream &print(const T &rhs)
{
::print_to_stream(stream_, rhs); // Это - глобальная функция.return *this;
}
private:
some_stream_type stream_;
};
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Quintanar, Вы писали:
Q>А по-моему, входит. Не перегрузка как таковая, а то, что перегружено может быть все, что угодно, без разбора.
Ну так это проблема "обезьяны с гранатой". Если ты не доверяешь человеку настолько, чтобы подпускать его к Си++ — не подпускай. си++ язык требующий высокого профессионального уровня. Именно требующий. Это не VB и "среднестатистический ламерок не разобрался" неуместный упрёк. Си++ и не расчитан на то, чтобы в нём кто попало разбирался. Язык мощный но вместе с тем и сложный.
Q>Ну использовать + для "сложения" строк вам же приходит в голову, хотя конкатенация строк к сложению никакого отношения не имеет.
Это общепринятое обозначение. Оно применяется не только для std::string но и для многих других строк и не только в Си++. То что + применяется для конкатекации это даже если и недостаток, то уж точно не Си++'овый.
A>>Зачем мне новый? В Си++ 10 унарных и 32 бинарных оператора которые можно перегрузить не считая () который может принимать любое количество аргументов. Я думаю, что из 43-х значков вполне можно выбрать тот, который по душе. А на большее просто ASCII символов не хватит.
Q>Ну а банальный foreach реализовать нельзя. Или таки можно в виде огромной груды шаблонов?
А какая разница как что-то реализованно если использование всё равно одинаково? Давай тогдла отменим мусещк потому что у него длинные исходники. Мне как-то без разницы vector это встроенный тип или нет
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, cranky, Вы писали:
Q>>>Идеологически правильный вариант — выбрать другое обозначение для операции конкатенации. Ибо конкатенация по сути — это слияние списков, а не сложение.
C>> Ну это совсем идеалистический вариант — представление строки списком, всё-таки нечто с рандомным доступом подошло бы лучше.
Хотя да, это тоже всего лишь косность мышления, последствия ненавистного императического программирования Списки оно, конечно, удобней для обобщённого функционального программирования.
Q>Это не совсем идеалистический вариант, кое-где так и сделано. Кроме того, никто не говорит о том, что обязательно нужно представлять строку списком, речь идет о том, что конкатенация по сути — это слияние списков, а не арифметическре сложение, и логично для этого использовать другое обозначение.
Тогда можно совсем обобщить: конкатенация — это операция слияния регулярных структур переменного размера. Есть возражения?
Здравствуйте, Quintanar, Вы писали:
Q>Не соглашусь. В данном конкретном случае есть некоторое удобство, однако в целом, это поощряет использование перегрузки для всего, что угодно, без всякой привязки к смыслу. Мне больше импонирует Haskell'овский подход. Там можно наложить ограничения на перегрузку для того, чтобы перегружаемые функции или операнды вели себя более предсказуемо.
Есть такая штука — практика. И она показывает, что никаких проблем перегрузка не вызывает. На практике никто не кидается перегружать все какие можно операторы для все попавшихся под руку типов. Те кто может навалять дурака просто недодумываются применить это средство.
Ну, и апеллировать к неразумности не разумно . Тут кто-то правильно заметил, что если человек идиот, то он и без перегрузки операторов способен наворотить многое. А разумный человек будет использовать перегрузку операторов там где это может дать большую выразительность.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Прям девать некуда.
Ведь ясно же, что имелась в виду свобода не думать о мелочах, а заняться более серьезными делами. 
Если дурак-коллега не решил, что & это способ конкатекации строк, то я о мелочах типа "а какое действие выполняет этот перегруженный оператор?" вообще не думаю.
Ну это совсем идеалистический вариант — представление строки списком, всё-таки нечто с рандомным доступом подошло бы лучше.
