Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет. S>Опять двойка. Читать про value-типы.
Ну если мы начнем двойки друг другу ставить — боюсь, давно уже друг друга бы отчислили
По существу — естественоо, я имел в виду классы, а не структуры.
Здравствуйте, TK, Вы писали:
TK>Интересно, а какой смысл вести дискуссию цель которой доказать, что твой собеседник чего-то там не знает? Какая в этом польза для сообщества?
Польза очень простая — товарищь агитирует за крайне вредную для новичком идею — что паттерны вредны.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вполне возможно. Кстати, студент вовсе не пострадал PD>Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать.
Да нет, проблема в другом. При современном развитии железа и компиляторов, очень трудно прогнозировать как та или иная операция выйдет по производительности. В принципе от алгоритмической сложности отойти невозможно. Но вот сложность того или иного метода дизайна спрогнозировать сложно. Java — пытается запихнуть объекты по возможности в стек. Пытаются выдавить лишние действия из циклов. Пытаются работать через регистровую память. Пытаются уместить данные в кэше процессора. Пытаются ублажить конвейры процессора. И многое многое многое о чем я не знаю. Я только знаю что эта шняга будет работать, но каждый раз лазить в ассемблер и узнавать как оно в реальности работает, и узнавать что куча кода скомпилировалось в одну ассембленую команду(как это часто бывает в STL), я не могу и не буду. Знания конечно сила, я могу примерно прогнозировать во что это выльется для знакомых мне платформ. Но явно этими знаниями я пользуюсь редко и только для наибольшего криминальных команд и подсистем.
Лучше я отдам эти вопросы на откуп умному компилятору и заумному процессору. А сам буду делать логику, которая нужна мне а не им. Они сами справятся.
S>) S>Для примера более интересного поведения, рекомендую ознакомиться со структурой System.DateTime.
Упс. Да, здесь синтаксически насахарили хорошо. А вот тебе примеры того, что есть кое-что, что применимо к ссылочным объектам, и неприменимо к плоским значениям:
1. Деструкторы.
2. Выделение на куче.
3. Управление временем жизни с помощью ГЦ.
...
n. % уверен ты ещё много чего вспомнишь...
Лично мне это даёт основание не называть value-значения объектами. И фраза П. Дворкина в этом смысле верна. Ты можешь называть всё объектами, но тогда в определённые моменты времени ты вынужден вставляеть оговорки "для ссылочных объектов X, а вот для плоских объектов Y", и вышеуказанная фраза для тебя содержит противоречие.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вполне возможно. Кстати, студент вовсе не пострадал PD>>Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать. GZ>Да нет, проблема в другом. При современном развитии железа и компиляторов, очень трудно прогнозировать как та или иная операция выйдет по производительности. В принципе от алгоритмической сложности отойти невозможно. Но вот сложность того или иного метода дизайна спрогнозировать сложно. Java — пытается запихнуть объекты по возможности в стек. Пытаются выдавить лишние действия из циклов. Пытаются работать через регистровую память. Пытаются уместить данные в кэше процессора. Пытаются ублажить конвейры процессора. И многое многое многое о чем я не знаю. Я только знаю что эта шняга будет работать, но каждый раз лазить в ассемблер и узнавать как оно в реальности работает, и узнавать что куча кода скомпилировалось в одну ассембленую команду(как это часто бывает в STL), я не могу и не буду. Знания конечно сила, я могу примерно прогнозировать во что это выльется для знакомых мне платформ. Но явно этими знаниями я пользуюсь редко и только для наибольшего криминальных команд и подсистем. GZ>Лучше я отдам эти вопросы на откуп умному компилятору и заумному процессору. А сам буду делать логику, которая нужна мне а не им. Они сами справятся.
Я готов со всем этим согласиться, но с одним "но". Если речь идет все же о С++, то никакой умный компилятор и заумный процессор тебя не спасет, если ты начнешь развесистое дерево передавать по значению. Там все же конструктор копирования, который в себе такое потянет, что мало не покажется (и по времени, и по памяти). Если же там даже чистая структура С, то при ее размерах порядка десятков байт (а таких структур в том же Win32 много) делать копии — просто время зря расходовать (конечно, если не нужна именно копия). И вот это надо не допускать.
В пограничных случаях — (POINT, double и т.д.) разница может быть несущественной, верно. Но приучать надо все же к грамотному кодированию.
А кстати, как в C# сделать копию объекта, если надо все же ? Как я понимаю, надо реализовать ICloneable в классе ? А что если в классе есть ссылки на другие классы, которые этот интерфейс не реализуют и помечены как sealed ?
Здравствуйте, IT, Вы писали:
IT>Последнее время я всё больше и больше убеждаюсь, что все эти проработки-шмаработки, паттерны-шматтерны конечно хорошо, но находятся далеко не на первом месте. Почему-то у меня всё чаще и чаще на первое место выходит готовность системы к её последующим изменениям под новые требования. Т.е. заменить вот эту фенечку вот на такую шменечку и воткнуть между ними вот такую жменечку. Второе место занимает, кто бы мог подумать — готовность системы к изменениям после её изменения.
а паттерны-шматтерны не способствуют разве большей прозрачности (понятности) реализации? что в конечном итоге и равно готовности к изменениям. Или как ты эту готовность обеспечиваешь?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Теперь vdimas начал антипаттерновскую агитацию.
Думаю, что Дмитрий (vdimas) совершенно не собирался делать антипаттерновскую агитацию. А хотел сказать, что паттерны -- это всего лишь одна из программиских финтифлюшек (такой же, как и оптимизация, кстати). К которой и относится нужно соответственно, без религиозно-фанатичного обожания.
PD>Но пасаран!
Но пасаран!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я готов со всем этим согласиться, но с одним "но". Если речь идет все же о С++, то никакой умный компилятор и заумный процессор тебя не спасет, если ты начнешь развесистое дерево передавать по значению. Там все же конструктор копирования, который в себе такое потянет, что мало не покажется (и по времени, и по памяти). Если же там даже чистая структура С, то при ее размерах порядка десятков байт (а таких структур в том же Win32 много) делать копии — просто время зря расходовать (конечно, если не нужна именно копия). И вот это надо не допускать.
И здесь не всегда. Если процедура синлайнется, то вполне возможно что компилятор поймет что копировать не стоит. Вобщем ситуаций может быть много.
PD>В пограничных случаях — (POINT, double и т.д.) разница может быть несущественной, верно. Но приучать надо все же к грамотному кодированию.
Вобщем, насколько я понял, у нас различия в термине "грамотное кодирование".
PD>А кстати, как в C# сделать копию объекта, если надо все же ? Как я понимаю, надо реализовать ICloneable в классе ?
Да. PD>А что если в классе есть ссылки на другие классы, которые этот интерфейс не реализуют и помечены как sealed ?
Ключевые слова deep copy и shadow copy. Первый копирует все объекты на который ссылаются, второй копирует ссылки. По умолчанию обычно действует shadow copy.
Здравствуйте, AndrewVK, Вы писали:
GZ>>А по мне существует только один паттерн который называется Low Coupling/High Cohesion.
AVK>Это не паттерн, это оценочный критерий. Паттерн это конкретное архитектурное решение.
Паттерны так же относятся к набору практик. И упомянутый оценочный критерий тоже скорее из разряда практик. (или ссылку на формальное доказательство, если есть)
А практики — они такие интересные по сути вещи, что их применение может зависеть от внешних условий. Другими словами, даже упомянутый оценочный критерий не всегда требуется для оценки решений. Как пример — разработка практически любой аппаратуры, содержащей выч. компоненты. За требованиями минитюаризации, минимизации ресурсов, или даже исполнения в виде одной гибридной схемы и пр., оценка связанности компонентов просто теряет свою значимость. Связанность заведомо 100%-я.
V>>Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.
IT>Последнее время я всё больше и больше убеждаюсь, что все эти проработки-шмаработки, паттерны-шматтерны конечно хорошо, но находятся далеко не на первом месте. Почему-то у меня всё чаще и чаще на первое место выходит готовность системы к её последующим изменениям под новые требования. Т.е. заменить вот эту фенечку вот на такую шменечку и воткнуть между ними вот такую жменечку. Второе место занимает, кто бы мог подумать — готовность системы к изменениям после её изменения.
Счастливый человек. ИМХО, судя по твоим приоритетам, общий дизайн ты уже давно не разрабатываешь, он у тебя "сам собой получается естественным образом". Собственно, так и должно быть при наличии опыта.
А у некоторых пока стоят проблемы, (хе-хе) с путями реализаций требований. Эти пути и обсуждаем.
Здравствуйте, eao197, Вы писали:
E>Думаю, что Дмитрий (vdimas) совершенно не собирался делать антипаттерновскую агитацию. А хотел сказать, что паттерны -- это всего лишь одна из программиских финтифлюшек (такой же, как и оптимизация, кстати). К которой и относится нужно соответственно, без религиозно-фанатичного обожания.
Я бы это утверждение расширил. Без религиозно-фанатичного обожания надо относиться к оптимизации, паттернам, абстракциям, С++, C#, Java, .Net и т.д. и т.п. И вообще — не сотвори себе кумира
Боюсь только, что объяснять это некоторым — все равно, что агитировать римского папу вступить в общество атеистов
Здравствуйте, vdimas, Вы писали:
V>Паттерны так же относятся к набору практик. И упомянутый оценочный критерий тоже скорее из разряда практик.
Я что то совсем перестал понимать твой русский язык. Как может оценочный критерий быть практикой?
V>А практики — они такие интересные по сути вещи, что их применение может зависеть от внешних условий. Другими словами, даже упомянутый оценочный критерий не всегда требуется для оценки решений. Как пример — разработка практически любой аппаратуры, содержащей выч. компоненты. За требованиями минитюаризации, минимизации ресурсов, или даже исполнения в виде одной гибридной схемы и пр., оценка связанности компонентов просто теряет свою значимость. Связанность заведомо 100%-я.
Здравствуйте, GlebZ, Вы писали:
PD>>Я готов со всем этим согласиться, но с одним "но". Если речь идет все же о С++, то никакой умный компилятор и заумный процессор тебя не спасет, если ты начнешь развесистое дерево передавать по значению. Там все же конструктор копирования, который в себе такое потянет, что мало не покажется (и по времени, и по памяти). Если же там даже чистая структура С, то при ее размерах порядка десятков байт (а таких структур в том же Win32 много) делать копии — просто время зря расходовать (конечно, если не нужна именно копия). И вот это надо не допускать. GZ>И здесь не всегда. Если процедура синлайнется, то вполне возможно что компилятор поймет что копировать не стоит. Вобщем ситуаций может быть много.
Тут еще вот в чем дело. Передавая что-то по значению, мы должны знать, что это не приведет к черезмерным накладным расходам. Для POINT и RECT я это знаю, т.к. структуры тривиальные. Для std::vector, std::list или std::string я так же знаю, что, скорее всего, приведет к расходам, т.к. их реализации используют динамическую память. А если мне встречается какой-то не стандартный тип, скажем, auth_info_t или priority_levels_t. Про который я должен знать только его public-интерфейс и не должен знать деталей его реализации. Как мне оценить, что передача priority_levels_t по значению будет эффективной? Заглянув в состав его полей? А если там только одно поле-указатель, то значит ли это что-нибудь? Вдруг priority_levels_t через идиому PImpl реализован. Или, что еще опаснее, в текущей версии priority_levels_t можно эффективно копировать, а в следующей версии его реализацию сменят на более догоростоющую в копировании. Передача же объекта по ссылке гарантированно дает мне низкие накладные расходы и не обязывает меня обращать внимание на детали реализации используемых мной типов.
И еще один момент. В C++ есть понятие копирования объекта. А есть понятие копирования указателя на объект. Если мы передаем объект по значению мы используем именно понятие копирование объекта. И если функция/метод требует в качестве параметра именно значение объекта, то это не спроста. Значит функция внутри себя будет это свою личную копию иметь так, как фантазия позволит. И иметь именно копию, а не исходный объект. В случае же, если функция требует в качестве параметра константный указатель/ссылку на объект, функция декралирует, что исходный объект будет использоваться в операция внутри функции. Не константный указатель/ссылка же явно декларирует, что функция функция будет изменять исходный объект. В любом из случаев намерения функции по отношению к объекту становятся понятными исходя просто из описания функции. Поэтому описание параметра функции как константной ссылки или указателя на объект говорит пользователю: не бойся, не съем я твой объект
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
PD>>И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
Супер рассказ. Я столкнулся с подобным в своем старом коде, когда пришла пора его оптимизировать. Самое обидное — это то, что "оптимизируя" его при написании я "наоптимизировал" совсем не то, а главное создал совершенно немодифицируемый код. Пришлось переписывать по-человечески, и, разумеется, те микрооптимизации оказались ненужными ибо макрооптимизация с лихвой перекрыла прошлый выигрышь от них.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>а что, есть абсолютная уверенность, что они летали?
сам не знаю, не видел но специалисты утверждают, что летали
ANS>"Красота", это интегральная субьективная оценка, которую ты присваиваешь чему-либо. Вот ты считаеш птеродактелей уродцами, а может если бы ты знал об устройстве их крыльев, об аэродинамических качествах, то считал бы их образцом для подражания. То есть кто-то считает мечь прекрасным оценивая балансировку, сталь, а кто-то по наличию рюшиков.
вот ты сам это и сказал. Нет никакого общего понятия красоты, ибо понятие это субъективное и к тому же подверженное изменениям со временем. Вполне логично, что конструктор самолетов считает красивым хорошо спроектированный самолет (особенно — им самим спроектированный ). Вполне логично, что другой конструктор с ним не согласится. И также вполне логично, что тот самый конструктор посмотрит лет через двадцать на свой самолет и скажет "ну и уродец!"
ANS>См. выше. Я просто не смог сходу подобрать более лучшего слова чем "функциональность". Читай "интегральная оценка". А проблема в том, что довольно часто можно видеть высказывание типа "я написал красиво, а потом занялся оптимизацией и программа стала уродцем".
А ты представь себе, что тот самый конструктор сделал красивейший самолет, который замечательно летает, а ему потом сказали "ну ты извини, но твой самолет по размаху крыльев на три метра превышает имеющиеся у нас ангары. Так что ты придумай уж что-нибудь"
Здравствуйте, GlebZ, Вы писали:
GZ>И здесь не всегда. Если процедура синлайнется, то вполне возможно что компилятор поймет что копировать не стоит. Вобщем ситуаций может быть много.
Стоп, или я что-то не понимаю, или здесь что-то не так. Если ее передают по значению, ее обязаны скопировать. Потому что будет там inline или нет — не так уж важно, а вот формальный параметр, переданный по значению, я имею полное право изменять внутри вызываемой функции, и эти изменения не должны сказаться на фактическом параметре.
GZ>Вобщем, насколько я понял, у нас различия в термине "грамотное кодирование".
GZ>Ключевые слова deep copy и shadow copy. Первый копирует все объекты на который ссылаются, второй копирует ссылки. По умолчанию обычно действует shadow copy.
Это я все понимаю, а как все же этот deep copy реализовать ?
class MyClass
{
AnotherClass c;
//
}
и у AnotherClass ICloneable не реализован. Как его deep copy сделать ?
В С++ такое в принципе невозможно. Есть AnotherClass — должен быть у него конструктор копирования. Как он устроен — меня не интересует, а работать будет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, TK, Вы писали:
TK>>Интересно, а какой смысл вести дискуссию цель которой доказать, что твой собеседник чего-то там не знает? Какая в этом польза для сообщества?
AVK>Польза очень простая — товарищь агитирует за крайне вредную для новичком идею — что паттерны вредны.
Где именно?
Новички уже давно поняли, за что именно я агитирую.
1.1.4 stable rev. 510
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
