Delphi - "рулез форева"!

← →
DVM © (2010-02-16 18:14) [200]

> Германн © (16.02.10 18:09) [199]

к сожалению там исходники недоступны, как и тут: http://www.ritlabs.ru/the_bat/65/

← →
TUser © (2010-02-16 18:42) [201]

Мое ламерское имхо такое. Очень приятно, что на джаве есть контроль выхода индекса за границы массива, сразу исключение, очень удобно ошибки ловить. А на делфи нет, неудобно. Зато тут есть var-параметры для простого типа integer (int по-джавости).

Жить можно в любом языке. Можно даже на перле писАть. Даже по-паскалевски. Удобство/неудобство мало отличается в современных языках, если говорить о базовых конструкциях. Трудно найти современный язык, где нет оператора цикла или возможности делить прогу на модули. Кочнечно, без GC плохо, хотя, хз, может это сдерживает от ошибок. И без RTTI, наверное, кому-то хреново, но тоже живут. Я к тому, что языки современные бывают неудобными, но во-первых, не в хлам, а во-вторых, это субъективно.

А посему, все, чем они глобально отличаются, - это удобство, доступность и богатство библиотек, хелпа, факов, форумов. По всем параметрам, кроме хелпа, Делфи явно проигрывает. А в турбо - там и хелп так изуродовали, что держите меня семеро, под МС работают. Не знаю, как в более поздних.

Имхо есть имхо.

← →
Alkid © (2010-02-16 19:01) [202]

> TUser © (16.02.10 18:42) [201]

Пиши на C#! Там есть и контроль выходов за границы и var-параметры для простых типов.

P.S. У нас в конторе за var (т.е. ref)-параметры бьют по голове подсвечником. И правильно делают :)

← →
oxffff © (2010-02-16 19:04) [203]

>Alkid © (16.02.10 19:01) [202]
>
> P.S. У нас в конторе за var (т.е. ref)-параметры бьют по
> голове подсвечником. И правильно делают :)

Приветствую.
А почему?

← →
vuk © (2010-02-16 19:09) [204]

to TUser © (16.02.10 18:42) [201]:

> А на делфи нет, неудобно.

{$R+} - не?

← →
Alkid © (2010-02-16 19:21) [205]

> oxffff © (16.02.10 19:04) [203]

Привет.
Считается плохим стилем. Мы стремимся к идеалам ФП где этого можно достичь :) Если функция ко всему прочему будет еще и чистой, т.е. без побочных эффектов, от это вообще круто. ref-, out-параметры допустимы только там, где без них никак. Например, p/invoke и interop функциях. Но их сразу же оборачиваем фасадом, который предоставляет хороший интерфейс.

Если смотреть в более философском смысле - код становится более читаемым и предсказуемым.

← →
Eraser © (2010-02-16 19:21) [206]

как ни крути, а под Win32 рисовать GUI с пом. Делфи на порядок удобнее, чем с пом. аналогов, в особенности VS.

← →
Игорь Шевченко © (2010-02-16 19:24) [207]

Alkid © (16.02.10 19:21) [205]

Пуристов - давить :)

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

← →
oxffff © (2010-02-16 19:31) [208]

> Alkid © (16.02.10 19:21) [205]
>
> > oxffff © (16.02.10 19:04) [203]
>
> Привет.
> Считается плохим стилем. Мы стремимся к идеалам ФП где этого
> можно достичь :) Если функция ко всему прочему будет еще
> и чистой, т.е. без побочных эффектов, от это вообще круто.
> ref-, out-параметры допустимы только там, где без них никак.
> Например, p/invoke и interop функциях. Но их сразу же оборачиваем
> фасадом, который предоставляет хороший интерфейс.
>
> Если смотреть в более философском смысле - код становится
> более читаемым и предсказуемым.

Ну тогда почему бы в Вашей конторе отказаться от рекурсии в именованных функций. А воспользоваться комбинатором неподвижной точки fix как в функциональных языках. И например экзистенциальным типом на абстракции данных.

> Мы стремимся к идеалам ФП где этого можно достичь :)

И программируем на императивных.

← →
TUser © (2010-02-16 19:38) [209]

> vuk © (16.02.10 19:09) [204]

Спасибо ... обязательно буду теперь указывать. Надо же как оказывается полезно участвовать в такой ветке!

← →
Alkid © (2010-02-16 19:39) [210]

> Игорь Шевченко © (16.02.10 19:24) [207]

Всех не передавите!

А если серьезно - паттерны и антипаттерны (в широком смысле, не только GoF и ООП) - это те варианты во всем многообразии возможностей, предоставляемых языком, которые признаны хорошими и нехорошими решениями. Чистые функции и иммутабельные структуры - это хороший паттерн, который приносит много хороших пряников.

Однако от пуристов мы тем и отличаемся, что не прем на пролом. Если следование паттерну заводит в тупик, то ему не следуем.

← →
TUser © (2010-02-16 19:41) [211]

хз ... я, например, часто пишу

function BlaBlaBla (aaa, bbb, var ccc): boolean;

Смысл в том, что некое действо выполняется, если выполняется то TRUE, и тогда возвращается некое значение в ссс, а иначе - FALSE и в ссс смотреть бесполезно.

Не претенуя на истину, - а что в этом плохого?

← →
Alkid © (2010-02-16 19:46) [212]

> oxffff © (16.02.10 19:31) [208]
> И программируем на императивных.

Ну это как сказать. Вот это императивный код?

private IEnumerable<FieldJoin<TR>> JoinFields<TDataField, TR>(
object instance,
DataTransferObject dto,
Func<MemberInfo, bool> memberPredicate,
Func<MemberInfo, TDataField, FieldJoin<TR>> joinCombinator)
where TDataField : DataField
{
return GetObjectFields(instance, _ => memberPredicate(_))
.Join(GetDtoFields<TDataField>(dto),
_ => Utils.GetFieldName(_),
_ => _.Name,
joinCombinator);
}

С#, кстати, считается мультипарадигменным языком и в нем наблюдается устойчивый тренд в сторону ФП.

← →
oxffff © (2010-02-16 20:14) [213]

> Alkid © (16.02.10 19:46) [212]
>
> > oxffff © (16.02.10 19:31) [208]
> > И программируем на императивных.
>
>
> Ну это как сказать. Вот это императивный код?

Но функциональным он не является. Зачем тогда F#?

← →
Делфиец (2010-02-16 20:14) [214]

Ну все как только проект добью на делфи, то пойду изучать C#, а вообще то в нашей конторе SAP внедряют и скоро закроют всё и 1с -ников и все, что работало на оракле и все остальное и будет всёпоглащающий SAP, а нас выпнут наулицу. :(

На кого переквалифицироваться? А то что то кайлом махать не хочется.

← →
Kerk © (2010-02-16 20:17) [215]

> Кочнечно, без GC плохо

Я не доверяю GC почему-то. Мне комфортнее самому память освобождать.

← →
Игорь Шевченко © (2010-02-16 20:22) [216]

Alkid © (16.02.10 19:39) [210]

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

Ох уж эти догматики. "Признано".

Цитата прямо напрашивается:

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают
создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой
подход может обернуться неприятностями, если программисты реализуют простые
вещи сложными способами, просто потому что им известны эти способы и они умеют
ими пользоваться.
Все ОО-языки несколько склонны "втягивать" программистов в ловушку избыточной
иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне
затрудняется их просмотр и анализ ментальной модели, которую по существу
реализует код. Всецело нарушаются правила простоты, ясности и прозрачности,
а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы
при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения
правила представления. С этой точки зрения множество классов приравнивается
к внедрению знаний в данные. Проблема данного подхода заключается в том, что
слишком часто "развитые данные" в связующих уровнях фактически не относятся
у какому-либо естественному объекту в области действия программы -
они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них
предметных областей (GUI-интерфейсы, моделирование, графические средства),
возможно, является то, что в этих областях относительно трудно неправильно
определить онтологию типов. Например, в GUI-интерфейсах и графических средствах
присутствует довольно естественное соотвествие между манипулируемыми
визуальными объектами и классами. Если выясняется, что создается большое
количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим.
"

Я к чему - про приведенный тобой кусок кода в [212], вроде все слова по отдельности не вызывают непонимания, а в целом - ну напрочь непонятно.

Хорошо, когда абстракция на ладони, а когда абстракция ради абстракции (ну вот мне так по первому впечатлению кажется), получается еще более запутанно для простого неотягощенного программиста.

← →
Alkid © (2010-02-16 20:23) [217]

> TUser © (16.02.10 19:41) [211]

Я не люблю out/ref-параметры потому, что они автоматически приводят к "нечистой" функции (как звучит-то!) и потере всех пряников ФП. Кроме того, наличие out/ref-параметра - это явный code smell. Если функция возвращает два значения, то не занимается ли она двумя разными вещами, которые надо бы разбить на две функции? Функции с out-параметрами плохо подходят для функциональной комбинации. Ну и, наконец, такие функции запутывают код.

← →
Игорь Шевченко © (2010-02-16 20:24) [218]

Kerk © (16.02.10 20:17) [215]

> Я не доверяю GC почему-то

то есть, на всяких там перлах и прочих скриптовых языках ты пишешь исключительно под наркозом ? :)

← →
Игорь Шевченко © (2010-02-16 20:27) [219]

Alkid © (16.02.10 20:23) [217]

И все-таки давить. Функция вполне может возвращать N параметров и быть при этом максимально простой и ясной в отличие от искусственного нагромождения "объекта параметров" для замены такого вот code-smell :) Да и чем по сути будет отличаться набор параметров от набора свойств объекта параметров в этом случае кроме дополнительного кода - я как-то не понимаю.

← →
Alkid © (2010-02-16 20:30) [220]

> oxffff © (16.02.10 20:14) [213]
> Но функциональным он не является. Зачем тогда F#?

Он является как раз самым что ни на есть функциональным. Это чистая функция высшего порядка - отвечает всем критериям "функциональной функции". То, что она написана на C# ничего не меняет. Функционально программировать можно на любом языке, на котором можно написать чистую функцию. Просто в некоторых языках оставаться в парадигме ФП невыгодно из-за небольшой поддержки такого стиля в языке.

Вот тебе пример ФП на старом добром С:
int sum(int a, int b) { return a + b; } int mul(int a, int b) { return a * b; } int summAndMult(int a, int b, int c) { return sum(a, mult(b, c)); }

← →
Alkid © (2010-02-16 20:34) [221]

> Игорь Шевченко © (16.02.10 20:22) [216]

Ну, тот кусок кода к ООП не имеет никакого отношения :) А не понятно в нем ничего потому, что он выдран из контекста. И для его понимания надо представлять C# 3.0 и Linq.

Что же касается ООП и прочих "серебряных пуль" - я сам не сторонник превознесения одной парадигмы с презренным отверганием других. И ФП я пиарю не в смысле "срочно все языки запретить и всё переписать на Хаскеле!!!", а пропагандируя то, что я сам, на своем опыте нашел полезным.

← →
Делфиец (2010-02-16 20:43) [222]

> Игорь Шевченко © (16.02.10 20:27) [219]

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

← →
Игорь Шевченко © (2010-02-16 20:43) [223]

Alkid © (16.02.10 20:34) [221]

Да дело не в ООП в приведенном коде. Уж больно он абстрактно выглядит :)

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

> И для его понимания надо представлять C# 3.0

Я года три назад сотоварищи пытались попредставлять С# 2.0, то есть, 1.0 мы благополучно проигнорировали, а вот 2.0 решили поосваивать. Худо-бедно, даже больше худо поосваивали, набили шишек по первости, чего-то наваяли, и тут на тебе - linq! C#3.0! мама родная, как же за этим угнаться-то ?

Хорошо тем, кто пишет на простом С без плюсов...

← →
Alkid © (2010-02-16 21:00) [224]

> Игорь Шевченко © (16.02.10 20:27) [219]
> Функция вполне может возвращать N параметров и быть при этом максимально простой и ясной в отличие от искусственного нагромождения "объекта параметров" для замены такого вот code-smell :)

Не спорю, может, конечно. Только обычно этот code smell означает, что функция делает несколько вещей сразу и ее стоит разбить на более простые функции.

> Да и чем по сути будет отличаться набор параметров от набора
> свойств объекта параметров в этом случае кроме дополнительного
> кода - я как-то не понимаю.

Если мы говорим про выходные параметры, то:
1. Иммутабельностью данных. Функция не будет менять состояние неких переменных, данных ей в пользование, а породит объект-результат.
2. Возможностью применения этой функции как аргумента в библиотечных функциях высшего порядка для работы со списками.
Например, есть функция bool TryProcessValue(T value, out R result); которая пытается обработать результат и возвращает true и result, или false и неопределённое значение в result. Пока, вроде, ничего, кроме того факта, что мы имеем переменную с потенциально неопределённым значением.

Теперь мы хотим взять список значений и сформировать список результатов для тех из них, которые можно обработать функцией. Многие языки поддерживают функции filter (http://en.wikipedia.org/wiki/Filter_(higher-order_function)) и map (http://en.wikipedia.org/wiki/Map_(higher-order_function)). В C# они называются Where и Select. Но как засунуть эту функцию в эти? Никак. И мы пишем в стописяттысячный раз унылый цикл вида:
foreach(var v in MyValueCollection) { R result if(TryProcessValue(v, R)) { MyResultCollection.Add(R); } }

Если бы функция TryProcessValue была представлена в виде двух других функций:
bool CanProcessValue(T value); R Process(T value);

То весь цикл сверху сжался бы до:
MyValueCollection.Where(CanProcessValue).Select(ProcessValue);
Мало того, что этот код короче, он еще и понятнее. В нем гораздо более явно выражено намерение программиста, чем в варианте с циклом. Плюс ко всему он работает с неизменяемыми значениями. Чем это хорошо? Можно быстро и безопасно распараллелить при помощи PLINQ:
MyValueCollection.AsParallel().Where(CanProcessValue).Select(ProcessValue) ;
Всего одно добавление и наш код автоматически распараллеливается по количеству ядер. Понятное дело, что в этом мало моей доблести (ребята из MS молодцы), но что бы воспользоваться достижениями других, надо придерживать некоторых стандартов.

Пример не надуманный. Сейчас я пишу проект, в котором подобных задач с обработкой коллекций полным полно.

← →
Alkid © (2010-02-16 21:02) [225]

> Делфиец (16.02.10 20:43) [222]

Не бойся, наш фашизм распространяется только на тех, кто пришел к нам работать :)

← →
Alkid © (2010-02-16 21:05) [226]

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

Панацеи нет, это удобный инструмент, а не спасение мира :)

> C#3.0! мама родная, как же за этим угнаться-то ?

Следить за тем, что происходит :) Технологии вещь эфемерная. Но если понимать фундаментальные вещи, стоящие за тем же Linq, то его понять совершенно не сложно. Это просто удобное воплощение операций над множествами. В принципе, очень похоже на SQL. Или SQL тоже зря придумали? ;)

> Хорошо тем, кто пишет на простом С без плюсов...

Вот уж увольте меня писать те вещи, которые я пишу, на "простом С". И даже с плюсами.

← →
vuk © (2010-02-16 21:15) [227]

to Alkid © (16.02.10 21:00) [224]:

> Только обычно этот code smell означает, что функция делает
> несколько вещей сразу и ее стоит разбить на более простые
> функции.

Предлагаю без потери эффективности разбить на более простые функции что-нибудь типа:

function TStringList.Find(const S: string; var Index: Integer): Boolean;

← →
Игорь Шевченко © (2010-02-16 21:19) [228]

Alkid © (16.02.10 21:00) [224]

> 1. Иммутабельностью данных. Функция не будет менять состояние
> неких переменных, данных ей в пользование, а породит объект-
> результат.
> 2. Возможностью применения этой функции как аргумента в
> библиотечных функциях высшего порядка для работы со списками.
>

Вот ты все-таки не можешь понять одной простой вещи :) Нет черного и нет белого. Да, функция может возвращать несколько значений, это может вполне естественно и очевидно выглядеть. При этом она специально написана для того, чтобы "менять состояние переменных, выданных ей в пользование". Оно может и подход - городить на каждом шагу объекты, создавать, полагаться на сборщик мусора, что он их когда-нибудь подъест, но есть один тонкий момент - не всегда код с объектами, C#3.0 и linq выглядит проще и очевидней, чем без объектов, c#3.0 и linq

> Только обычно этот code smell означает, что функция делает
> несколько вещей сразу и ее стоит разбить на более простые
> функции.

Банальнейший пример - фукнция двоичного поиска в списке возвращает успех/неуспех и позицию в списке либо для найденного элемента, либо место для вставки нового. Да, она делает несколько (а именно две) вещи одновременно.
Предлагаешь разбить на две функции ? А зачем ?

> То весь цикл сверху сжался бы до:
> MyValueCollection.Where(CanProcessValue).Select(ProcessValue);
>

Ты извини, а что оно делает, эта вот строка кода ? Цикл описанный тобой выше, вполне себе понятен, а вот строка - мне, например, ни разу непонятна.

Alkid © (16.02.10 21:05) [226]

> Следить за тем, что происходит :) Технологии вещь эфемерная.
> Но если понимать фундаментальные вещи, стоящие за тем же
> Linq, то его понять совершенно не сложно. Это просто удобное
> воплощение операций над множествами. В принципе, очень похоже
> на SQL

Я немножко в курсе, что linq похож на убогий SQL, но не понимаю, где его место в процедурных языках. SQL обычно используется миллионами мух для манипуляций с данными, процедурные языки для (грубо говоря), кодирования алгоритмов.

Впрочем, мое непонимание вполне может объясняться, скажем так, не тесным знакомством с linq, но первое впечатление именно такое - а нафига?

to Игорь Шевченко © (16.02.10 21:19) [229]:

> Так не честно, я пост дольше писал :)

У нас это называется "у дураков и мысли - одинаковые". :))

> vuk © (16.02.10 21:15) [227]

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

Но ты верно ткнул меня носом и я внесу оговорку - я говорю о задачах, где performance - not an issue.

to Alkid © (16.02.10 21:22) [231]:

> Вся красота, о которой я говорю, не очень дружит с производительностью

Зато красиво всё до опупения. Вот только отчего-то красивая машина не хочет летать красиво. Не дружит она с полетать... :)

Alkid © (16.02.10 21:22) [231]

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

http://local.joelonsoftware.com/wiki/%D0%9D%D0%B5_%D0%B4%D0%B0%D0%B9%D1%82%D0%B5_%D0%90%D1%81%D1%82%D1%80%D0%BE%D0%BD%D0%B0%D0%B2%D1%82%D0%B0%D0%BC_%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B_%D0%B2%D0%B0%D1%81_%D0%B7%D0%B0%D0%BF%D1%83%D0%B3%D0%B0%D1%82%D1%8C

Alkid © (16.02.10 21:22) [231]

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

Как это ни странно, в ряде случаев отлично дружит. Особенно если объекты не городить :) Сокрытие информации и разделение обязанностей прекрасно можно реализовать и без ООП, чему опыт исходного кода Unix уже лет 30 с копейками как свидетельствует.

> Игорь Шевченко © (16.02.10 21:19) [228]

Я не говорю о черном и белом :) Я надеюсь ты понял, что про подсвечник - это была шутка. Я говорю о том, с чем я столкнулся на своем опыте и для чего предлагаемые мною паттерны оказались хорошим решением.

> Предлагаешь разбить на две функции ? А зачем ?

Именно потому что делает две вещи. Функция, которая делает что-то одно проще во всех смысла - для написания, для понимания, для отладки и поддержки.

> Ты извини, а что оно делает, эта вот строка кода ? Цикл
> описанный тобой выше, вполне себе понятен, а вот строка
> - мне, например, ни разу непонятна.

Ты либо лукавил, говоря о том, что представляешь себе linq, либо сейчас лукавишь :)

> Впрочем, мое непонимание вполне может объясняться, скажем
> так, не тесным знакомством с linq, но первое впечатление
> именно такое - а нафига?

Да как тебе сказать... Вот все сейчас ругают linq, дескать, нафига он нужен. Но никому не приходит в голову ругать функции map,filter, fold, join, intersect, union и т.п., которые в том или ином виде почти в каждом языке встречаются. А ведь это, по сути, одно и то же :)

← →
Делфиец (2010-02-16 21:37) [235]

> Alkid © (16.02.10 21:02) [225]
> > Делфиец (16.02.10 20:43) [222]Не бойся, наш фашизм распространяется
> только на тех, кто пришел к нам работать :)

Так на заметочку, а где вы работаете? А то когда буду безработным шляться, то быть в курсе о подобных конторах в которых прогеров в шеринги выстраивают ;-)

Alkid © (16.02.10 21:33) [234]

> Именно потому что делает две вещи. Функция, которая делает
> что-то одно проще во всех смысла - для написания, для понимания,
> для отладки и поддержки.

Это опять религиозные споры. Разумеется, можно написать функцию, которая вычисляет квадратные корни, вычисляет координаты вершин всех звездчатых форм икосаэдра с заданным центром и ребром, и предсказывает погоду в 11 точках планеты - все за один вызов. А можно не писать такую функцию.

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

> Ты либо лукавил, говоря о том, что представляешь себе linq,
> либо сейчас лукавишь :)

Нет, как ни странно, не лукавлю. Абстрактные имена с толку сбивают. Ну и про тесноту общения с linq я тоже упоминал.

> Но никому не приходит в голову ругать функции map,filter,
> fold, join, intersect, union и т.п., которые в том или
> ином виде почти в каждом языке встречаются. А ведь это,
> по сути, одно и то же :)

Э...в паскале тоже встречаются ? :) join, intersect и union ?

← →
делфиец (2010-02-16 21:56) [237]

Кстати в самой windows подобных функций полно, которые возвращают переменные и результат одновременно
QueryServiceStatusEx(HSrv,SC_STATUS_PROCESS_INFO,@SSPRec,SizeOf(SSPRec),dw BytesNeeded)
да почти весь WINAPI так устроен, кстати и это тоже придумали те же умные парни из Microsoft .

да усе хакеры знают, шо винда отстой ...

← →
Делфиец (2010-02-16 22:08) [239]

> делфиец (16.02.10 21:56) [237]

.... И это им не мешает писать подобные функции и далее в и кроме того даже в новых windows. Вы Alkid © представляете себе, что было бы, если бы эти парни из Microsoft дробили бы все свои подобные функиции на двое?

> Игорь Шевченко © (16.02.10 21:41) [236]

> центральной частью функциональности, а не возвращение найден/не
> найден и места, куда вставить

Академические размышления на эту тему привели меня когда-то
к варианту, способному примирить две позиции:
функция, не могущая принести результат, возбудит исключение.

Конечно, для некоторых случаев использование оного механизма
может оказаться накладным, но для остальных - оч.наглядно.

Да, и уважаемый Alkid © палку-то перегнул, насчет by Ref,
бо, если у функций нет побочных эффектов, скажем, с
выделением памяти, то чего особенного она в системе изменит.

Заполняем мы буферы в функциях Win32, никто, вроде, не пострадал,
если, конечно, внимательно за размерами следил :)

--
Regards, LVT.

Delphi - "рулез форева"! Найти похожие ветки