Re[25]: доведение ad absurdum
От: Pavel Dvorkin Россия  
Дата: 14.10.09 11:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>За оба — разработчика уволить. Здесь мы видим нарушение транзитивности конструкторов.


Слушай, ты наконец усвоишь одну простую вещь ? Я привожу демонстрационный пример. Он только для демонстрации предназначен, и только того, о чем речь идет. Специально для этой цели сделан. Ни на что большее он не претендует и никакие иные требования к нему не предъявляются. Неужели это не понятно ?

PD>>Остальное skipped, ввиду того, что ты ушел в сторону. Вопрос не в том, как именно делать Reverse и какие тут extension (это пиши как хочешь), а в том. что не может компилятор за тебя этот код оптимизировать. Я же ясно сказал — ad absurdum. Пример не для того сделан, чтобы его улучшать (это я и сам бы мог), а просто для того, чтобы показать тебе еще раз твою ошибку в утверждении , что компилятор сможет сам все оптимизировать.

S>Я не делал такого утверждения.

Ну-ну. Ладно, пусть желающие сами читают твои постинги, там ясно сказано, что ты утверждаешь. Мне лень искать и цитировать.

>Я делал совсем другое утверждение. Что характерно, все твои примеры подтверждают мои тезисы и опровергают твои. За что большое спасибо.


Ну да, проще всего заявить голословно что-нибудь. Если аргументов нет — это тоже решение.
With best regards
Pavel Dvorkin
Re[23]: доведение ad absurdum
От: Pavel Dvorkin Россия  
Дата: 14.10.09 11:11
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Есть такие компиляторы, в которых оптимизатор — программируемый. Разработчики библиотек могут посказывать компилятору, какие выражения и как можно упрощать. Например, можно создать правило, что list.reverse().reverse() == list — вуаля, избавились от двух ненужных вызовов и двух лишних копий списка.


Хм. Из того, что list.reverse().reverse() == list не ясно все же, как быть, если мне нужен просто list.reverse(). Тут подсказать не удастся вроде бы, так ?


Glasgow Haskell Compiler — как раз такой компилятор, и в важных библиотеках этим пользуются.

Вполне допускаю, что это может в определенных случаях помочь. Хотя все же для традиционных компиляторов это не делается. Но дело даже не в этом. Если ты начнешь подсказки компилятору делать, то ты тем самым переложишь свою работу в другое место. Иными словами, кое-что ты не запрограммируешь в коде, а запрограммируешь как правило для компилятора. Может, это и упрощает работу иногда.
With best regards
Pavel Dvorkin
Re[24]: еще один пример
От: Pavel Dvorkin Россия  
Дата: 14.10.09 11:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здесь речь именно о том. Ты вспомни контекст разговора — речь шла про туплы и про способы возврата нескольких аргументов.


Речь в нашем треде давно уже про это не идет. Речь идет о промежуточных переменных и вызове конструкторов для этого. И ты это прекрасно знаешь.

S>Я тебе продемонстрировал причины, по которым предлагаемые тобой варианты "записи на гипотетическом языке" не стоит делать эквивалетными.


S>Тогда ты сел на своего любимого конька и начал рассуждать про эффективность программ на несуществующем языке.


S>В принципе, абсурд начался уже тогда — потому как на несуществующем языке никакой эффективности у программ, понятное дело, быть не может.


Демагогия. Мы перешли давно на С++. И до поры до времени ты обсуждал именно мои С++ реализации всех трех точек. Тоггда это тебя почему-то не волновало, и про туплы ты уже не вспоминал. А сейчас решил вспомнить, поскольку зашел в тупик.

S>Зачем это всё? Чтобы только уйти от обсуждения основной темы?


Опять демагогия. Если уж ты хотел не уходить от основной темы, надо было предложить сразу либо не обсуждать эффективность в вопросе вложенных преобразований. Сразу. Я бы тогда и не стал продолжать. А заявлять это сейчас поздно — как говорят дети, играющие в футбол — "заиграно". Иными словами, после того, как мяч уже ввели от ворот, не обсуждают, нужно ли назначать угловой.

S>2. Нас не интересует в данном контексте общий случай алгоритмической оптимизации. Всё, что мы обсуждаем — способность компилятора устранить конструирование временных объектах при возврате нескольких значений.


А как же туплы ? Ты же именно их и хочешь только обсуждать ? А продолжаешь тему оптимизации.


S>По прежнему не понимаю, почему нельзя написать их 0 раз, сэкономив время себе, компилятору, и процессору.


А, прекрасно. Значит, N раз все же писать не буду. Один раз напишу, тут же пойму, исправлюсь, и больше писать не буду.
Ответ — если соображу вовремя — напишу 0 раз. Сразу без промежуточной переменной. Если не соображу — написав, нажму несколько раз Del, BackSpace, Shift-Ctrl-L и поправлю. Тебе надо подробно описать, как именно я код редактирую ?

PD>>Так,ясно. Что я пишу и что не пишу — это один вопрос. А вот насчет того, что профайлер, по твоему мнению, может потом сопоставить профилируемый код со строчками текста, мы кажется, разобрались.

S>Ок, хорошо. Пусть не может потом профайлер сопоставить строчки кода.

Ну слава богу! Наконец-то ты сумел признать свою неправоту. Прогресс явный!

>Профайлер зато единственный, кто может сопоставить эффективность двух решений.


Хм... Да, если написать вариант с моими точками, то сможет. А вот в задаче с массивом-списком — я и сам могу сопоставить. Без профайлера и даже без запуска. Потому как нечего из Новосибирска в Омск через Владивосток, Нью-Йорк и Москву лететь. Тут и так все ясно. И даже если этот полет ты совершишь один раз в жизни, и даже если тебе на деньги и время наплевать, то все равно кроме как глупостью этот полет никак назвать нельзя.

PD>>Не может все-таки. Возразить тебе не удалось, решил поэтому на меня перевести, этот твой прием я хорошо знаю. Не получится. Констатирую : рассуждения твои о возможности профайлера определить, какие строки исполнялись, а какие нет, надо признать неудовлетворительными. В результате падают и все твои прочие выводы, на этой основе сделанные.

S>Отлично. Увёл, значит, разговор в сторону. Теперь то, повлияют ли лишние строчки boilerplate-кода, написанные вручную, на скорость работы программы, зависит только от того, сможет ли профайлер сопоставить им какие-либо данные. Ну-ну. Удачи.

Разговор именно ты и пытался увести. А теперь начинаешь опять свою любимую игру — приписывать мне то, чего я не говорил, и на этом основании заниматься демагогией.

PD>>Оптимизировал я не свой код, а он был на С, так что не могло там быть неявных преобразований. Да и не все ли равно тебе, как я оптимизировал ? Ты лучше на вопрос ответь — нужно ли оптимизировать, если удастся выиграть 1% ? Опять пытаешься уйти от вопроса.

S>В большинстве случаев — не нужно. 1% — это типичная погрешность измерений. Допускаю, что где-то, в отдельных случаях, это может играть какую-то роль.
S>Но опять же, получается, что полезность возврата одним махом множества значений теперь зависит только от того, надо ли оптимизировать 1%. Ну не бред ли?

Не бред, а фальшь. Твоя. Вопрос об том, надо ли оптимизировать 1%, я поставил безотносительно от чего бы то ни было. Просто — надо или нет. И множества значений (туплы) здесь абсолютно ни при чем.

Вот мои слова

PD>Да, с таким подходом только и делать серьезную работу. А мне , например, заказчик выразил благодарность за то, что я оптимизировал код на 1%. И оптимизировал я не то место, где 80% — там я ничего сделать не мог, а именно то, что 2% требовало (суммарно), а теперь 1%.

PD>Не так уж это мало — 1%. Когда ПО работает не на одном компьютере, а на сотнях

И как с этим соотносится "полезность возврата одним махом множества значений теперь зависит только от того, надо ли оптимизировать 1%" ? Где бузина и где дядька ?
With best regards
Pavel Dvorkin
Re[26]: доведение ad absurdum
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.10.09 11:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, ты наконец усвоишь одну простую вещь ? Я привожу демонстрационный пример. Он только для демонстрации предназначен, и только того, о чем речь идет. Специально для этой цели сделан. Ни на что большее он не претендует и никакие иные требования к нему не предъявляются. Неужели это не понятно ?
Я поясню: пока что компьютеры неспособны "перехитрить" человека. Поэтому всегда можно придумать "демонстрационный" контрпример.
Нас не интересует способность компилятора оптимизировать любые зловредно устроенные программы.
Нас интересует способность компилятора оптимизировать типичные решения, которые удобно писать людям.
Ты можешь писать сколько угодно примеров идиотского кода, который занимается нагреванием воздуха. Они ровным счётом ничего не доказывают и не опровергают.

Я тебе пишу реалистичные примеры того, какой код я хочу получать. Ты мне пытаешься доказать, что такая запись вредна из-за потенциальной неоптимальности. При этом маешься совершеннейшей дурью.
PD>Ну да, проще всего заявить голословно что-нибудь. Если аргументов нет — это тоже решение.
Я уже привёл массу аргументов, по буквам разжёвывая возможное поведение компилятора в различных сценариях.
Ты мне всё время приводишь примеры того, как можно
а) написать много лишнего кода, который всё равно выкинет компилятор
б) написать много лишнего кода, который бы всё равно был выкинут компилятором, и выкинуть его вручную
в) написать много лишнего кода, который компилятор не сможет выкинуть
г) написать много лишнего кода, который компилятор не сможет выкинуть, и выкинуть его вручную.

Ну так эти все примеры только подтверждают мою точку зрения: лучше всего — не писать лишнего кода. И только если лишний целевой будет сгенерирован компилятором, озаботиться исправлением исходника так, чтобы этого не происходило.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: еще один пример
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.10.09 12:14
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Речь в нашем треде давно уже про это не идет. Речь идет о промежуточных переменных и вызове конструкторов для этого. И ты это прекрасно знаешь.

Нет, Павел. Не надо тут пытаться поймать меня на знании деталей С++. Я понимаю, что это твоя любимая тема, но обсуждаем мы не её.

PD>Демагогия. Мы перешли давно на С++. И до поры до времени ты обсуждал именно мои С++ реализации всех трех точек.

Поясняю: я пытался объяснить суть происходящего на понятном тебе языке. Я не виноват, что ты стал приводить примеры именно на С++.

И не я виноват, что именно ты привёл примеры, которые даже при компиляции на С++ подтверждают именно мою точку зрения.

Тебе пришлось сильно постараться, чтобы придумать пример, который (как ты думаешь) заведомо не получится оптимизировать компилятором.

PD>Опять демагогия. Если уж ты хотел не уходить от основной темы, надо было предложить сразу либо не обсуждать эффективность в вопросе вложенных преобразований. Сразу. Я бы тогда и не стал продолжать. А заявлять это сейчас поздно — как говорят дети, играющие в футбол — "заиграно". Иными словами, после того, как мяч уже ввели от ворот, не обсуждают, нужно ли назначать угловой.

И футбол тоже не то, про что эта тема. Поэтому мы не будем ставить полезность возможности возврата нескольких значений от того, обсуждают ли назначение углового после ввода мяча от ворот.

PD>А как же туплы ? Ты же именно их и хочешь только обсуждать ? А продолжаешь тему оптимизации.

Это и есть про туплы. Сначала ты предложил вместо туплов сделать возврат кортежа синтаксическим сахаром для &-параметров. Я тебе подробно объяснил, в чём тут грабли.
Тогда ты взялся за возврат туплов со стороны "оптимизации", причём как обычно — приводя примеры, которые опровергают твою же точку зрения.

PD>А, прекрасно. Значит, N раз все же писать не буду. Один раз напишу, тут же пойму, исправлюсь, и больше писать не буду.

PD>Ответ — если соображу вовремя — напишу 0 раз. Сразу без промежуточной переменной. Если не соображу — написав, нажму несколько раз Del, BackSpace, Shift-Ctrl-L и поправлю. Тебе надо подробно описать, как именно я код редактирую ?
Нет, не надо. Всё понятно и так.

PD>Хм... Да, если написать вариант с моими точками, то сможет. А вот в задаче с массивом-списком — я и сам могу сопоставить.

Напомни, пожалуйста, какое отношение к туплам имеет задача с массивом-списком? Ну или, хотя бы, какое отношение она имеет к неявным преобразованиям?

PD>Без профайлера и даже без запуска. Потому как нечего из Новосибирска в Омск через Владивосток, Нью-Йорк и Москву лететь. Тут и так все ясно. И даже если этот полет ты совершишь один раз в жизни, и даже если тебе на деньги и время наплевать, то все равно кроме как глупостью этот полет никак назвать нельзя.

Но именно ты почему-то начал писать именно такой полёт. Посмотри в свой код — у тебя там явно сказано "лететь через Array". Подумай — зачем ты это написал? Как на самом деле выглядит код обращения такого списка — пусть такой, где никто не задумался об оптимизации заранее.
А то ведешь себя тут, как суровые сибирские мужики с японской бензопилой.

PD>Не бред, а фальшь. Твоя. Вопрос об том, надо ли оптимизировать 1%, я поставил безотносительно от чего бы то ни было. Просто — надо или нет. И множества значений (туплы) здесь абсолютно ни при чем.

Ок, давай тогда я спрошу безотносительно всего: нужно ли снимать кожуру с яблока? А если не ответишь — будем считать, что все твои выводы в этой ветке неверны. Раз уж пошла такая пьянка, задавать не относящиеся к делу вопросы.

PD>И как с этим соотносится "полезность возврата одним махом множества значений теперь зависит только от того, надо ли оптимизировать 1%" ? Где бузина и где дядька ?

Вот и я удивляюсь — начали с туплов, а закончили, как всегда, твоим 1%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: доведение ad absurdum
От: Pavel Dvorkin Россия  
Дата: 14.10.09 12:29
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Слушай, ты наконец усвоишь одну простую вещь ? Я привожу демонстрационный пример. Он только для демонстрации предназначен, и только того, о чем речь идет. Специально для этой цели сделан. Ни на что большее он не претендует и никакие иные требования к нему не предъявляются. Неужели это не понятно ?
S>Я поясню: пока что компьютеры неспособны "перехитрить" человека. Поэтому всегда можно придумать "демонстрационный" контрпример.

И то хорошо, что ты это признал. Таким образом, по крайней мере для этого случая ты мою правоту признал. Прогресс.

S>Нас не интересует способность компилятора оптимизировать любые зловредно устроенные программы.


Демагогия. Никто ничего зловредного не обсуждал.

S>Нас интересует способность компилятора оптимизировать типичные решения, которые удобно писать людям.

S>Ты можешь писать сколько угодно примеров идиотского кода, который занимается нагреванием воздуха.

Демагогия.


S>Ты мне всё время приводишь примеры того, как можно

S>а) написать много лишнего кода, который всё равно выкинет компилятор

Не было.

S>б) написать много лишнего кода, который бы всё равно был выкинут компилятором, и выкинуть его вручную


Не было. Я как раз предлагал его не писать.

S>в) написать много лишнего кода, который компилятор не сможет выкинуть


Тоже ложь. Я как раз и предлагал его не писать.

S>г) написать много лишнего кода, который компилятор не сможет выкинуть, и выкинуть его вручную.


и опять ложь.

А правда лишь одна — я говорю, что при анализе кода в применении к вопросу о явных и неявных преобразованиях может выясниться, что кое-что делать совсем не надо, а поэтому не надо и писать. И это легче будет обнаружить при явных, нежели при неявных преобразованиях.
А мне в ответ — все, что угодно. Ладно. Оставайся при своем мнении.
With best regards
Pavel Dvorkin
Re[13]: Inline records
От: Юрий Жмеренецкий ICQ 380412032
Дата: 14.10.09 12:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Юрий Жмеренецкий, Вы писали:


ЮЖ>>Какие? Поддержка IDE?

S>Нет. В императивном языке мне нравится идея не просто "возвращать кортеж", или "возвращать кортеж в анонимный кортеж, описанный по месту", а возможность "указывать, куда девать результаты".
S>Ну вот если в "обычном" коде мы пишем
S>
S>var i = SomeFunc(a, b);
S>GlobalSettings.Instance.Property = SomeOtherFunc(a, b);
S>

S>то как бы хочется аналогичных мощностей для
S>
S>(var i, GlobalSettings.Instance.Property) = CombinedFunc(a, b);
S>


Хм... Но это как раз ортогонально именам членов тупла при декларации функции.

ЮЖ>>
(int x, int y : x < y) F();

S>Давайте отделять структурные результаты и постусловия.

У меня присутствует ощущение того, что если постусловие в отношении функции для такого кортежа (особенно если его члены именованы) равное 'true' (т.е. вообще любой набор значений является допустимым), то это следствие нарушения SRP. Это далеко не стопроцентный критерий, разумеется, но даже упомянутая выше функция IntDivide имеет постусловия в отношении результата 'в целом', т.е. фактически имеется связь между компонентами (в смысле cohesion).

С другой стороны я вижу сценарии, когда инварианты на кортеж не являются значимыми в точке использования, но это будут скорее утилитарные вещи, для которых достаточно индекснего доступа для отдельных элементов. Но в этом случае такой синтаксис:

(double x, double y) = GetXY()


не является необходимым, достаточно доступа к первому элементу и к списку оставшихся.

S>В том смысле, что эта фича, имхо, полностью ортогональна кортежам.

S>Сначала надо научиться возвращать
S>
S>int x : x >= 10 F();
S>

S>А уже потом подумать про кортежи.


ЮЖ>>Здесь и до зависимых типов недалеко... Можно разрешить использование 'this' и в том числе для использования при проверки предусловий для аргументов + состояние объекта, т.е.

ЮЖ>>
ЮЖ>>void Container::Remove(Key k : !this.Empty && this.Exists(k))
ЮЖ>>

S>Ну вот — видишь, здесь никаких кортежей нет, а предусловия какбы есть.

Почему нет? кортеж (Key, Container) + оочень специфический "конструктор".

ЮЖ>>Можно пойти еще дальше: операция Remove принимает (как бы) тупл из двух элементов — (Container, Key):

ЮЖ>>
ЮЖ>>void Container::Remove(Container this_ : !this_.Empty, Key k : this_.Exists(k))
ЮЖ>>

S>Можно, а зачем?

Эта запись предназначена для объяснения того, как должен себя вести компилятор.


ЮЖ>>С 'Exists(k)' так просто не получится — но есть два варианта: самый простой — автоматически добавлять runtime проверку (Assert или что-то еще), второй — то же что и первый, + нужно исходить из того факта, что помимо совпадения произвольного ключа возможен случай с передачей в Remove значения, полученного от этого же экземпляра контейнера (или эквивалентного находящемуся в нем) — если между этими событиями модификация контейнера не производилась — есть 100% гарантия нахождения значения с указанным ключом в контейнере (можно анализировать и более сложные случаи). В этом случае проверка не нужна. Правда в этом случае компилятор должен поддерживать аннотирование любых объектов. Вобщем получаются predicate types.

S>Получится очень просто: либо компилятор статически может проверить гарантию наличия значения по ключу, либо пользователь обязан явно описать уточнение.
S>То есть вот такое примерно должно иметь место:
S>
S>public void Test(Dictionary<string, int> data)
S>{
S>  data["test"] = GetExternalInt(); // тип data неявно сменился
  
S>  int a = data["test"]; // компилятор пропускает, потому что там точно лежит int
  
S>  int b = data["fail"]; // компилятор ругается, потому что нет гарантии наличия ключа
  
S>  int? c = data["fail"]; // компилятор спокоен, потому что мы явно предусмотрели отсутствие ключа

S>  int d = 0;  
S>  if (data.Exists("fail")) // тип data неявно сменился 
S>    int d = data["fail"]; // компилятор спокоен, потому что в этой ветке есть гарантия наличия ключа
S>}
S>


Что-то типа этого. Теоритически можно заставить работать и такое:

string s = ...;
data[s]  = ...

Y y(s); // s 'ушла'
string s2 = y.bar(); // ... и вернулась, т.е. s == s2 

int n = data[s2]; // ok


Здесь в постусловии конструктора Y может присутствовать предикат вида this.bar() == аргумент_конструктора, + компилятор/анализатор должен быть уверен в том что содержимое data не изменялось во время 'путешествия' s, либо эти изменения не повлияли на нее. Правда в пределе может возникнуть ситуация, когда время компиляции стремится к бесконечности. Здесь логичнее плясать от статистики по выявленным дефектам и в первую очередь пытаться переложить на плечи компилятора работу по выявлению наиболее частых. Но это слабореализуемо...

ЮЖ>>Если же не рассматривать вышесказанное, то имхо, идея именования элементов туплов вполне жизнеспособна, но озвученные аналогии с именами для аргументов начинают немного хромать в присутствии аргументов по умолчанию (для полноты картины):

ЮЖ>>Но аналогия для возвращаемых значений тут неприменима. Да, можно игнорировать некоторые элементы, но активное использование такой 'фичи' больше похоже на симптомы проблем с дизайном.
S>Не вижу никакой хромоты.

Использовании значения по умолчанию — такие значения все же будут использованы для дальнейших вычислений. Неиспользование результата — скорее должно приводить к элиминации соответствующих вычислений, т.е. по сути — ленивые вычисления. Игнорирование здесь мало подходит, т.к. в этом случае не получится игнорировать возможные побочные эффекты, + возможные затраты на вычисление.
Re[26]: еще один пример
От: Pavel Dvorkin Россия  
Дата: 14.10.09 12:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Речь в нашем треде давно уже про это не идет. Речь идет о промежуточных переменных и вызове конструкторов для этого. И ты это прекрасно знаешь.

S>Нет, Павел. Не надо тут пытаться поймать меня на знании деталей С++. Я понимаю, что это твоя любимая тема, но обсуждаем мы не её.

Ловить тебя мне совсем не интересно, а про детали С++ (кроме того, как и можно ли вообще соотнести строчки С++ и команды), вроде речи вообще не было. Примеры мои — деталям не посвящены. И до сих пор тебя это не тревожило. Что так вдруг ?

S>Поясняю: я пытался объяснить суть происходящего на понятном тебе языке. Я не виноват, что ты стал приводить примеры именно на С++.


Да бога ради, мог привести на C# или Java. Я выбрал то, что мне ближе, возражений об языке не последовало.

S>И не я виноват, что именно ты привёл примеры, которые даже при компиляции на С++ подтверждают именно мою точку зрения.


Ай-яй-яй!
Ты же сам утверждаешь, что без профайлера ничего не докажешь. А мы даже и не компилировали ни один пример, более того, и не написали его как следует. Ты сам себе противоречишь — ты уже без всякого профайлинга доказал, что твой подход лучше. Я это мог бы себе позволить, но ты-то как ?

Вот то-то и оно. Психология. Типичная оговорка по Фрейду.

S>Тебе пришлось сильно постараться, чтобы придумать пример, который (как ты думаешь) заведомо не получится оптимизировать компилятором.


Я его придумывал секунд 30, пока ходил в курилку. Стараться тут нечего — пока домой доеду, могу еще много других придумать. Но существенен факт — ты все же признал, что не удастся ему оптимизировать. ну и это уже хорошо.

S>И футбол тоже не то, про что эта тема. Поэтому мы не будем ставить полезность возможности возврата нескольких значений от того, обсуждают ли назначение углового после ввода мяча от ворот.


Заиграно. Ели хочешь обсуждать опять туплы — перейди в подветку, где продолжают их обсуждать.

S>Тогда ты взялся за возврат туплов со стороны "оптимизации", причём как обычно — приводя примеры, которые опровергают твою же точку зрения.


То они опровергают, то все же не получится оптимизировать. Пойди пойми.

PD>>А, прекрасно. Значит, N раз все же писать не буду. Один раз напишу, тут же пойму, исправлюсь, и больше писать не буду.

PD>>Ответ — если соображу вовремя — напишу 0 раз. Сразу без промежуточной переменной. Если не соображу — написав, нажму несколько раз Del, BackSpace, Shift-Ctrl-L и поправлю. Тебе надо подробно описать, как именно я код редактирую ?
S>Нет, не надо. Всё понятно и так.

Слава богу

PD>>Хм... Да, если написать вариант с моими точками, то сможет. А вот в задаче с массивом-списком — я и сам могу сопоставить.

S>Напомни, пожалуйста, какое отношение к туплам имеет задача с массивом-списком? Ну или, хотя бы, какое отношение она имеет к неявным преобразованиям?

Не юли. Раньше надо было о туплах говорить. А то два дня уже обсуждаем совсем другое, а теперь вспомнил...

PD>>Без профайлера и даже без запуска. Потому как нечего из Новосибирска в Омск через Владивосток, Нью-Йорк и Москву лететь. Тут и так все ясно. И даже если этот полет ты совершишь один раз в жизни, и даже если тебе на деньги и время наплевать, то все равно кроме как глупостью этот полет никак назвать нельзя.

S>Но именно ты почему-то начал писать именно такой полёт. Посмотри в свой код — у тебя там явно сказано "лететь через Array". Подумай — зачем ты это написал? Как на самом деле выглядит код обращения такого списка — пусть такой, где никто не задумался об оптимизации заранее.

Нет. Это не я написал. Я такие вещи писать не буду. Это я продемонстрировал как любители неявных преобразований могут лишнюю бессмысленную работу делать. Иными словами, это я объяснил, как эти авторы летают иногда из Н-ска в Омск.


PD>>Не бред, а фальшь. Твоя. Вопрос об том, надо ли оптимизировать 1%, я поставил безотносительно от чего бы то ни было. Просто — надо или нет. И множества значений (туплы) здесь абсолютно ни при чем.

S>Ок, давай тогда я спрошу безотносительно всего: нужно ли снимать кожуру с яблока? А если не ответишь — будем считать, что все твои выводы в этой ветке неверны. Раз уж пошла такая пьянка, задавать не относящиеся к делу вопросы.

Раньше думать надо было.

PD>Оптимизировал я не свой код, а он был на С, так что не могло там быть неявных преобразований. Да и не все ли равно тебе, как я оптимизировал ? Ты лучше на вопрос ответь — нужно ли оптимизировать, если удастся выиграть 1% ? Опять пытаешься уйти от вопроса.

S>В большинстве случаев — не нужно. 1% — это типичная погрешность измерений. Допускаю, что где-то, в отдельных случаях, это может играть какую-то роль. Но опять же, получается, что полезность возврата одним махом множества значений теперь зависит только от того, надо ли оптимизировать 1%. Ну не бред ли?

Писал такое ? Не вторую, а первую фразу ? Писал. То есть согласился ее обсуждать. А теперь начал заявлять, что это, мол, к делу не оносится. Да, прямо не относится. Но раз уж так — надо было сразу ответить. А взявшись отвечать по существу — не говори, что не относится. Поезд ушел. Или самолет. Из Н-ска в Омск. Через Нью-Йорк
With best regards
Pavel Dvorkin
Re[28]: доведение ad absurdum
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.10.09 13:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Демагогия. Никто ничего зловредного не обсуждал.
Цитирую:

Linked2List reverseList = Linked2List(Array(sourceList));

Кто это написал? Я что ли? Весь смысл этой программы — не дать компилятору её соптимизировать.

S>>Ты можешь писать сколько угодно примеров идиотского кода, который занимается нагреванием воздуха.

PD>Демагогия.
Опять цитирую:

Linked2List reverseList = Linked2List(Array(sourceList));

Этот код занимается нагреванием воздуха.

S>>а) написать много лишнего кода, который всё равно выкинет компилятор

PD>Не было.
Цитирую:
IPoint ip;
GetPointByRef(ip);
FPoint fp1 = ip;
FPoint3D fp3D = fp1;

Весь лишний код будет устранён компилятором (если не предпринимать специальных усилий).
S>>б) написать много лишнего кода, который бы всё равно был выкинут компилятором, и выкинуть его вручную
PD>Не было. Я как раз предлагал его не писать.
Цитирую:

А вот если бы я написал

IPoint ip;
GetPointByRef(ip);
FPoint fp1 = ip;
FPoint3D fp3D = fp1;


то я бы сразу задал себе вопрос — зачем я тут ерундой занимаюсь!

IPoint ip;
GetPointByRef(ip);
FPoint3D fp3D = ip;

Самостоятельно написал лишнюю конверсию IPoint->FPoint->FPoint3d, самостоятельно её выбросил.

S>>в) написать много лишнего кода, который компилятор не сможет выкинуть

PD>Тоже ложь. Я как раз и предлагал его не писать.
Цитирую:
Linked2List reverseList = Linked2List(Array(sourceList));

Вот этот Array — он здесь зачем? Ясно: для доказательства того, что компилятор не может его выбросить. Здесь нет ни одного неявного преобразования, зато есть явная инструкция "делай медленно".
S>>г) написать много лишнего кода, который компилятор не сможет выкинуть, и выкинуть его вручную.
PD>и опять ложь.
Снова цитирую:

а их конкатенация применительно к данной задаче — абсурдна. Потому что задача решается намного проще. Без всякого выкладывания в массив.

То есть сам написал выкладывание в массив, и сам же талантливо от него избавился. Браво, аплодирую стоя.

PD>А правда лишь одна — я говорю, что при анализе кода в применении к вопросу о явных и неявных преобразованиях может выясниться, что кое-что делать совсем не надо, а поэтому не надо и писать. И это легче будет обнаружить при явных, нежели при неявных преобразованиях.

Увы, никаких аргументов в пользу именно этого утверждения приведено не было. Ни один из примеров не содержит проблемы с неявным преобразованием, которую имеет смысл решать. Даже самый абсурдный пример построен на наличии явного преобразования, которое явно занимается ерундой.

В реальной жизни оказывается, что неявные преобразования порождают проблемы намного реже, чем решают. Потенциальные проблемы производительности при неявных преобразованиях
а) редкость (мы всё ещё ждем от мега-гуру плюсов убедительного примера )
б) могут быть обнаружены профайлером
в) могут быть исправлены локальным переписыванием виновного кода — без поисков по всему проекту

PD>А мне в ответ — все, что угодно. Ладно. Оставайся при своем мнении.

И вам того же.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Inline records
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.10.09 13:31
Оценка:
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Хм... Но это как раз ортогонально именам членов тупла при декларации функции.

Это — да. Неортогональна именам "членов тупла" возможность получить в IDE подсказку о том, что куда попадает.

А сама эта фича несколько противоречит, собственно, самому туплу — тут его, в общем-то, и нет. Есть пара destinations, куда должен попасть результат.
С точки зрения CLR, к примеру, мы можем считать, что оба значения просто оказались на стеке после вызова.
А потом мы уже одно из них употребили при помощи stloc, а другое — при помощи вызова сеттера.
Ну, а _, соответственно, означает просто pop в нужном месте. Но всё это, естественно, чисто императивная ересь. Я вообще как-то сомневаюсь в её полезности в контексте ФП. Поэтому я и написал, что с планами Влада это, скорее всего, будет расходиться.

ЮЖ>У меня присутствует ощущение того, что если постусловие в отношении функции для такого кортежа (особенно если его члены именованы) равное 'true' (т.е. вообще любой набор значений является допустимым), то это следствие нарушения SRP.

Возможно — не буду спорить. Хотя не очень понятно, SRP там или нет. А какой принцип будет нарушать вырожденное постусловие на скалярный результат? Ведь в природе тоже неограниченные контракты встречаются редко.
Механика контрактов — могучая вещь, но, повторюсь, она как-то выходит за пределы туплов.

ЮЖ>Это далеко не стопроцентный критерий, разумеется, но даже упомянутая выше функция IntDivide имеет постусловия в отношении результата 'в целом', т.е. фактически имеется связь между компонентами (в смысле cohesion).

Это правда. Но даже если мы рассмотрим скалярную функцию /, то её результат связан с аргументами.

ЮЖ>С другой стороны я вижу сценарии, когда инварианты на кортеж не являются значимыми в точке использования, но это будут скорее утилитарные вещи, для которых достаточно индекснего доступа для отдельных элементов. Но в этом случае такой синтаксис:

ЮЖ>
(double x, double y) = GetXY()

ЮЖ>не является необходимым, достаточно доступа к первому элементу и к списку оставшихся.
Может, это Лисп?
Я думаю, что могут быть сценарии, которые осознанно нарушают SRP ради получения каких-то других бенефитов.

ЮЖ>Что-то типа этого. Теоритически можно заставить работать и такое:


ЮЖ>Здесь в постусловии конструктора Y может присутствовать предикат вида this.bar() == аргумент_конструктора, + компилятор/анализатор должен быть уверен в том что содержимое data не изменялось во время 'путешествия' s, либо эти изменения не повлияли на нее. Правда в пределе может возникнуть ситуация, когда время компиляции стремится к бесконечности. Здесь логичнее плясать от статистики по выявленным дефектам и в первую очередь пытаться переложить на плечи компилятора работу по выявлению наиболее частых. Но это слабореализуемо...

Не вижу Проблемы. Статистика быстро подскажет нам, что самые популярные — это NullReferenceException и IndexOutOfRangeException.
Оба, очевидно, лечатся с помощью ЗТ. Причем первый — вообще тривиальным способом, т.к. там собственно зависимости нет; всё будет работать даже на существующем фреймворке — дайте только новый компилятор и разметьте атрибутами mscorlib. Со вторым поинтереснее, но по-прежнему у нас нет NP-задачи. Точнее, мы можем выделить относительно разрешимую подзадачу.
Для начала — научиться отличать заведомо пустые коллекции от заведомо непустых; OutOfRange в 90% случаев — это обращение по индексу 0.

ЮЖ>Использовании значения по умолчанию — такие значения все же будут использованы для дальнейших вычислений.

По хорошему, они тоже должны элиминироваться. Т.е. для значений по умолчанию компилятор может построить более эффективный код.
ЮЖ>Неиспользование результата — скорее должно приводить к элиминации соответствующих вычислений, т.е. по сути — ленивые вычисления.
Опять же — при инлайнинге возможности открываются поистине бесконечные. Либо, как минимум, опять можно специализировать код функции по способам применения — не обязательно прямо-таки для каждого call site делать отдельную версию. Возможных вариантов игнорирования N результатов всего 2^N . C учётом того, что всё это возложено на JIT, нас не сдерживает code bloat во время статической компиляции.
ЮЖ>Игнорирование здесь мало подходит, т.к. в этом случае не получится игнорировать возможные побочные эффекты, + возможные затраты на вычисление.
Это если побочные эффекты есть. У Липперта, помнится, есть упоминание про то, как оптимизируется код "вокруг" побочных эффектов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Inline records
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.09 13:33
Оценка: +1
Здравствуйте, lomeo, Вы писали:


L>Как это — кортеж поддерживает структурную идентичность? Разве кортеж — это не отдельный тип?


Кортежи — да. Но для них можно просто описать набот дженерик-типов (так как имена полей у них фиксированные).
Сделать тоже самое с записями невозможно, так как у них разные имена полей.

L>
L>class Tuple2<A,B>
L>class Tuple3<A,B,C>
L>...
L>


L>В Scala — так, в Nemerle по другому?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Inline records
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.09 13:39
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, VladD2, Вы писали:


VD>>Тогда за фиг тебе С++? На С можно писать точно так же, только с большим количеством явно выраженных деталей. Ну, а раз можно обходиться, то нужно (по твоей логике)!


PD>Инкапсулирование. На С практически невозможно, разве что пародия.


Да, ну? Иди попробуй нарушить инкапсуляцию Win API.

PD>Наследование. То же.


Да, ну. Это просто сахар же. Реализуется вручную только дат.

PD>Полиморфизм. То же.


Та же фигня.

Ну, или тебе придется признать, что точно так же в языке нужны и иные расширения упрощающие жизнь.

Если ты еще не понял, то разговоры на тему зачем нужны кортежи ничем не отличаются от разговоров на тему зачем нужны классы. Просто ты предвзято относишься к проблеме.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Inline records
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 14.10.09 16:16
Оценка: 6 (1)
Здравствуйте, VladD2, Вы писали:

VD>Речь идет об включении в описание функции имен этих отдельных значений.

VD>А луа это динамически типизированный скрип в котором даже понятия такого как описание типа нет.

Стало интересно, как это может выглядеть на упомянутом выше netch80 питоне. Как-то так:

from inlinerecords import _, returnsnames

@returnsnames(ident.topicid, ident.title, ident.author)
def getmessage():
    return (3564395, 'Inline records', 'VladD2')

message = getmessage()

print message
print 'topicId=%s, title=\'%s\', author=\'%s\'' % (message.topicid, message.title, message.author)


выведет:

(3564395, 'Inline records', 'VladD2')
topicId=3564395, title='Inline records', author='VladD2'




код inlinerecords.py:

'''
Кортеж, хранящий свои элементы еще и в именованных полях.
Инстанцирование: x = inlinerecord({name1:value1, name2:value2 ..., nameN:valueN})
'''
class inlinerecord(tuple):
    def __new__(cls, dict):
        for name, value in dict.iteritems(): setattr(cls, name, value)
        return super(inlinerecord, cls).__new__(cls, dict.values())

        # все по-честному, мы также как и tuple будем неизменяемыми ;)
    def __setattr__(self, *args):
        raise TypeError("can't modify immutable instance")
    __delattr__ = __setattr__

'''
Класс-пустышка, в ответ на обращение к любому его несуществующему полю возвращает строку с именем этого поля:
print x = ident.test - выведет "test"
'''
class ident(object):
    class __metaclass__(type):
        def __getattr__(cls, attr): return attr

'''
декоратор для оборачивания функций, возвращающих кортежи с целью их замены на кортежи с именованными полями
'''
def returnsnames(*names):
    def wrapper(f):
        return lambda *args, **kwds: inlinerecord(dict(zip(names, f(*args, **kwds))))
    return wrapper

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[4]: Inline records
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.09 18:39
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Как это — кортеж поддерживает структурную идентичность? Разве кортеж — это не отдельный тип?


Смотря где. В реляционной модели запись определяется как кортеж с именованными полями, а тип записи определяется совокупностью типов ее полей и имен.

L>В Scala — так, в Nemerle по другому?


В немерле нет записей, так как нет структурной идентичности. Есть клссы, но их идентичность определяется их реализаций. По умолчанию два эземляра не равны.

За скалу не скжу, но что-то не помню там синтаксиса для записи записей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Inline records
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.09 18:46
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, VladD2, Вы писали:


VD>>Речь идет об включении в описание функции имен этих отдельных значений.

VD>>А луа это динамически типизированный скрип в котором даже понятия такого как описание типа нет.

KV>Стало интересно, как это может выглядеть на упомянутом выше netch80 питоне. Как-то так:...


Ну, так выходит, что речь идет не о типах, а о некоторой метапрограмме которая переписывает код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Inline records
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.09 18:54
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

Кстати, можно пояснить (прямо по кускам разобрать и прокоментировать) код:

class inlinerecord(tuple):
    def __new__(cls, dict):
        for name, value in dict.iteritems(): setattr(cls, name, value)
        return super(inlinerecord, cls).__new__(cls, dict.values())


Как я понимаю в питоне уже есть тип record?
Именно он возвращается?

Ну, и поддерживается ли для типа record (если он существует) структурная идентичность? Ну, когда две независимо созданные записи идентичны при условии, что идентичны значения и имена полей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Inline records
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.09 18:57
Оценка:
Здравствуйте, netch80, Вы писали:

N>Это не "докапывание до терминов", это поиск согласования. Когда ты говоришь какие-то вещи безусловно не соответствующие общепринятому пониманию,


Что не соответствует общепринятому пониманю? Что скрипты называют нетипизированными или динамически-типизированными? Или то, что все эти термины в обиходе означают одно и то же?

N>"совершенно точно имеет факт одного из двух" — или непонимание, или своя терминология ради какой-то своей цели. Но причины такого определения ты раскрывать не хочешь — ну что ж, заставить нельзя


Значит я правильно понял, что ты все же решился докопаться до термина "нетипизированный"?
Тебя устроить если вместо него использовать динамически-типизированный?

VD>> В данном случае совершенно точно имеет факт одного из двух.


N>Мимо. Впрочем, возобновлять дискуссию мне облом.


Что мимо то? Я так и не понял что ты хотел сказать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Inline records
От: Юрий Жмеренецкий ICQ 380412032
Дата: 14.10.09 19:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

ЮЖ>>У меня присутствует ощущение того, что если постусловие в отношении функции для такого кортежа (особенно если его члены именованы) равное 'true' (т.е. вообще любой набор значений является допустимым), то это следствие нарушения SRP.

S>Возможно — не буду спорить. Хотя не очень понятно, SRP там или нет.

Что-то я не то сказал. Имел ввиду другое, но в дальнейших рассуждениях появились дополнительные факторы и они пока не совсем увязались между собой.

S>А какой принцип будет нарушать вырожденное постусловие на скалярный результат? Ведь в природе тоже неограниченные контракты встречаются редко.


Никакое не нарушают. А встречаются не так уж и редко — например функция которая возвращает bool =).

S>Механика контрактов — могучая вещь, но, повторюсь, она как-то выходит за пределы туплов.


Совсем без контрактов получится аналог голой структуры, про значения которой и про взаимосвязи между которыми ничего неизвестно. Вот это мне совсем не нравится. Добавление контрактов на аргументы/состояние/возвращаемое значение в объявление функции, имхо, лучше чем в определение (особенно для постусловий), и еще лучше чем в комментарии.

ЮЖ>>Это далеко не стопроцентный критерий, разумеется, но даже упомянутая выше функция IntDivide имеет постусловия в отношении результата 'в целом', т.е. фактически имеется связь между компонентами (в смысле cohesion).

S>Это правда. Но даже если мы рассмотрим скалярную функцию /, то её результат связан с аргументами.

Безусловно, но я имел ввиду наличие как минимум двух значений, которые возвращаются в качестве результата и взаимоотношениях между ними. Впрочем, к туплам, как таковым это не относится.

ЮЖ>>С другой стороны я вижу сценарии, когда инварианты на кортеж не являются значимыми в точке использования, но это будут скорее утилитарные вещи, для которых достаточно индекснего доступа для отдельных элементов. Но в этом случае такой синтаксис:

ЮЖ>>
(double x, double y) = GetXY()

ЮЖ>>не является необходимым, достаточно доступа к первому элементу и к списку оставшихся.
S>Может, это Лисп?

Пусть будет С++, там возможность получить тупл со ссылками на все члены объекта / параметры функции весьма кстати.


S> Статистика быстро подскажет нам, что самые популярные — это NullReferenceException и IndexOutOfRangeException.


Это не дефекты — это симптомы. Дефект может быть совсем в другом месте.

S>Оба, очевидно, лечатся с помощью ЗТ. Причем первый — вообще тривиальным способом, т.к. там собственно зависимости нет; всё будет работать даже на существующем фреймворке — дайте только новый компилятор и разметьте атрибутами mscorlib. Со вторым поинтереснее, но по-прежнему у нас нет NP-задачи. Точнее, мы можем выделить относительно разрешимую подзадачу.


Все рано или поздно упрется в определение эквивалентности двух объектов. Например: берем строку — литерал в коде, состоящий из K символов (известных). шифруем ее каким-нибудь алгоритмом, сжимаем ее, конкатенируем саму с собой, удаляем все буквы 'x', вобщем в том же духе, потом берем два символа с начала строки и два с конца — конкатенируем... а дальше строка 'if (s == "2009")'. Вот здесь компилятор особенно обрадуется... Или тоже самое в присутствии внешних данных и возможных дефектов. Строку можно заменить на какой-нибудь граф объектов...

ЮЖ>>Использовании значения по умолчанию — такие значения все же будут использованы для дальнейших вычислений.

S>По хорошему, они тоже должны элиминироваться.

Как элиминироваться? От них же (значений) код зависит.

string f(string name, string prefix = "Dear "){
  return prefix + name;
}
//...
f("Bob!");


В частном случае их использование может зависеть от других значений...

ЮЖ>>Игнорирование здесь мало подходит, т.к. в этом случае не получится игнорировать возможные побочные эффекты, + возможные затраты на вычисление.

S>Это если побочные эффекты есть. У Липперта, помнится, есть упоминание про то, как оптимизируется код "вокруг" побочных эффектов.

Можно взять эффекты такого рода:
int foo()
{
  int x = f();
  int y = g(); 
  if(y == 100)
  {
    x++;
  }

  return (x, y); // y - не будет использоваться.
}


Вот такой случай я выше имел ввиду под "зависимыми значениями" результата.
Re[11]: Inline records
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.10.09 20:50
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Это не "докапывание до терминов", это поиск согласования. Когда ты говоришь какие-то вещи безусловно не соответствующие общепринятому пониманию,

VD>Что не соответствует общепринятому пониманю? Что скрипты называют нетипизированными или динамически-типизированными? Или то, что все эти термины в обиходе означают одно и то же?

Второе. Такой "обиход" соответствует разве что традиции твоего кружка. Остальные знают, что есть статическая типизация и динамическая, строгая и нестрогая, основанная на наследовании и утиная, в каждой паре масса промежуточных вариантов, комбинируются они тоже не всегда тривиально. И наконец, что обобщать как "скрипты" группу совершенно по-разному устроенных языков — нелепица. И что твоё обобщение почему-то включило в себя ещё те языки, которые ничуть не "скрипты" — тот же Erlang, который компилируется, но в котором статическая оптимизация есть сейчас только в маргинальных случаях.

N>>"совершенно точно имеет факт одного из двух" — или непонимание, или своя терминология ради какой-то своей цели. Но причины такого определения ты раскрывать не хочешь — ну что ж, заставить нельзя:))

VD>Значит я правильно понял, что ты все же решился докопаться до термина "нетипизированный"?
VD>Тебя устроить если вместо него использовать динамически-типизированный?

В локальном смысле — да, если принять такое определение для ветки дискуссии. В глобальном — уже нет. Потому что ты
1) из всех вопросов, которые обсуждались, отрезал и выпятил только один
2) развил его в агрессивно-парадоксальном стиле, с переходом на личности ("решился докопаться" и тому подобные обращения)
3) при этом пытаешься сместить терминологию в сторону, не обусловленную ни одним объективным фактором

И, собственно, кто тут должен утверждать "не могу вести дискуссию в таком стиле" — вопрос спорный.

VD>>> В данном случае совершенно точно имеет факт одного из двух.

N>>Мимо. Впрочем, возобновлять дискуссию мне облом.
VD>Что мимо то? Я так и не понял что ты хотел сказать.

Что "имеет факт одного из двух". Имел факт вопроса, на основании чего такое странное утверждение — может, ты пытался выдвинуть какую-то совершенно новую идею. Но вместо этого я увидел только волну обструктива, а это действительно облом продолжать.
The God is real, unless declared integer.
Re[13]: Inline records
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.10.09 20:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Тогда за фиг тебе С++? На С можно писать точно так же, только с большим количеством явно выраженных деталей. Ну, а раз можно обходиться, то нужно (по твоей логике)!

PD>>Инкапсулирование. На С практически невозможно, разве что пародия.
VD>Да, ну? Иди попробуй нарушить инкапсуляцию Win API.

Если формально подходить к вопросу — это более чем возможно. Очень многие вещи в WinAPI реализуются в userland'е использующего процесса — например, к этому относится значительная часть GUI, и залезть в область данных рисуемого приложением окна (при том, что адрес области добывается через GetWindowLong) — столь же легко, как запороть любые другие данные.

Сложно доступиться только до того, что находится в пространстве ядра или другой задачи. Но это сложно уже на любом языке, в котором нет аналога LA 1,12 / SVC 107 :)) и тут аналогично C и C++ не помогут.

Вообще, ваш спор существенно ни о чём.

VD>Если ты еще не понял, то разговоры на тему зачем нужны кортежи ничем не отличаются от разговоров на тему зачем нужны классы. Просто ты предвзято относишься к проблеме.


Вот тут +100. Наличие механизма, упрощающего написание и понимание типичных конструкций, всегда полезно.
The God is real, unless declared integer.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.