Здравствуйте, Sheridan, Вы писали:
S>Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно.
Если тебе так проще, то ладно, считай что я обиделся.
S>Тем точнее. Да.
Просто был вопрос: P>То есть, если я правильно понял, использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры?
Твой ответ: S>Очень приблизительно как то так.
Я тебе кусочек псевдокода привел, чтобы ты развил свою мысль о том что использующие ручное управление памятью — программисты, а авиоматическое — говнокодеры. Просто понимаешь, на этот вопрос нет ответа во фразе S>Очень приблизительно как то так.
Вот я и подумал грешным делом, что на коде ты объяснишь нам неразумным неквалифицированным обидчивым разработчикам, почему же так.
Но нет, Шеридан в своем репертуаре: вырывание из контекста, уход в сторону, трансформация, поток сознания и тому подобные фокусы, которые мы тут много лет наблюдаем.
M>>Другие программисты точно так же, как ты «не используют GC/СП в своем коде», а «используют либу, где используется GC». S>Другие программисты, несмотря на наличие ГЦ вручную управляют памятью? Нет. Тупо потому что возможности такой нет, по крайней мере в большинстве языков с ГЦ.
Ты ею тоже не управляешь, от слова «нигде».
S>Более того, они всячески гордятся этим самым ГЦ и всячески защищают его, всячески хвалят итд. Более того, делят языки на языки с ГЦ и прочие, и навскидку могут назвать с десяток языков с ГЦ. То есть, они целенаправленно ищут язык с ГЦ и целенаправленно его используют.
Да. Потому что есть объективная реальность: есть языки с GC, а есть языки без GC. И грамотный специалист:
— выберет тот инструмент, который наиболее полно соответсвует его задаче
— вместо безумных фантазий на тему «ааааааа праизвадитильнасть» будет эту производительность замерять и профилировать. И ВНЕЗАПНО окажется, что основная проблема — это не GC или СП, а кривые алгоритмы и доступ к базе данных (в 99.99999(9)% случаев)
S>Чем я отличаюсь от них с вышеупомянутым кутэ, которая использует СП? Я в открытую говорю, что СП — дерьмо и я в своём коде их не использую.
Как это ты не используешь, если используешь? Ты нигде в своих проектах не занимаешься ручным управлением памяти. За тебя все делают СП.
S>Хорош ли такой подход? Думаю, да. Я знаю время жизни своих объектов, из за этого у меня нет утечек (надеюсь), так же у меня нет оверхеда по памяти и по процессору из за работы ГЦ.
Нет. Ты не знаешь вермени жизни объектов, их знают СП внутри Qt. Утечек памяти у тебя нет тоже только из-за того, что внутри Qt за этим следят СП. Оверхед по памяти у тебя равен оверхеду по памяти на СП внутри Qt.
S>Плох такой подход? Нет. Или ты считаешь, что плох? Почему?
Подход плох в том, что ты как 10 лет тому назад, как сейчас, не имеешь ни малейшего представления, о чем говоришь.
TDWContainerBase *dw = new TDWContainerBase(title, icon, this); // создаем СП
dw->init(); // в зависимости от того, что такое TDWContainerBase, тут может создаться еще сотня СП
m_docks.append(dw); // передаем управление смартпойнетром в объект m_docks
QAction *a = dw->toggleViewAction(); // получаем СП
a->setIcon(icon); // передаем управление смартпойнетром на icon в объект a
a->setToolTip(title); // если title это QString, то еще один СП
appendAction(a); // передаем управление смартпойнетром на a
addDockWidget(Qt::TopDockWidgetArea, dw); // передаем управление смартпойнетромreturn dw; // возвращаем СП
то ты прекрасно знаешь, что у тебя происходит, у тебя неплохой подход и т.п. Когда точно такой же код пишет любой твой оппонент, они — тупые криворукие некомпетентные ленивые уроды, ага-ага
M>>Более того, люди, которые используют СП, могут и точно знают о языке в разы больше, чем ты. S>Скорее всего да, спорить не собираюсь.
Не скорее всего да, а точно да.
S>Но вот про свой проект они знают, очевидно, на порядки меньше, чем следовало бы. Иначе не было бы столько вздохов "ах, как сложно управлять памятью, ведь так сложно знать время жизни объекта, ах...".
«Очевидно», ага. 10 лет опыта обзения с тобой говорят о том, что то, что тебе «очевидно», является лишь плодом твоей безумной фантазии. И да, памятью управлять — нетривиально. И ты лично памятью не управляешь вообще, но гонору — как-будто ты каждый бит вручную отслеживаешь.
Здравствуйте, Sheridan, Вы писали:
P>>"Об этом" — это о чем? О квалификации? S>Разговор переводишь на другую тему? показательно.
Ну, во-первых, тема где-то как-то та же (как у тебя, см. ниже), а во-вторых, мы в КСВ или погулять вышли?
S>Опыт показывает что тоже самое, но на жабе требует памяти в два-три раза больше.
Дай пример для сравнения.
S>Ну конечно же, можно плюнуть и растереть. Незначительно же. Подскажу тебе — чужие расходы всегда будут незначительными, если речь идёт о несколько более напряжной работе для их снижения.
Так ведь затраты-то несет заказчик в любом случае. Вот эта самая "несколько более", а на самом деле значительно более напряжная работа обойдется, по нижней оценке, в разы дороже, чем электроэнергия, использованное за время эксплуатации. При этом, к гадалке не ходи, сдвинутся сроки. А в это время конкуренты запустят аналогичный сервис, захватят рынок, и ты не сможешь отбить свои затраты.
S>Вот именно поэтому надо сразу писать на нативе, а не на всяком дерьме и нанимать программистов, а не студентов. И тогда главным конкурентом будешь ты, потому как сможешь пускать заработанное на развитие, а не на закупку новых серверов.
Но владельцу мозга такой саморемонт обходится весьма недешево.
S>Аврал на два месяца по 12-15 часов? Руководителя расстрелять.
В том случае примерно по этому сценарию оно и пошло. Разумеется, расстреливать никого не стали, но сменили человека где-то наверху. А тот привел с собой команду управленцев, среди которых оказались весьма грамотные. В общем, порядок навели. Я тогда на совещания чаще раза в неделю не ходил.
S>Так же хочу себе сказать, что очень зря ты не спал и так помногу работал.
Тогда не все от меня зависело. И был я тогда сильно глупее моложе. Надеялся, что проскочу.
S>>>>>>>Очень приблизительно как то так. P>>То есть твое это "очень приблизительно" означать может все, что угодно? Даже "совсем не так", я правильно понял? S>Совсем не так.
Вот видишь, а мне пенял про смену темы. Я ж говорил, что КСВ.
S>Ну я так и понял, что ты выбираешь шарп в даннм случае потому как уже есть готовый код. Был бы готовый код на с++, ты выбрал бы с++.
Исхожу из реалий. Думаю, что если бы мне пришлось начинать с нуля, я в наших условиях взял бы Шарп. В других, возможно, плюсы. В третьих, может быть, вообще Питон. А может быть, удобнее купить компонент на стороне. Все зависит от упомянутых мною реалий.
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
S>>Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно. F>Если тебе так проще, то ладно, считай что я обиделся.
Мне не проще и не сложнее. Мне пофиг, решение твоё.
Здравствуйте, Sheridan, Вы писали:
S>Мне не проще и не сложнее. Мне пофиг, решение твоё.
Да неужели? Так уж и пофиг?
F>Очевидно для чьего-то воспаленного сознания. S>Ты так обиделся, как будто причисляешь себя к вышеописанным разработчикам... Или таки причисляешь?
F>Я себя причисляю к тем, кто подбирает инструмент по задаче. А когда появляются шарлатаны, которые скандируют, что смартпоинтеры и сборщики это зло, и думают, что есть только два мнения — их и не правильное, это несколько раздражает, только и всего. Какие тут могут быть обиды. S>Ясно. Таки причисляешь, раз обиделся, ибо по тексту обиду явно видно.
Ага, пофиг ему .
И кстати, могу я считать, что на изначальный вопрос у тебя ответа нет и ты просто тролль?
Здравствуйте, Sheridan, Вы писали:
F>>именно так. плюнуть и растереть. S>Еще бы. Не ваши же. С вашей стороны птичка вылетела, можно умывать руки.
остальные затраты незначительны, если делать всё грамотно, а не, как ты.
S>Аренда? Нахер, нахер. Предпочитаю своё.
т.е. на ниве кодинга лажать тебе надоело, решил облажаться по администрированию и управлению?
молодец, у тебя получилось.
сколько раз в день тебе говорят "вон из профессии"?
Здравствуйте, dimgel, Вы писали:
D>Нет. Должно быть что-то более низкоуровневое, максимально приближенное к хранящейся модели данных
Вот LINQ как раз инструмент для создания таких, максимально приближенных. Только вот, сдается мне, асилить этот самый максимально приближенный провайдер в полном объеме не способно 99% программистов.
Здравствуйте, Sheridan, Вы писали: S>Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят.
Отсутствие утечек свойственно любому точному GC, даже самому тупому.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>Ты не в ту сторону экстраполировал. Это все из-за неверного предположения, что человек в среднем лучше сделает план с помощью хинтов, чем оптимизатор. Для взрослых субд это не так.
Я бы даже более радикально выразился: чтобы составить план лучше оптимизатора, надо обладать недюжинными знаниями о том, как внутри работает движок БД, и что еще этот движок будет делать одновременно с запросом.
В этом плане проще написать ассемблерный код, который будет работать быстрее, чем сгенерированный компилятором. Причем до сих пор есть применения такому коду — см. SnappyCam, софтина, критичные части которой были написаны на ассемблере (для ARM, конечно), и работали настолько быстрее, что Apple предпочли попросту купить целиком всю контору (состоящую из единственного разработчика, хаха) за суровые деньги, чем повторять решение.
Здравствуйте, Sinclair, Вы писали:
S>>Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят. S>Отсутствие утечек свойственно любому точному GC, даже самому тупому.
В GC тоже можно устроить формальную утечку, точно по той же причине по которой делаются утечки без GC — по невнимательности. Просто забыв про какой либо reference который держит за ниточку здоровенное дерево зависимостей.
S>>>Ну конечно же. Православный ГЦ истинно безошибочен и правоверно свят. S>>Отсутствие утечек свойственно любому точному GC, даже самому тупому.
CC>В GC тоже можно устроить формальную утечку, точно по той же причине по которой делаются утечки без GC — по невнимательности. Просто забыв про какой либо reference который держит за ниточку здоровенное дерево зависимостей.
Формально там все происходит из-за попыток обмануть GC Но в итоге так и получается: данные в памяти накапливаются неограниченно из-за неподчищенных ссылок по разным процессам.
Здравствуйте, CreatorCray, Вы писали:
CC>В GC тоже можно устроить формальную утечку, точно по той же причине по которой делаются утечки без GC — по невнимательности. Просто забыв про какой либо reference который держит за ниточку здоровенное дерево зависимостей.
Ну, это будет не совсем утечка. Если на данные ссылаются — то они кому-нибудь нужны
Я к тому, что в классике мы запросто можем оказаться в ситуации, когда в памяти нет ни одного указателя на неосвобождённые данные, т.е. у нас нет даже теоретической возможности сделать delete.
Хотя ситуации с неожиданным корнем, конечно же, тоже имеют место.
Особенно ужасными, на мой взгляд, являются грабли с подпиской на события. Тот факт, что обработчик события от короткоживущего объекта, расположенный в долгоживущем объекте, удерживает от сборки event target, является крайне контринтуитивным.
Вообще ситуация, когда это — именно то, что нам нужно, в жизни бывает очень редко.
Поэтому странно, что в дотнете не предусмотрели встроенный класс weak event.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Философ, Вы писали:
vsb>Это плохой выбор. VM это тормоза и ненадёжность. Плюс — очень мало доступной памяти.
очень странный набор утверждений. виртуализация была еще во времена большого железа IBM. это на ранних персоналках виртуализация не имела смысла, ибо не было ни памяти, ни дискового пространства, ни ЦП. но сейчас выделять целую рабочую станцию (даже не сервер) под одну ось -- это жоподробительно. потому что памяти реально больше, чем нужно одному экземляру ос, зато есть потребность запускать больше одной оси одновременно.
собственно, в винде есть нативные виртуальные машины с ихним же манагером
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, TK, Вы писали:
BDA>Кстати, вопрос на засыпку: какой объем виртуальной памяти доступен процессу в 32-битной Windows XP? НИКТО ЕЩЕ НЕ ОТВЕТИЛ ПРАВИЛЬНО НА МОЕЙ ПАМЯТИ. BDA>Кто Рихтера не читал, те отвечают 2 или 4 гига. Кто читал — говорят 3. Правильный ответ — у тебя д енег на такой компьютер не хватит, чтобы лимит исчерпать.
вы сами путаете виртуальную память с физической. 16 TB дискового пространства под своп (а это и есть лимит виртуальной памяти на 32 битных системах) стоят освежающе дешево. тем более, что он не обязательно должен быть одним диском. и это, кстати, есть у рихтера. там даже картинки нарисованы как виртуальная память процесса отображается на виртуальное адресное пространство и как этим отображением можно управлять. вопрос -- нужно ли? это ведь даже хуже, чем сегменты в 8086. там по крайней мере их поддерживали компиляторы и потому мы имели кучу моделей памяти от tiny до huge, где в си все указатели представлялись как сегмент:смещение, но эта кухня была скрыта от программиста и ему были доступы блоки памяти больше чем 64 кб.
кстати, процессу доступо не только его адресное пространство, но и соседних тоже. через API. и еще: никто не мешает написать драйвер, который позволит преодолеть лимит виртуальной памяти, предоставляя свое API, чтобы мапить диск на адресное пространство процесса. при желании можно использовать не 64 бит адресацию (как в win32 api), а хоть 512 бит или даже 2014. вопрос: на хрена? практический интерес представляет сколько памяти мы можем выделить одним куском. на 32 бит винде это порядка 1.5 гб.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
