ПК>Ты один работаешь или в команде?

это вообще хобби а к чему ты спрашиваешь?

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

Извини. Только сейчас и случайно заметил. Уже практически не слежу за веткой.

WH>А между точкой выброса и точкой обработки как ресурсы освобождаешь?
Об автоматических объектах вопрос наверное не стоит. Раскручивание стека — вещь понятная. Но раз зашла речь о сырых указателях то уж куда без объяснений.
Если я завожу локальный указатель и при этом еще и выделяю под него память, то на это у меня может быть несколько причин. Либо он мне нужен для перемещения внутри объекта с более глобальной областью видимости, либо он мне нужен для трансляции в более глобальный контейнер указателей, который сам имеет механизмы уборки за собой, ежели организован по такому принципу. Возможно я перечислил бегло не все варианты необходимости, но поверьте на все варианты, есть безопасные алгоритмы слежения за ресурсами.
1. Если он мне нужен для перемещения по памяти занимаемой объектом с более глобальной областью видимости, то о каком освобождении идет речь. Ежели я выделяю под него память и при этом я не имею 100% уверенности что после выделения, до достижения точки присвоения не возникнет исключения, я ставлю перехватчик обязательно в области видимости указателя и как минимум ставлю фильтр на выброс всех описанных спецификацией исключений, алгоритмами выделения. И в зависимости от того где было перехвачено исключение я делаю соответствующие выводы. Все остальное — ошибка программиста, may be. Мог конечно что то и упустить при беглом описании. Не статья, чтобы над ней работать, но суть реализации такова. Я думаю всегда, даже когда знаю что делаю. Это помогает мне не напрягаться отсутствием элементарного внимания в некоторых случаях.

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

A>>Андрей. Честно, положа руку на сердце. Это уже не к месту. Я отвечу на все твои вопросы, но уже при личной встрече.
WH>Это весьма маловероятное событие.
Я приеду, если пригласишь

A>>Если столбик термометра перевалит за 800 — это уже лишнее для чего угодно.
WH>Ты про колличество сообщений в теме? Так это же флейм.
Здесь ты меня понял абсолютно точно.

Здравствуйте, dr.Chaos, Вы писали:

DC>ЗЫ Если уж придираться к орфографии и грамматике, давай придираться ко всем .

А я и не придирался вовсе, просто забавным показалось. А если тебе все же обидно за свои ляпы, так это не ко мне притензии.

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

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

PD>>А это один из критериев качества. Быстрее, меньше памяти требуется и т.д.

AF>Качество — это когда программа делает свою работу правильно, не падает и не рушится.
В понятие "правильности" может входить и определенное время реакции. Особенно актуально это для систем реального времени (к которым, в общем-то и игры можно отнести) и массового обслуживания (СУБД, веб-серверы и т.п.)

AF>А скорость — это отдельный параметр, и к качеству никакого отношения не имеет.
Имеет. Сможешь ли ты играть в игру со скоростью вывода 1 fps? Хотя она не падает.

ИМХО, качественная программа — программа, выпоняющая возложенную на нее задачу.

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

VD>>Из ГУИ януса я делал только дерево.
CC>Это то, которое при сворачивании иногда неправильно перерисовывается оставляя хвост?

А ты еще древнее Янус надыбай и не то будет.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Кстати, поиском не нашел. Говорят, манифестом можно сделать у него потребный вид по win2k... Сцылочкой не поделитесь?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity name="WindowsShell" processorArchitecture="x86" version="5.1.0.0" type="win32"/>
<description>Windows Shell</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="x86" 
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

Сохраняешь в файл Janus.exe.manifest и кладешь рядом с экзешником. Только он и так должен быть по идее.

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

BZ>сколько они тебе за это заплатили?

Дык они еще дньги не дали. Все обещают.

BZ>ps: спрашиваю не из любопытсва — может, я продешевил?

Может.

Здравствуйте, cl-user, Вы писали:

CU>Пойду повешусь.

В добрый путь.

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

VD>>Извини, ты смарт-поинтерами пользуешся?

A>Очень редко, поскольку у меня нет проблем связанных с утечкой ресурсов под указателями. Но не отвергаю их с определенным количеством оговорок.
A>Задавай вопрос целиком. Учитывая оболочку в которой мы общаемся — это расточительство.

Не могу. Он (точнее они) зависит от твоих ответов.

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

И еще один вопрос. Я правильно понял, что ардесной ирифметикой ты пользуешся в своих программах довольно часто?

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

BZ>так это готовые, особенно твоё. дело-то именно в том, что хаскел предоставляет мощные средства КОМПОЗИЦИИ простых операций, в то время как для популярных языков существуют готовые бибилиотеки, где реализована куча алгоритмов. но выйди за пределы этих библиотек. наличие rfind ничем не поможет тебе в работе в lazy списками или деревьями. речь идёт именно о возможностях конструирования алгоритмов, предоставляемых языком


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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Да уж... Rocket science... То, что ты изобразил на C#, на C++ выглядит, мягко говоря, не сложнее: str.rfind(' ', 80)

Согласен такой примитив даже в С++ в библиотеки запихнут. Что скажешь по поводу других примеров?

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

A>У С++ не настолько куцые концепции, насколько куцые представления у вас о них, либо это просто упрежденное мнение и оно не может учитываться в претендентах на действительность.

Оба допущения не врены. Идем дальше.

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

Осмыслености в этом не обнаружил, так что отчечать не начто.

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

Русский меня вполне устраивает. Ужасом его не считаю. Многие знатоки аглийского видимо тоже самое сказали бы и про него.

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

Опять пустословие.

A>Это я могу воспринять только как наезд. Где было определение того, что я знаю только С++ или даже еще больше ограничиваюсь только его использованием, и даже если вы соблоговолите это признать, то это совершенно не обозначает что я полностью поддерживаю ваше мнение.

Это видно не вооруженным взглядом. Может ты и знаешь еще с сотню менее мощьных языков (однотипных), но сути дела это не меняет. Твое явное непонимание того что тебе высказывают говорит само за себя. Обижаться тут бессиленно. Надо или преркащать идсскуюссию и оставаться в блаженном неведении или все же попытаться изучить альтернативы и вести разговор используя общие понятия.

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

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

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

VD>>Это понятно. Ты ведь не видел того как может выглядеть метапрограммирование будь оно органично встроено в язык. Потому и сомневашся. А вот IT видел. Как сейчас помню восторженный его восклик в аске — "Оифигеть! Я добавил поле типа Location и забыл сделать его изменяемым, но компилятор мне сказал об этом! И это делает простой макрос!". Так что вы в разных условиях. Он видел и то, и то, а ты только шаблоны С++.

A>) Не только, если сложилось такое впечатление и я не об этом, если это просто ваше заблуждение.

ОК, тогда тебе не составит труда описать известные тебе языки с встроенными возможностями метапрограммирвоания объяснить почему ты считашь, что С++-ное метапрограммирвоание на шаблонах лучше, или хотя бы не хуже. Не составит?

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

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

Добро пожаловать в мир где эти вопросы практически решены — в мир Nemerle!

Здравствуйте, Андрей Хропов, Вы писали:

АХ>ИМХО, качественная программа — программа, выпоняющая возложенную на нее задачу.

Вот это точно. Главное, что можно сказать про скорость — она должна быть достаточной. И не более того.

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

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

VD>>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты? Может их просто нет в этом языке, а средства эмуляции настолько убоги, что не позволяют это сделать качественно? Я ошибаюсь? А тогда в чем же дело?

A>Мне похлопать тем (гы-гы, кто использует этот язык 10 лет к ряду) от тех (гы-гы, кто использует этот язык 10 лет к ряду). Или я должен был понять, что вы именно тот человек, чей опыт и представления идеальны.

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

Хлопать тоже не надо. Просто твои предположения не верны. Я писал на С++ 10 лет. Правда тогда еще шаблоны были по слабее (в начале их вообще не было), и СТЛ мы не использовали так как он появился после того как мы сделали свои библиотеки, но это мелочи. Вольфхаунд и сейчас зарабатывает хлеб программированием на С++ просто потму что за него сейчас платят хорошо. И он уж точно на современных выкрутасах С++ не одну собаку съел.
В общем, ты лучше спроси. А то видишь, что люди что-то критикуют и сразу строишь предположения о низкой компетенции в этой области.

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

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

A>Настолько убоги, насколько лишь вам это кажется, но это только кажется. Ваши представления и мои и чьи либо другие далеки от истины, иначе был бы уже давно единый и совершенный мир.

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

Вот, ты наприммер, за все время полемики даже не разу не удосужился уточнить "А что же мы предлагмем взамен?". Видимо не интересно. Ведь ты уже в этой жизни для себя все решил. Есть правильный путь, и он тебе звестен. Я угодал?

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

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

A>То что вас ограничивает с использованием каких либо средств, не является признаком того, что это логично, а лишь признаком того, что по каким либо причинам вас это просто не устраивает.

А что же нелогичного в том, что нас что-то не устраивает? Может быть мы знаем как можно делать тоже самое, но лучше?

A> (А тут хоть что угодно определяйте. Не гибкость, не желание и т.д. и т.п.) Но это уже ваши проблемы а не комитета. Если бы это были проблемы комитета, то на языке уже никто не писал. И по моему это обсуждение уже вышло за рамки ++.

Не. Это конечно не проблемы комитета. Ему просто по барабану. Это вообщене человек. У него нет единого мнения. Да и язык от тупого животного по имени комитет не помрет сразу. Он будет медленно деградировать или просто остановится в развитии.

VD>>В С# нет встроенного метапрограммирования. По этому и обсуждать не чего. А вот в Nemerle есть. И метапрограммирование на С++ на его фоне выглядит полнейшим извращением и убожеством.
A>Все верно, но это не значит что нет таких вещей, которые тоже могут являться не естественными в обратном направлении.

Да, уж. Не поспоришь. Один факт не отрицает гипотетической возможнсоти наличия дугого.
Но первый факт остается фактом.

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

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

Вобще-то Хаскель как раз компилируется в нэйтив-код. Я ошибаюсь?
Байтод же дотнета никогда не исполняется в режиме интерпретации. Он всегда компилируется.
Так что если разница есть, то она определяется не байткодом, а другими вещами. Опимизацией компияторов (можно найти С++-компилятор который будте работать медленее хасклея во многих случаях, например) и герераторов нэйтив-кода. Качеством библиотек. Способом абстрагирвоания. Несомненно С/С++ позволяют выжать из железа больше при должном рвении. Но так же несомненно, что это больше выжимается очень редко. И не редки случаи кода на С++ пишут крайне медлительный код (иногда даже не осознавая этого). Утверждение "С++ самый быстрый" самое большое заблуждение. Код пишет программист. А С++ инструмент позволяющий оптимизировать в малом. Но на больших объемах он может сослужить плохую службу.

BZ>вопрос "если наш язык так крут, почему же его никто не использует?" в сообществах small языков возникают куда чаще, чем здесь есть даже статья об этом профессора Вадлера, одного из авторов Haskell и generic Java. если кратко, то дело (помимо объективных свойств самого языка) в *инфораструктуре*: библиотеках, средствах разработки, книгах, обучении и в конечном счёте подготовленных специалистах

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

BZ>спецы по Прологу или Немерлу — хорошие программисты не потому, что язык хорош. я вот скажем пишу на хаскеле, си и delphi, так что — мои способности каждый день меняются? дело в том, что для изучения скажем ООП+ООД уже есть хорошо накатанная колея, этому учат с института и человек думает о программе в этих терминах на автомате, воспринимает их как нечто соверщшенно ращзумеющееся — точно так же, как умение говорить. как мне Влад говорил, "на самом деле мир — императивен"

С обучением вообще "труба". Все что я пробовал читать по ФП никода не годится. Это писанина сумашедших ученых погрязщих в теоритическом булшите. Их труды скорее способны отбить желание изучать предмет.

Тут нужна литература столь же доступная как труд Кхернигана. Уверен, что успех С во многом определяется его книгой.

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

Вопрос отладчиков, библиотек и IDE очень важен. И его надо решать. Это один из фаторо останавливающих программистов в изучении и применении новых языков. После Дельфи, ИДЕИ и VS 2005 мало кто захочет писать код в нотпэдах или даже в Вимах и Емаксах.
Вот в отношении Немерла мы как раз работаем над этим. И уверен, что если будем меньше ошиватьс на этом форуме, то добьемся успехов.

Здравствуйте, Курилка, Вы писали:

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

На мой взгляд ФП такая же надстройка но с другим уклоном.

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

BZ>меня как-то на C# приглашали только потому, что я хаскел знаю. в history of haskell самая понравившшаяся мне фраза — представителя одной из коммереских фирм: "мы обнаружили, что поиск специалистов по хаскелу — это просто способ найти наиболее грамотных и талантливых программистов".

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

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

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

CC> Без комментариев!!!
CC>

Аргументы кончилис?