MSS>>Как хорошо, что Си не дает передавать структуры by value... и временных объектов не плодит...
RO>С каких это пор не дает?
Когда я это последний раз пробовал сделать — получил warning, и тут же про это забыл. Зачем это нужно-то? если мне будет нужно by value — то я сам объявлю Tmp и сделаю Tmp = Struct; f(&Tmp); Делов-то
Я думаю, что в целом Линус прав, но кое в чем он ошибается. Просто у
этих языков — принципиально разные цели. Настолько разные, что их, по
большому счету, не имеет особого смысла сравнивать. C++ (как и все ОО
языки), в первую очередь, ориентирован на эффективность разработки и
сопровождения программы, а C — на эффективность исполнения (память,
скорость, объем кода). Самое интересное, что стиль программирования
действительно меняется с языком. Происходит это за счет того, что язык
поощряет определенные решения, упрощая процесс их реализации. Как
правило, программы, написанные одним и тем же человеком на C, обычном
C++, при помощи метапрограммирования на C++ или функциональных языков,
имеют принципиально различные проектные решения.
Вот и получается, что выбрав в качестве одной из первичных целей
эффективность исполнения, им пришлось намеренно отказаться от C++.
Конечно, на C++ тоже можно писать эффективные программы (как и на C —
неэффективные). Просто для этого, как правило, приходится прилагать
больше усилий и тщательнее контролировать себя. В тоже время, существует
множество задач, где использование C++ оправданно и желательно.
Здравствуйте, Erop, Вы писали:
TL>>Я в Линусе чайник: что еще кроме линукса Линус написал? E>Не помню. Мни и линукса вполне достаточно. Это очень большой и серьёзный проект
Цитата из Википедии: (да, более достоверных источников... да мне просто лень искать )
В настоящее время лишь около двух процентов системного ядра «Linux» написано самим Торвальдсом, но за ним остаётся решение о внесении изменений в официальную ветку ядра.
Торвальдс владеет товарным знаком «Linux» и следит за его использованием[4] через некоммерческую организацию «Linux International» и при помощи пользователей «Linux» во всём мире.
Это и есть "очень большой и серьезный проект"?
Голь на выдумку хитра, однако...
Re[13]: Ты просто неверно понимаешь концепцию константности
Здравствуйте, Pzz, Вы писали:
Pzz>К примеру, взять такой объект:
Pzz>
Pzz>struct str
Pzz>{
Pzz> char *s;
Pzz>};
Pzz>
Pzz>В буквальном C++'ном понимании его константность заключается в том, что я не смогу поменать указатель s. Но мне ничего не помешает пописать в память, на которую ссылается этот указатель. Изменится при этом значение объекта или нет?
Ты просто плохо понимаешь концепцию константности в С++.
AFAIK, в C++ всё устроено как-то так
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, The Lex, Вы писали:
TL>>>Ключевой момент был неоднократно упомянут и указан явно тоже: практик в _чем_ именно? E>>В программировании довольно сложных систем. А Александреску практик в написании книжек...
TL>Я в Линусе чайник: что еще кроме линукса Линус написал?
Git и книжку про то, как ему было в кайф писать линух и как ему нравится кататься на красном BMW.
Но я бы считал его главной заслугой способность поддерживать разработку ядра линуха на плаву. Это нетривиальная задача, с точки зрения управления проектами.
Здравствуйте, Maxim S. Shatskih, Вы писали:
TL>>Я в Линусе чайник: что еще кроме линукса Линус написал?
MSS>7 лет назад был 15 мег зип с исходниками. Конечно, там не все один Линус писал, но он писал самые старые и фундаментальные вещи и еще и поддерживал все это как тимлид.
Т.е. Линус "удачно попав под струю" осуществил в принципе мечту каждого человека: заниматься любимым делом и не думать о деньгах. Однако же тут уже заметили, что для остальных "население планеты минус Линус" это далеко не всегда так, а чаще как раз наоборот. К тому же, как уже заметили, ничего особо нового Линус в технический прогресс не привнес — по сути своей как ни посмотри, а Линукс — явление больше социально-организационного масштаба, чем технологического.
Лично у меня нет мечты — сидеть за компьютером и писать программы. Лично я больше мечтаю об отельчике на берегу моря. Лично мне что удачливый Линус, что удачливый Гейтс, что иже с ними Стив и Стив — все это примеры удачливых людей — а сколько было неудачливых?
Лично я пока что не вижу чем Сам Линус может мне помочь в моей лично скромной жизни. Копаться в ядре линукса я не буду — что лично мне Линус еще может предложить? А полезного лично для меня?
Здравствуйте, hexis, Вы писали:
H>Я думаю, что в целом Линус прав, но кое в чем он ошибается. Просто у H>этих языков — принципиально разные цели. Настолько разные, что их, по H>большому счету, не имеет особого смысла сравнивать. C++ (как и все ОО H>языки), в первую очередь, ориентирован на эффективность разработки и H>сопровождения программы,
Это заблуждение. C++ в первую очередь рассчитан на индустриальный стиль программирования — когда главный индус описывает интерфейсы, а подчиненные индусы наращивают мясо на эти интерфейсы. Это не обеспечивает эффективности разработки, это обеспечивает массштабируемость (больше индусов — больше кода, почти в линейной пропорции, до тех пор, пока bandwidth главного индуса не исчерпан. А потом — кирдык).
Re[14]: Ты просто неверно понимаешь концепцию константности
Здравствуйте, Erop, Вы писали:
Pzz>>В буквальном C++'ном понимании его константность заключается в том, что я не смогу поменать указатель s. Но мне ничего не помешает пописать в память, на которую ссылается этот указатель. Изменится при этом значение объекта или нет?
E>Ты просто плохо понимаешь концепцию константности в С++. E>AFAIK, в C++ всё устроено как-то так
Я очень хорошо понимаю. Проблема как раз в том, что в C++ нет явного способа, поддерживаемого синтаксисом языка, выразить, что именно является значением объекта. А рассуждения о константности имеют смысл только как о переменной, значение которой нельзя менять.
Заметим в скобках, что в языках, в которых нет переменных (т.е., чистая функциональщина), и понятие константы не имеет смысла. В такого рода языках выражение let x = 5 не создает переменной x, а создает человеческое имя для значения 5.
Здравствуйте, Pzz, Вы писали:
Pzz>Это заблуждение. C++ в первую очередь рассчитан на индустриальный стиль программирования — когда главный индус описывает интерфейсы, а подчиненные индусы наращивают мясо на эти интерфейсы. Это не обеспечивает эффективности разработки, это обеспечивает массштабируемость (больше индусов — больше кода, почти в линейной пропорции, до тех пор, пока bandwidth главного индуса не исчерпан. А потом — кирдык).
Простите, а как разрабатывается линукс? Все дружно пишут кто что хочет, а потом Линус пытается найти из всего этого что-нибудь полезного и интегрировать в систему?
Вообще-то "индустриальный стиль программирования" применим для любого языка, способного реализовать систему из отдельных модулей, объединенных интерфейсами. Или описание функций — это не есть "описать интерфейсы"?
ЗЫ: Линус — не индус. Значит Си хороший, а Си++ — плохой. Имхо, логично.
Здравствуйте, Roman Odaisky, Вы писали:
RO>std::vector<int> const someIntegers(42u, 42);
RO>там наверняка внутри три указателя — начало данных, конец данных, конец выделенной области памяти. Как ты этот вектор ни используй, данные ты не изменишь. Спрятано всё.
Это все перестает работать, как только мы попытаемся засунуть в вектор объект, которому не все равно, где лежать.
Pzz>>Проблема в том, что в C++ управление памятью — ручное. Как его не оборачивай в темплейтные обертки, компилятор все равно не в курсе, что происходит с памятью. А без этого, видимо, высокоуровневый язык не построишь.
RO>Открою секрет: в C++09 изо всех сил стараются добавить GC. Ручное управление памятью — не проблема.
C++ вообще, как хороший наркотик. Чем больше колешься, тем больше хочется.
Pzz>>На C++, на самом деле, тоже толком никак. Например потому, что конструктор не знает, конструирует ли он константный или mutable объект.
RO>Это лишено смысла… X const x = X(); — здесь какой объект конструируется?
Отнюдь нет. Конструируя константный объект, можно было бы не заботиться о конструировании тех его запчастей, которые нужны только для неконстантного объекта. Если бы об этом можно было узнать в момент конструирования...
Здравствуйте, The Lex, Вы писали:
TL>Простите, а как разрабатывается линукс? Все дружно пишут кто что хочет, а потом Линус пытается найти из всего этого что-нибудь полезного и интегрировать в систему?
Ну примерно. К линусу приходят разные люди с идеями, "я вот тута сделал кульную штуку, давай включим ее в ядро". Линус либо включает, либо не включает. Иногда даже объясняет, почему он принимает то или иное решение
TL>Вообще-то "индустриальный стиль программирования" применим для любого языка, способного реализовать систему из отдельных модулей, объединенных интерфейсами. Или описание функций — это не есть "описать интерфейсы"?
C++ дает дополнительную гибкость именно в описании интерфейсов. В остальном он примерно такой же, как Си.
RO>>Это лишено смысла… X const x = X(); — здесь какой объект конструируется?
Pzz>Отнюдь нет. Конструируя константный объект, можно было бы не заботиться о конструировании тех его запчастей, которые нужны только для неконстантного объекта. Если бы об этом можно было узнать в момент конструирования...
В такой ситуации имхо логичнее просто сделать 2 различных типа:
class X_const {};
class X {};
Логичнее даже наверное так:
class X_const {};
class X : public X_const {};
Так проще, и в противном случае не удасться полность избавиться от издержек, т.к. раскладку объекта менять не получится.
Pzz wrote: > > Это заблуждение. C++ в первую очередь рассчитан на индустриальный стиль > программирования — когда главный индус описывает интерфейсы, а > подчиненные индусы наращивают мясо на эти интерфейсы. Это не > обеспечивает эффективности разработки, это обеспечивает > массштабируемость (больше индусов — больше кода, почти в линейной > пропорции, до тех пор, пока bandwidth главного индуса не исчерпан. А > потом — кирдык).
Ну, тогда мы явно заблуждаемся вместе. Что такое "индустриальный"
стиль программирования, как не эффективность на этапе разработки?
Принцип — разработать продукт с удовлетворительным качеством в заданные
сроки, использовав заданные ресурсы. Как правило ресурсы приоритетнее.
Да и вы приводите пример повышения именно такой эффективности —
сокращение времени, потраченного на разработку, за счет
распараллеливания задач и возможность использования множества легко
доступных посредственных программистов. А таланты архитектора — не
принадлежность языка или какой-то парадигмы. Хотя вполне могут
ограничиваться ими.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Это лишено смысла… X const x = X(); — здесь какой объект конструируется?
Вообще-то тут конструируется два объекта, один временный и один константный. При этом компилятор может оптимизировать это дело и строить сразу константный.
В целом не понятно что мешает как-то предоставить доступ к информации о том, какой объект конструируется, временный, константный, на стеке или в куче. Правда не понятно зачем это так уж сильно надо. Разве что для какой-то хитрой оптимизации...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, hexis, Вы писали:
H>Ну, тогда мы явно заблуждаемся вместе. Что такое "индустриальный" H>стиль программирования, как не эффективность на этапе разработки?
Для начала надо определить понятие эффективности. Но как бы не была определена эффективность, ясно, что она является дробью, в числителе у которой то, что мы преобрели, а в знаменателе — то, что потратили.
Индустриальный же способ разработки — это в первую очередь не эффективность как таковая, а масштабируемость. Т.е., сохранение эффективности более-менее неизменной при существенном увеличении потраченных ресурсов (например, числа разработчиков). Что позволяет в конечном итоге увеличить отдачу, просто вкладывая в проект дополнительные бапки.
Заметим в скобках, что если бабок мало, масштабируемость совершенно не нужна. В отличии от эффективности.
Здравствуйте, Pzz, Вы писали:
Pzz>Не насколько не распостранена. Но факт передачи указателя явно виден в точке вызова. Т.е., когда Вы читаете вызов функции, Вам не надо заглядывать в другой файл, чтобы понять, что на самом деле получит эта функция — значение или ссылку.
Ну если программу пишут нормально, то от константных ссылок указатели не берут, и уж тем более не прихранивают.
Вот смотри. функция1
одинаково неправильные...
Чем тут мешает именно ссылка? Это всего лишь оптимизация передачи значения объекта в функцию. Зачем про эту оптимизацию знать в точке вызова?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pzz, Вы писали:
Pzz>Индустриальный же способ разработки — это в первую очередь не эффективность как таковая, а масштабируемость. Т.е., сохранение эффективности более-менее неизменной при существенном увеличении потраченных ресурсов (например, числа разработчиков). Что позволяет в конечном итоге увеличить отдачу, просто вкладывая в проект дополнительные бапки.
Нет такого — и никогда не было. Софт — это не единственный и далеко не новый "объект индустриального производства, нуждающийся в разработке". Тупо "масштабируются" при сохранении возможности создания конечного продука только рутинные операции: надо написать 100 буков "А" — можно посадить 1 человека, а можно 10, а можно и 100 — получим почти линейную масштабируемость. Если же надо написать "Войну и мир" — читай, "разработать" — масштабировать на уровне "чем больше наймем — тем лучше" никак не получится — и никогда не получалось. Еще раз: до софта была куча других промышленных объектов, которые точно так же проектировались, как софт — разрабатывается. И "просто масштабировать" производительность КБ, посадив 100 проектировщиков вместо 10 можно только на рутинных, четко определенных и ограниченных операциях, вроде черчения или расчетов.
Имхо, это дискуссия не для этого топика и не для этого раздела — это уже в "философию".
Pzz>Заметим в скобках, что если бабок мало, масштабируемость совершенно не нужна. В отличии от эффективности.
Тема бабок не раскрыта. Тема эффективности не раскрыта. Тема масштабируемости не раскрыта. Тема создания конечно продукта не раскрыта. Незачот.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Как хорошо, что Си не дает передавать структуры by value... и временных объектов не плодит... RO>>С каких это пор не дает?
MSS>Когда я это последний раз пробовал сделать — получил warning, и тут же про это забыл. Зачем это нужно-то? если мне будет нужно by value — то я сам объявлю Tmp и сделаю Tmp = Struct; f(&Tmp); Делов-то
Во-первых, зачем так пренебрегать замечательными возможностями C99?
)
