LINUX.ORG.RU

Valgrind 3.8.0

 , , , ,


3

2

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

  • Поддержка свежих дистрибутивов Linux (gcc-4.7, glibc-2.16).
  • Поддержка платформы MIPS32/Linux, в обоих форматах: BE и LE.
  • Начальная поддержка x86/Android.
  • Начальная поддержка MacOSX 10.8.
  • Поддержка инструкций Intel AVX и AES.
  • Поддержка инструкций для десятичных чисел с плавающей запятой для архитектуры POWER.
  • Добавлена поддержка реализаций malloc(), находящихся не в libc.so. Это даёт возможность использовать альтернативные реализации malloc() такие как TCMalloc и JEMalloc при запуске в Memcheck, Massif, DRD, Helgrind.
  • Для инструментов, подменяющих вызовы функции malloc() и ей подобных, добавлена опция --redzone-size=<кол-во байт>, которая позволяет задать размер специальных запретных зон вокруг выделяемых блоков памяти. Чем больше размер этих зон, тем больше шанс поймать выход за границы выделенной памяти.
  • Для инструментов, работающих с потоками, добавлен новый планировщик потоков, основанный на алгоритме round-robin. Этот планировщик является более честным и обеспечивает лучшую отзывчивость интерактивных многопоточных программ, а также даёт лучшую воспроизводимость результатов в Helgrind и DRD.
  • Улучшение производительности при наличии большого количества правил для подавления ошибок.
  • Улучшена поддержка формата Dwarf (поддержка DWARF4 и алгоритма сжатия отладочной информации DWZ).
  • В Memcheck сокращено потребление памяти для программ, выделяющих большое количество блоков памяти.
  • В Memcheck увеличена производительность обнаружения утечек памяти.
  • Во встроенный GDB-сервер добавлено несколько полезных команд для работы с Memcheck.
  • В Memcheck под MacOSX 10.6, 10.7 уменьшено количество ложных срабатываний, которые вызваны особенностями кода, генерируемого LLVM/Clang.
  • Множество других улучшений и исправлений ошибок.

Официальный сайт

>>> Подробности

★★★

Проверено: maxcom ()
Последнее исправление: Silent (всего исправлений: 1)
Ответ на: комментарий от true_admin

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

Тоже му-ха-ха. Что бы ты тут ни сказал факт остается фактом: ТЫ НЕ РАСПАРСИЛ ПОСЛЕДОВАТЕЛЬНОСТЬ СИМВОЛОВ ДО КОНЦА ПРЕДЛОЖЕНИЯ А ОТРЕФЛЕКСИРОВАЛ В ПРЕДЕЛАХ ВЫРАЖЕНИЯ. Неудачник, чо.

anonymous
()
Ответ на: комментарий от anonymous

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

A-234 ★★★★★
()
Ответ на: комментарий от A-234

Мы парадигму обсуждаем, а не конкретный язык.

Да.

Treats datafields as objects manipulated through pre-defined methods only

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

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

unsigned ★★★★
()
Ответ на: комментарий от geekless

Тебе не хватает правильно собранного модуля libastral, определённо.

Подкинешь мне свой so'шник? Ах, да... .Там же нет ооп и интерфейса нет...как же мы без них. Можешь для меня врапнуть libastral под XPCOM/JavaScript. А вглубь я уже сам все расковыраю раз по-вашему «вне ООП жизни нет».

anonymous
()
Ответ на: комментарий от anonymous

Бла-бла-бла. Науке и хорошим практикам границы неведомы. Тем более в такой говенной, безденежной области, как быдлокодинг прикладных инструментов

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Бла-бла-бла.

??? (*)

Науке и хорошим практикам границы неведомы.

Согласен. Ну а вы готовы дать обезьяне гранату? Так вот, вам сначала придется доказать что вы не обезья^W из числа 95%.

Тем более в такой говенной, безденежной области, как быдлокодинг прикладных инструментов

Как бы речь была о парадигме. А насчет «быдлокодинга прикладных инструментов» я ничего сказать не могу. Вероятно вам виднее.

--- * - ???

anonymous
()
Ответ на: комментарий от anonymous

ОТРЕФЛЕКСИРОВАЛ

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

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

Так что будь ласка или таки расскажи (можешь ссылок на википедию накидать) или изыди. Смотри только чтобы не получилось что ты переизобрел ООП.

я писал на С++ кроссплатформенный расширяемый (привет, интерфейсы) интеллектуальный загрузчик любых (привет, абстракция) типов данных с любых (снова привет) хранилищ

Открыл для себя сериализацию и объектные БД?

дибильное решение по другим параметрам

не поделишься параметрами для ламеров позорных типа меня?

true_admin ★★★★★
()
Ответ на: комментарий от geekless

Я тебя спросил, при чем тут регэкспы, на что ты решил, что «по-вашему вне ООП жизни нет». Вывод: ты упорот.

Лол. Железная\^W женская логика :). Как бы сначала ты для себя решил что я тебе внезапно дам готовые ответы. А с чего бы вдруг? Думай сам.

anonymous
()
Ответ на: комментарий от anonymous

Согласен. Ну а вы готовы дать обезьяне гранату?
Так вот, вам сначала придется доказать что вы не обезья^W из числа 95%.

Ладно, значит ты не социопат-неудачник, а просто неумелый тролль

vasily_pupkin ★★★★★
()
Ответ на: комментарий от A-234

Ты не блаблакай, конкретную реализацию давай. Еще учти, что дейталог через bdd реализован.

А для ООП тупо нет ни одной подходящей задачи. Вообще ни одной! Все, что делают через оопу, лучше и проще делать другими путями. Всегда. Без исключений.

anonymous
()
Ответ на: комментарий от unsigned

Ни наследование ни инкапсуляция ни полиморфизм не приводят нас к определениям понятий класс и объект. ООП с успехом можно применять к программам написанным на чистом С, впрочем первые С++ компиляторы были фактически препроцессорами порождающими С код. С тем же успехом программы написанные на С++ с объектами содержащими public members объектно-ориентированными не являются, хотя они могут с успехом использовать все три «столпа» ООП.

A-234 ★★★★★
()
Ответ на: комментарий от anonymous

У тебя женская логика? Ну тебе виднее.

Использование регулярок и ООП вообще никак не связано. Чувак может быть матерым крестовиком или хаскелистом. Владеет он при этом регулярками или нет — абсолютно ортогонально.

В сад, короче.

geekless ★★
()
Ответ на: комментарий от anonymous

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

можно пример реализации библиотеки GUI? Посмотрим как далеко удалось уйти от наследования и полиморфизма. Я надеюсь это не будет тот же ооп, только через задницу?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

Назови меня упоротым/троллем и забей на сказанное. И нет проблем. Так же проще. Че ты к моему «троллингу» докопался? А тебе не пофиг?

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

Благодарю. А то много желающих в последнее время урывками пересказать про столпы ООП, потрясти ветхим заветом\^W\^W трудами Г. Буча и заодно потыкать лицом в Rational Rose (R) .

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

Хм...а ведь есть еще варианты.

Смотри только чтобы не получилось что ты переизобрел ООП.

Да, одно время мне так и казалось. Но штанишки ООП сильно жмут и часто рвутся. Поэтому, можно утверждать что закройка под ООП не наш случай. Это, кстати, и не АОП. До сих пор вопрос не рассматривался в достаточной мере.

я писал на С++ кроссплатформенный расширяемый (привет, интерфейсы) интеллектуальный загрузчик любых (привет, абстракция) типов данных с любых (снова привет) хранилищ

Открыл для себя сериализацию и объектные БД?

Да, близко. Но они не сходятся.

дибильное решение по другим параметрам

не поделишься параметрами для ламеров позорных типа меня?

К сожалению, не поделюсь. Я и сам бы рад дискуссию создать в сети насчет «этой» техники разработки для поиска новых решении и анализом существующих и подключить людей которые идут в этом направлении, но в сегодняшних реалиях делать подобное будет глупостью (да и, честно говоря, до сих пор встречаются признаки незаконченности подхода). А люди двигающиеся в подобном напралении таки есть: не так давно мне попадался нестандартный код написанный на С++ с использованием сходной техники, и автор явно знал что делает и почему. Есть хорошая идея насчет нее, но чтобы опробовать ее надо как следует войти (а это в процессе) в гейм-девелопинг.

anonymous
()
Ответ на: комментарий от anonymous

Ты не блаблакай, конкретную реализацию давай. Еще учти, что дейталог через bdd реализован.

А для ООП тупо нет ни одной подходящей задачи. Вообще ни одной! Все, что делают через оопу, лучше и проще делать другими путями. Всегда. Без исключений.

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

PS: ООП можно использовать и не стандартным путем. ООП-шники ловят при этом лютый баттхерт (проверено).

anonymous
()
Ответ на: комментарий от anonymous

без обид, но без хотя бы элементарнейших примеров ты выглядишь как ещё одна заблудшая душа которая думает что знает что-то до чего другие «не доросли». Уже не раз и не два на лоре такое видел.

Я тебе поделюсь своим видением мира, хотя понимаю что тебе пофиг. Вначале был код аля простыня. Без функций, без ничего. Потом решили отдельные (а так же повторяющиеся) куски кода обособлять для удобства разработки и отладки. Так появились функции. Потом подумали-подумали и решили что часть функций можно выделить в библиотеки. Так появились библиотеки. Потом идея «разделяй и властвуй» развивалась дальше и функции и данные начали выделять в классы (что не отменило ни функций, ни библиотек). Попутно это дало прочие плюшки типа наследования. Но, по сути, ООП это способ организации и структурирования кода. Один из нескольких способов, какой из них лучше подходит выбирать тому кто пишет.

Так вот, заявлать что ООП не нужен это глупо. Точно так же можно заявлять что не нужны, например, функции. Да что уж там, циклы тоже не нужны.

PS а я не поленился, прошерстил инет на тему «недостатки ООП». Кроме тупого высера от громких имен из computer science и жалоб что «от этого кода сам писаться не начинает» и «нам не удалось сократить затраты на разработку в 10 раз» я больше ничего не нашёл.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

ООП можно использовать и не стандартным путем.

примеры в студию

ООП-шники ловят при этом лютый баттхерт (проверено).

Возможно есть от чего. Я на внедрении проектов такого насмотрелся... При этом люди очень сильно гордились своими поделиями.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

без обид, но без хотя бы элементарнейших примеров ты выглядишь как ещё одна заблудшая душа которая думает что знает что-то до чего другие «не доросли». Уже не раз и не два на лоре такое видел.

Да понимаю я все. Да и не пофиг вовсе. Говорите что видели не раз такое - это уже интересно.

Я тебе поделюсь своим видением мира, хотя понимаю что тебе пофиг. Вначале был код аля простыня. Без функций, без ничего. Потом решили отдельные (а так же повторяющиеся) куски кода обособлять для удобства разработки и отладки. Так появились функции. Потом подумали-подумали и решили что часть функций можно выделить в библиотеки. Так появились библиотеки. Потом идея «разделяй и властвуй» развивалась дальше и функции и данные начали выделять в классы (что не отменило ни функций, ни библиотек). Попутно это дало прочие плюшки типа наследования. Но, по сути, ООП это способ организации и структурирования кода. Один из нескольких способов, какой из них лучше подходит выбирать тому кто пишет.

Все что вы сказали было осознано в конец студенчества как раз с освоением UML и осмыслением процесса программирования как инженерную дисциплину. Я так же думал и во времена ООП моего головного мозга.

Так вот, заявлать что ООП не нужен это глупо. Точно так же можно заявлять что не нужны, например, функции. Да что уж там, циклы тоже не нужны.

А я и не заявляю что оно глупо. А заявляю я (как и другой коллега - анон) следующее. Вот вы в лесу и срочно нужны вам дрова, а из колюще-режущих у вас только вилка (будем считать что лес бесконечен и хвороста, тонких веток и тонких деревьев в этом лесу нет). И что, в этом случае вы не будете использовать вилку для достижения цели (дрова) ? К чему этот пафос? - Это я пытаюсь так «тонко» намекнуть что ООП можно использовать всегда и везде так же как и как и вилку для добычи дров. Но есть способы лучше. Однако, абориген (в случае программирования это быдлокодер-неосилятор) который не знаком с ножовкой не сможет ее использовать пока не познакомится с ней.

PS а я не поленился, прошерстил инет на тему «недостатки ООП». Кроме тупого высера от громких имен из computer science и жалоб что «от этого кода сам писаться не начинает» и «нам не удалось сократить затраты на разработку в 10 раз» я больше ничего не нашёл.

Ищите «почему провалилось ООП» (или что-то в этом духе по ключевым словам). А также где-то на хабре совсем недавно была статья «я не понимаю ООП» (или что-то в этом духе также по ключевым словам).

anonymous
()
Ответ на: комментарий от anonymous

Вообще, ООП - отличный детектор непрофессионализма.

ООП-хейтерство - тоже.

segfault ★★★★★
()
Ответ на: комментарий от true_admin

примеры в студию
Возможно есть от чего. Я на внедрении проектов такого насмотрелся... При этом люди очень сильно гордились своими поделиями.

То есть ловили баттхерт? :)

Пилить реализацию ради потехни нецелесообразно. Я опишу на словах, а вы попробуйте сами реализовать. Если реализуете - я предложу вам вариант нестандартного использования ООП. Язык - С++. Чистый ООП - то есть никаких friend-функции и никаких хаков через полиморфные структуры нэймспейса.

Задача: Пусть у нас есть набор документов (бухгалерские, определенный набор). Нужна система для обработки данных. Как будем обрабатывать - пока не известно, какие данных из документов будет обрабатывать - тоже неизвестно.

anonymous
()
Ответ на: комментарий от anonymous

Железом. Микроконтроллеры, компиляторы для них, и т.п.

Контроллерами блоков питания? Да, там ООП не нужно.

До того работал в конторе, занимавшейся CAD-ами, там была такая же кадровая политика, ООП был (и остается) под запретом.

Три варианта: либо контора рипнулась в зародыше, либо занималась распилами, либо существовала только в твоем воображении.

А почему к сайтам вопросов нет? Казалось бы, чуть ли не единственная отрасль в индустрии, где ООП особо сильно навредить не может.

Это чуть ли единственная область ИТ, где ООП пока не нужно.

segfault ★★★★★
()
Ответ на: комментарий от harvos

Как не работал у меня tcmalloc с valgrind'ом, так и не работает

А чего не сработало? Ты опцию --soname-synonyms=somalloc=*tcmalloc*, я надеюсь, задал?

GArik ★★★
() автор топика
Ответ на: комментарий от anonymous

А для ООП тупо нет ни одной подходящей задачи. Вообще ни одной!

Хорошо искал?

Вот например, утилита, работающая со смарт-картами. В ее коде дофига функций, требующих установку соединения с карточкой, а в последствии - его разрыв (карточка - на разделяемый ресурс). Естественно, каждая функция имеет около десятка мест выхода. Я создаю класс «SmartCardConnection», в нем два метода - connect(...) и disconnect(...). В деструкторе условие: если подключен, то выполняется disconnect. Далее пользуюсь им и не беспокоюсь о том, что ресурс может быть не освобожден. Компилятор все делает за меня.

Если ООП здесь не уместно - предложите лучший вариант, без него.

Ну а во-вторых хотел бы видеть реализацию «умных указателей», лучшую, чем ООП-шная.

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

segfault ★★★★★
()
Ответ на: комментарий от anonymous

Ищите «почему провалилось ООП»

Прочитал и это и всё остальное. Я по-прежнему придерживаюсь мнения что пчёлы выступают против мёда. Я кроме как «да, это хорошо, но ведь это присуще не только ООП!» и «ошибки в программах при переходе на ООП никуда не делись!» ничего не увидел. Везде какие-то сферические кони в вакууме.

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

В общем, давай уже в студию код который демонстрирует ущербность ООП и превосходство твоей парадигмы. Остальное всё пустой трёп.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Язык - С++

фу таким быть.

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

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

true_admin ★★★★★
()
Ответ на: комментарий от segfault

предложите лучший вариант

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

или напишут что «главное это алгоритмы, остальное вторично»

Ага, а выбор парадигмы программирования - вообще «третично». И тем не менее, разразился вот такой вот... нездоровый спор.

segfault ★★★★★
()

Valgrind 3.8.0

Два батальона юных девственниц разработчикам этого чудесного инструмента.

red_eyed_peguin
()
Ответ на: комментарий от anonymous

Кстати, анон, что там с построением оконного интерфейса без объектов и их жалкого подобия на структурах и функциях? Иксы не нужны, да?

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

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

A-234 ★★★★★
()
Последнее исправление: A-234 (всего исправлений: 1)
Ответ на: комментарий от segfault

Ты не перди, тупица объектная, а реши конкретную задачу про дейталог. Слабо, сява?

anonymous
()
Ответ на: комментарий от segfault

И при чем тут ООП, сопля ты ничтожная? Достаточно правильной модульности.

Кстати, никакое ООП-говно не сравнится с модулями высшего порядка из SML.

anonymous
()
Ответ на: комментарий от true_admin

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

В общем, давай уже в студию код который демонстрирует ущербность ООП и превосходство твоей парадигмы. Остальное всё пустой трёп.

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

PS: Я другой аноним (не этот: anonymous (14.08.2012 16:36:32) ). Но и тут вы вольны для себя решить что-нибудь свое.

anonymous
()
Ответ на: комментарий от anonymous

Functional Reactive Programming, быдлятина.
И при чем тут ООП, сопля ты ничтожная? Достаточно правильной модульности.

Анон, дело говоришь. Но через транформацию мат. моделей задачи слабой формализации решаются гораздо проще (тут надо учитывать уровень подготовки испытуемого). Кстати, у модульности тоже имеет отражение на математическую модель (она неявная). Но особенно ярко выражена модель data flow. Приятно видеть человека без ООП голового мозга. Успехов.

anonymous
()
Ответ на: комментарий от segfault

Ну вот... покормил троллей - и двое лопнули. Теперь модераторам убирать... Я не хотел. Честно.

segfault ★★★★★
()
Ответ на: комментарий от true_admin

Язык - С++

фу таким быть.

Неосилил плюсы? С гвидобейсиком (пидоном) или жабой возвращайтесь туда откуда пришли.

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

Угу, да и какая структура документов будет тоже неизвестно.

Сказал же определенный набор. То есть определенный. То есть определено. Твой ООП-мозг снова не распарсил.

Ну считай я слился, твой супер-мега код в студию. Хотя мне уже очевидно что ты наркоман.

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

anonymous
()
Ответ на: комментарий от true_admin

или выход за границы массива понять в большинстве случаев просто

Это если нормальные массивы а не болото с указателями внутри, там ещё нужно подумать как пофиксить.

что-то мне не нравится код на котором 10кк ошибок выдаёт valgrind.

Циклы выполняющиеся много раз. Конечно, искать надо, на то он и опенсорс чтобы плодить баги и создавать базу для поддержки:)

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Циклы выполняющиеся много раз

так оно же мёрджит ошибки в одну которая повторилась n-раз :)

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

быдлятина

не кипятись, сладенький :). Ты только что научился двигать спрайты по канвасу, молодец. А иерархию виджетов как будешь делать? Ой-вей, шо такое иерахия, да? :) Ещё спроси для чего она нужна, ты можешь :)

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

ты диванный теоретик

Ага. А ты видимо телепат.

anonymous
()
Ответ на: комментарий от A-234

Короче, объектный недоносок эпично слил. Альтернативы дейталогу с bdd не нашел. Типично. Все быдлокодеры одинаково ничтожны.

anonymous
()
Ответ на: комментарий от anonymous

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Но до кода ты не дойдёшь. Ни ты, ни остальные аноны. Продолжайте дальше хвастаться своими несуществующими достижениями.

Ты ничего не понял или запутался. Коллега анон говорит тебе о существующих публичных техниках разработки которые лучше практически по всем параметрам в подавляющем большинстве «реальных» задач. Я же тебе говорю про мат модели которые являются отображением архитектурных решении, но техника разработки используется именно та о которой говорит рядом анон. Даже модульности хватит на все случаи жизни. В ООП совершенно нет необходимости тем более что на уровне принятия архитектурных решении ООП вносить слишком сильные искажения. Но быдлу на все это либо плевать, либо он просто не понимает о чем была речь.

anonymous
()
Ответ на: комментарий от true_admin

Но до кода ты не дойдёшь. Ни ты, ни остальные аноны.

И, кстати, насчет кода. Я таки хотел тебе продемонстрировать одну из «особых» техник использования ООП, но ты слился сразу. А барьер в виде «реализуй сначала ты и потом продемонстрирую» я поставил не случайно: подобный барьер моментально фильтрует ненужное быдло которое лишь ждет готовое решение тогда как сам пригоден лишь на удобрения. Для меня было несколько неожиданным то что ты отфильтровался (я был выше мнения). А все это делается по одной простой причине: на быдло время тратить не просто бесполезно. а часто вредно.

anonymous
()
Ответ на: комментарий от anonymous

Я таки хотел тебе продемонстрировать одну из «особых» техник использования ООП

«Санта Клаус дарит подарки только тем деткам, которые хорошо кушают» (ц)

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.