Здравствуйте, GhostCoders, Вы писали:
GC>Здраствуйте!
GC>Оцените плиз следующий лисапед.
"Что это было, Пух?" (с)
Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге".
Здравствуйте, GhostCoders, Вы писали:
GC>Здраствуйте!
GC>Оцените плиз следующий лисапед. GC>Как положительные так и отрицательные качества.
GC>Планирется Class1Impl сделать закрытым для пользователя (в другом заголовочном файле будет, тут только опережающее объявление оставить), GC>оставив для пользования только Class1.
Здравствуйте, shasa, Вы писали:
S>Не тому нынче учат в университетах. Учат городить велосипед, вместо того чтобы решать конкретные задачи.
Я не согласен, уметь решать задачи по рецепту — "Павлова", нажали кнопку получили профит — можно обучить даже... собаку.
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, k.o., Вы писали:
Z_>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
KO>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок. Z_>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA?
Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах.
Здравствуйте, GhostCoders, Вы писали:
GC>Для чего это нужно? Хотелось бы иметь умный указатель с подсчетом ссылок, который был бы свободен от следующего бага:
просто делаешь интрузивный подсчёт ссылок и будет тебе счастье...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
O>>>1. Оператор присваивания Class1 реализован некорректно, потому что не O>>>отрабатывает такую ситуацию: Z_>>
Z_>>Class1 a;
Z_>>a = a;
Z_>>
O>>>А так вроде все в порядке. Z_>>Если уж дотрахиваться до таких мелочей, то надо и на переполнение проверять)
KO>Ничего себе мелочь, UB в результате обычного вызова оператора присваивания. Это же совершенно обычный use-case. А для переполнения счётчика, нужно создать 2^16 объектов являющихся копией друг-друга, что, во-первых, выглядит, мягко говоря, странно, а во-вторых, невозможно (без дополнительных усилий) на машинах с разрядностью менее 64 бит.
Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
Здравствуйте, GhostCoders, Вы писали:
GC>а как сейчас поживает эта идиома? Насколько популярна?
Достаточно.
GC>Есть ли в ней смысл?
Если ты задаешь этот вопрос, тебе оно не нужно.
GC>Недостаток я вижу в том, что необходимо вручную дописывать свой враппер для каждого метода.
Недостатков вагон и маленькая тележка.
GC>Хотя можно переопределить -> оператор.
Это дзен которого боятся маги 80-го уровня, а ты пока даже не на 5-м.
Даже не думай!
GC>Для чего это нужно? Хотелось бы иметь умный указатель с подсчетом ссылок, который был бы свободен от следующего бага:
GC> boost::shared_ptr<A> sa(new A()); GC> boost::shared_ptr<A> sb(sa.get()); // Будет двойное удаление A
Это не баг, а непонимание. boost::shared_ptr<A> sb(sa);
Pimpl к умным ссылкам отношение прямого не имеет, он нужен для скрытия реализации.
Z_>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
KO>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок.
Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA? Мой мозг отказывается такое воспринимать принципиально, это уже признак говнокода — дальше смотреть можно, но нужно ли? Я еще понимаю по работе, когда за это деньги платят, и то повбывав бы, но за просто так себя насиловать? С трудом вынудил себя найти ту же архитектурно заложенную опасность целочисленного переполнения, но целиком анализировать всю идею кода, а тем более просчитывать все возможные ошибки... "На фиг, на фиг — к терапевту" (с) При таком похабном написании в коде еще и ни одного коммента, которые призваны как-то сглаживать проблемы понимания когда ничего больше не помогает. Препод-стайл — "я написал, я такой умный, а вы втыкайте в мои скрижали". Надо иметь какое-то уважение к читателям если хочешь нормальной реакции.
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, k.o., Вы писали:
Z_>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
KO>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок. Z_>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA? Мой мозг отказывается такое воспринимать принципиально, это уже признак говнокода — дальше смотреть можно, но нужно ли? Я еще понимаю по работе, когда за это деньги платят, и то повбывав бы, но за просто так себя насиловать? С трудом вынудил себя найти ту же архитектурно заложенную опасность целочисленного переполнения, но целиком анализировать всю идею кода, а тем более просчитывать все возможные ошибки... "На фиг, на фиг — к терапевту" (с) При таком похабном написании в коде еще и ни одного коммента, которые призваны как-то сглаживать проблемы понимания когда ничего больше не помогает. Препод-стайл — "я написал, я такой умный, а вы втыкайте в мои скрижали". Надо иметь какое-то уважение к читателям если хочешь нормальной реакции.
согласен бессмысленые названия можно юзать только в циклах i, j, ii, jj, x, y или для указателей p, q (и тут же их использовать) все остальное надо нормально обозначать
Z_>>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
KO>>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок. Z_>>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA? Мой мозг отказывается такое воспринимать принципиально, это уже признак говнокода — дальше смотреть можно, но нужно ли? Я еще понимаю по работе, когда за это деньги платят, и то повбывав бы, но за просто так себя насиловать? С трудом вынудил себя найти ту же архитектурно заложенную опасность целочисленного переполнения, но целиком анализировать всю идею кода, а тем более просчитывать все возможные ошибки... "На фиг, на фиг — к терапевту" (с) При таком похабном написании в коде еще и ни одного коммента, которые призваны как-то сглаживать проблемы понимания когда ничего больше не помогает. Препод-стайл — "я написал, я такой умный, а вы втыкайте в мои скрижали". Надо иметь какое-то уважение к читателям если хочешь нормальной реакции. J>согласен бессмысленые названия можно юзать только в циклах i, j, ii, jj, x, y или для указателей p, q (и тут же их использовать) все остальное надо нормально обозначать
ну в общем да. только я бы еще добавил, что для указателя можно использовать специальную переменную, типа my_pointer, а для итераторов, если их много и особенно если циклы вложены друг в друга, то тоже давать осмысленные имена — employee_iterator, manager_iterator.
Здравствуйте, GhostCoders, Вы писали:
GC>Недостаток я вижу в том, что необходимо вручную дописывать свой враппер для каждого метода.
Вообще, это конечно некоторая проблема PImpl в С++.
Но решение ТС ничего в ней не решает.
Есть два известных мне пути.
Путь 1. Описываем общую часть как-то так, что это описание используется ДВАЖДЫ.
Один раз для того, чтобы нагенерить публичную часть интерфейса, а другой раз для того, чтобы нагенерить часть реализации.
// хедер MyClassImpl.hclass MyClass::MyClassimpl {
public:
#include<BeginImpl.h>
#include"MyClass.h"#include<EndImpl.h>
private:
// тут, собственно private часть реализщации
};
Путь 2.
Пишется свой препроцессор, который по как-то размеченному хедеру с описанием реализации генерит хедер с реализацией PImpl- обёртки.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, GhostCoders, Вы писали:
GC>Оцените плиз следующий лисапед.
Нихрена не понятно зачем это вообще надо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, GhostCoders, Вы писали:
GC>>Здраствуйте!
GC>>Оцените плиз следующий лисапед. Z_>"Что это было, Пух?" (с) Z_>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге".
Очевидно же, что студент или что-то типа этого.
Самое время для написания лисапедов.
Здравствуйте, GhostCoders, Вы писали:
GC>Планирется Class1Impl сделать закрытым для пользователя (в другом заголовочном файле будет, тут только опережающее объявление оставить), GC>оставив для пользования только Class1. GC>...
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, k.o., Вы писали:
Z_>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок.
Z_>>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?
KO>>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок. Z_>>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA?
KO>Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах.
Как ваш пример читать, если названия переменных смысла не имеют? Значит на форумах обычно постят говнокод. Ну если всех устраивает — то пожалуйста, фапайте, я просто не в кугсе.
Оцените плиз следующий лисапед.
Как положительные так и отрицательные качества.
Планирется Class1Impl сделать закрытым для пользователя (в другом заголовочном файле будет, тут только опережающее объявление оставить),
оставив для пользования только Class1.
class Class1Impl
{
int mA;
int mRefCount;
public:
Class1Impl(): mA(0), mRefCount(1)
{
printf("Class1Impl::Class1Impl()\n");
}
virtual ~Class1Impl()
{
printf("~Class1Impl::Class1Impl()\n");
}
virtual void AddRef()
{
mRefCount++;
}
virtual void Release()
{
mRefCount--;
if (mRefCount <= 0)
delete this;
}
virtual void SetParamAImpl(int a)
{
mA = a;
}
virtual int GetParamAImpl() const
{
return mA;
}
};
class Class1
{
Class1Impl* mInternalImpl;
public:
Class1()
{
mInternalImpl = new Class1Impl;
}
Class1(const Class1& other): mInternalImpl(other.mInternalImpl)
{
if (mInternalImpl)
mInternalImpl->AddRef();
}
virtual ~Class1()
{
if (mInternalImpl)
mInternalImpl->Release();
}
virtual bool operator == (const Class1 & other) const
{
return mInternalImpl == other.mInternalImpl;
}
virtual bool operator != (const Class1 & other) const
{
return mInternalImpl != other.mInternalImpl;
}
virtual Class1 & operator = (const Class1 & other)
{
if (mInternalImpl)
mInternalImpl->Release();
mInternalImpl = other.mInternalImpl;
if (mInternalImpl)
mInternalImpl->AddRef();
return *this;
}
virtual void SetParamA(int a)
{
if (mInternalImpl)
mInternalImpl->SetParamAImpl(a);
}
virtual int GetParamA() const
{
int result = 0;
if (mInternalImpl)
result = mInternalImpl->GetParamAImpl();
return result;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
Class1 a;
Class1 b;
Class1 c;
a = c;
printf("abc!\n");
return 0;
}
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, okman, Вы писали:
O>>1. Оператор присваивания Class1 реализован некорректно, потому что не O>>отрабатывает такую ситуацию: Z_>
Z_>Class1 a;
Z_>a = a;
Z_>
O>>А так вроде все в порядке. Z_>Если уж дотрахиваться до таких мелочей, то надо и на переполнение проверять)
Ничего себе мелочь, UB в результате обычного вызова оператора присваивания. Это же совершенно обычный use-case. А для переполнения счётчика, нужно создать 2^16 объектов являющихся копией друг-друга, что, во-первых, выглядит, мягко говоря, странно, а во-вторых, невозможно (без дополнительных усилий) на машинах с разрядностью менее 64 бит.
Здравствуйте, GhostCoders, Вы писали: GC>Здраствуйте! GC>Оцените плиз следующий лисапед. GC>Как положительные так и отрицательные качества. GC>Планирется Class1Impl сделать ...
Не тому нынче учат в университетах. Учат городить велосипед, вместо того чтобы решать конкретные задачи.
Здравствуйте, dZentle_man, Вы писали:
KO>>Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах. Z_>Как ваш пример читать, если названия переменных смысла не имеют? Значит на форумах обычно постят говнокод.
Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции
Дабы закрыть эту тему, пока она не переросла в более абстрактную и холиварную, этот пост.
В примерах, традиционно, сущностям, не имеющим отношения к делу, даются более абстрактные имена: foo, bar, func, Class, SomeClass, data или чуть более конкретные, демонстрирующие смысловую нагрузку:
// Класс с типом type, являющимся ссылкой:struct SomeClassWithReferenceType {
typedef int& type;
};
// Просто какой-то класс, без ссылок:struct SomeClass {
typedef int type;
};
// И дальше описание какого-нибудь шаблонного трюка на этой основе с уже осмысленными именами.
// ...
— вообще f. Это не говнокод (в рабочем коде, конечно, критерии другие и там "foo/bar" смотрятся дико), это естественное разделение важных сущностей от неважных, т.к. всё остальное названо осмысленно.
Z_>Ну если всех устраивает — то пожалуйста, фапайте, я просто не в кугсе.
А никто и не фапает.
KO>>>Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах. Z_>>Как ваш пример читать, если названия переменных смысла не имеют? Значит на форумах обычно постят говнокод. AF>Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции
Очень осмысленное название.
AF>Дабы закрыть эту тему, пока она не переросла в более абстрактную и холиварную, этот пост.
AF>В примерах, традиционно, сущностям, не имеющим отношения к делу, даются более абстрактные имена: foo, bar, func, Class, SomeClass, data или чуть более конкретные, демонстрирующие смысловую нагрузку:
Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.
AF>Или пример здесь
— имя, не имеющее отношения к примеру — foo
А с чего вы взяли что счетчик mA не имеет отношения к делу? Мне, например, это совсем не очевидно при беглом взгляде на код. А читать вдумчиво уже неудобно, из-за нечитаемости кода.
Здравствуйте, dZentle_man, Вы писали:
Z_>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.
Ну что можно сказать? А то, что Вы не читали Страуструпа.
Сейчас открыл книжку Страуструпа "Язык программирования С++".
Листаю от начала,
первый пример кода более-менее, но третий такой:
#include"stack.h"// используем интерфейс стекаstatic char v [ stack_size ]; // "static" означает локальный
// в данном файле\модулеstatic char * p = v; // стек внчала пустvoid push( char c)
{
....
кусочек из пятого примера
void f()
{
шестой пример
class complex
{
double re, im;
седьмой
void f()
{
complex a = 2.3;
complex b = 1 / a;
complex c = a + b * complex( 1, 2.3 );
чуть далее:
class shape
{
...
kind k;
то есть почти каждый третий (или даже второй) пример содержит однобуквенные идентификаторы.
Открыл книгу Мейерса, "Наиболее эффективный С++".
Та же самая картина. Используются "f", "X", "x".
Открываем Саттера. Аналогичная картина.
Второе. Вызывает улыбку Ваша фраза "архитектурно заложенную ошибку переполнения счетчика..." и Ваши нечеловеческие усилия по обнаружению онной.
Вы не отличаете "архитектуру" от реализации.
Как то у меня был в стадии тестирования один молодой амбициозный человек. Претендовал на роль разработчика приложений на С++.
Говорил, что он мол бы работать менеджером проектов, так как прочитал много книг про управления проектами.
Много критиковал существующий код, писал в комментариях к существующему коду "THIS CODE IS VERY VERY VERY BAD" и т.д.
С ним у меня работать не получилось, я отказался от работы с ним.
Через пару лет, я связался с ним опять, и попросил его написать примеры использования одной библиотеки,
программы ва стиле "Hello, World!", так как все мы были заняты и отвлекаться на это времени не было.
Но он ответил, что не занимается уже С++, и целиком перешел на PHP и HTML, так как его уровень не достаточен для серьезной работы на С++.
Стиль Ваших реплик показывает, что Вы недалеко ушли от такого молодого человека.
Либо другое, то что Ваш уровень С++ может и не такой низкий, но Вы — типичный тролль. У вас самое главное оскорбить, унизить кого-то или что-то. Возможно, из-за комплекса неполноценности или каким-то другим причинам. А может из-за банального занудства.
Мне пришлось потратить около получаса своего высокооплачиваемого времени на написание ответа Вам.
НЕ КОРМИТЕ ТРОЛЯ! Больше ответа Вам я не напишу, не надейтесь!
Здравствуйте, dZentle_man, Вы писали:
AF>>Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции Z_>Очень осмысленное название. Z_>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.
"Data" — некая абстрактная полезная нагрузка, заглушка для примера. Намёк, что в рабочем коде здесь будут реальные данные с осмысленным именем.
А "понабирали" ( ) мы это с форумов, книг и собственных экспериментов, когда имя не важно, а важен тип или само присутствие сущности в коде (см. ссылки на сообщения, которые я привёл в прошлом посте). Уж что-что, а книги изобилуют такими именами . Беру Майерса, листаю — сходу нахожу абстратные Handle, a, b, c, d, e, n, d (последние два — вместо полных numerator, denumerator), f1, f2, temp1, temp2... А там, где автор хочет показать более конкретные примеры — Person, PersonInfo, DatabaseID. В соседнем сообщении у Страуструпа нашли много подобного (нет под рукой книги).
Ибо зачем нагружать читателя лишними подробностями? Абстракция.
обзовут FooBar — доставай линейку бить по рукам (с другой стороны, если этот же AddReference наравне с другими выступает в роли некоторого функтора (не важно какого) — FooBar будет вполне к месту).
AF>>Или пример здесь
— имя, не имеющее отношения к примеру — foo Z_>А с чего вы взяли что счетчик mA не имеет отношения к делу? Мне, например, это совсем не очевидно при беглом взгляде на код. А читать вдумчиво уже неудобно, из-за нечитаемости кода.
Да легко. Однобуквенное имя, не параметр шаблона + остальные функции включают в себя "A" как часть имени, оперируя с ним — значит, это некая полезная нагрузка.
Можно было назвать "A" "image", сделать ему соответствующий class Image и продемонстрировать работу на примере подсчёта ссылок на изображения. Но самым лучшим было бы написать в самом начале, для чего это нужно, чтобы мы не разбирались — с "A" оно работает, с картинками или ещё с чем Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.
Z_>>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.
GC>Ну что можно сказать? А то, что Вы не читали Страуструпа.
GC>Сейчас открыл книжку Страуструпа "Язык программирования С++". GC>Листаю от начала,
Бгг) Сколько неправды, наговора, неверных предпосылок и умозаключений в одном посте) От начала говорите листаете? Да кого вообще это начало интересует, до 5 главы, про классы? Читаем "предварительные замечания", первый же раздел — "структура книги": В главах 2, 3 и 4 описываются средства С++, которые не используются для определения новых типов:
основные типы, выражения и структуры управления. Другими словами, эти главы содержат описание
той части языка, которая по сути представляет С.
Первая же глава — это краткое описание языка, хотя по содержанию это еще и из-рук-вон-описание, не обладающей ни краеугольной полнотой изложения, ни систематичностью, способствующей первично вникнуть в суть языка — только свалка надерганных кусков и фраз. Да, не самая удачная глава книги, и вообще страуструп пишет довольно заумно, но тем не менее — вы бы знали об этом, если бы сами потрудились его прочитать)
GC>первый пример кода более-менее, но третий такой: GC>
GC> #include"stack.h"// используем интерфейс стека
GC> static char v [ stack_size ]; // "static" означает локальный
GC> // в данном файле\модуле
GC> static char * p = v; // стек внчала пуст
GC> void push( char c)
GC> {
GC> ....
GC>
Опять же, вы сравните — десять строчек у него, и 50 у вас. Причем у него логика сосредоточена в этих 10 строчках, а у вас она прокинута между всеми 50. То, что вы не видите разницы — говорит лишь о том, что вы вообще плохо себе представляете как пишется читаемый код, и почему один код читаемее другого.
GC>кусочек из пятого примера
GC>
GC>void f()
GC>{
GC>
К функции f() в этом коде нет ни одного обращения — это просто объявление функции, его вообще могло бы и не быть, и код не утратил бы наглядности.
GC>шестой пример
GC>
GC>class complex
GC>{
GC> double re, im;
GC>
Ну что вы хотите — да, у него тоже хватает говнокода. Но вы сами нашли первый адекватный пример этому на шестом примере — если бы у вас статистика была похожей, я бы не стал придираться.
GC>то есть почти каждый третий (или даже второй) пример содержит однобуквенные идентификаторы.
Если бы у вас в коде каждая вторая переменная была бы читаемой — код был бы в два раза понятнее.
GC>Открыл книгу Мейерса, "Наиболее эффективный С++". GC>Та же самая картина. Используются "f", "X", "x". GC>Открываем Саттера. Аналогичная картина.
Идем в подворотню — там пасаны колются — делаем то же самое. Че, пример маргинальный? Идем в голливуд — там кокаин нюхают — делаем то же самое.
GC>Второе. Вызывает улыбку Ваша фраза "архитектурно заложенную ошибку переполнения счетчика..." и Ваши нечеловеческие усилия по обнаружению онной. GC>Вы не отличаете "архитектуру" от реализации.
А вот это уже голословное утверждение) Вы архитектурно выбрали целочисленный тип для хранения данных счетчика, так и реализовали. Или вы начинаете думать какую же переменную взять на стадии реализации, когда уже пишите код?
GC>Как то у меня был в стадии тестирования один молодой амбициозный человек. Претендовал на роль разработчика приложений на С++. GC>Говорил, что он мол бы работать менеджером проектов, так как прочитал много книг про управления проектами. GC>Много критиковал существующий код, писал в комментариях к существующему коду "THIS CODE IS VERY VERY VERY BAD" и т.д.
Я вам конкретно сказал чем плох ваш код, а не вери-вери бэд. Хотя вы даже в этом не видите отличия)
GC>С ним у меня работать не получилось, я отказался от работы с ним.
Я бы тоже отказался от работы с человеком, чьи комментарии в коде сводятся к "THIS CODE IS VERY VERY VERY BAD".
GC>Через пару лет, я связался с ним опять, и попросил его написать примеры использования одной библиотеки, GC>программы ва стиле "Hello, World!", так как все мы были заняты и отвлекаться на это времени не было. GC>Но он ответил, что не занимается уже С++, и целиком перешел на PHP и HTML, так как его уровень не достаточен для серьезной работы на С++.
То есть ваш код, в котором не происходит валидации данных для страховки от переполнения, пригоден для серьезной работы?
GC>Стиль Ваших реплик показывает, что Вы недалеко ушли от такого молодого человека.
Скорее уж ваших)
GC>Либо другое, то что Ваш уровень С++ может и не такой низкий, но Вы — типичный тролль. У вас самое главное оскорбить, унизить кого-то или что-то. Возможно, из-за комплекса неполноценности или каким-то другим причинам. А может из-за банального занудства.
Сколько возможных объяснений одного, вами же высказанного предположения) Я вам конкретно сказал чем код плох, и остановился на этом. Вас же прорвало. На мой взгляд это может говорить о том, что вы не привыкли, не умеете и не считает нужным писать читаемый код, да еще и плохо воспринимаете конструктивную критику. А между тем критики и просили.
GC>Мне пришлось потратить около получаса своего высокооплачиваемого времени на написание ответа Вам.
Вам еще и деньги за такой код платят? Это где так, интересно?
GC>НЕ КОРМИТЕ ТРОЛЯ! Больше ответа Вам я не напишу, не надейтесь!
Ах, я теперь уже стопудовый тролль, уже точно не ламер в плюсах? Будь я модератором — банил бы тех, кто поминает слово "тролль", потому что поминают его те, кто на самом деле не знают что такое троллинг.
AF>>>Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции Z_>>Очень осмысленное название. Z_>>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости. AF>"Data" — некая абстрактная полезная нагрузка, заглушка для примера. Намёк, что в рабочем коде здесь будут реальные данные с осмысленным именем.
Почему не обозвать как ObjectCounter? Почему я должен думать зачем нужна ваша Data?
AF>А "понабирали" ( ) мы это с форумов, книг и собственных экспериментов, когда имя не важно, а важен тип или само присутствие сущности в коде (см. ссылки на сообщения, которые я привёл в прошлом посте).
Я пока что таких кодов не видел, где это не важно.
AF>Уж что-что, а книги изобилуют такими именами . Беру Майерса, листаю — сходу нахожу абстратные Handle, a, b, c, d, e, n, d (последние два — вместо полных numerator, denumerator), f1, f2, temp1, temp2...
Это пример плохого программирования. Вы классический труд Кернигана с Ритчи открывали? Они там на первых же страницах рекомендуют давать переменным осмысленные имена. Да, идея не очень очевидная для начинающего, но они правильно говорят, потому что уже собаку на кодинге съели. Ну да, применение перменных типа a, b, c встречается у всех, в том числе и у Кернигана с Ритчи, и у страуструпа. Но, во-первых, обычно пример в книге — это 5-10 строчек кода, а во-вторых, читаемость это не всегда улучшает даже в таких небольших кусочках кода. А ТС вывалил 50 строк.
— имя, не имеющее отношения к примеру — foo Z_>>А с чего вы взяли что счетчик mA не имеет отношения к делу? Мне, например, это совсем не очевидно при беглом взгляде на код. А читать вдумчиво уже неудобно, из-за нечитаемости кода. AF>Да легко. Однобуквенное имя, не параметр шаблона + остальные функции включают в себя "A" как часть имени, оперируя с ним — значит, это некая полезная нагрузка.
Вообще-то, если говорить о стандартных обозначениях, то A — используется как знак работы с ANSI-строками, что меня, например, вводит в заблуждение когда я смотрю на функцию SetParamAImpl(int a).
AF>Можно было назвать "A" "image", сделать ему соответствующий class Image и продемонстрировать работу на примере подсчёта ссылок на изображения. Но самым лучшим было бы написать в самом начале, для чего это нужно, чтобы мы не разбирались — с "A" оно работает, с картинками или ещё с чем
Зачем придумывать применение, когда можно сделать абстрактное название, которое передаст суть объекта, и подойдет в любом случае — с чем бы мы ни работали — с изображениями, музыкой или текстами? Например Parameter? Тогда даже название функции SetParamAImpl(int a) упростилось бы до SetParamImpl(int ParameterValue).
AF>Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.
Если давать адекватные названия, то не нужно никаких описаний и, тем более, выдуманных прикладных областей. А вот если наоборот, то даже описания и подробные комменты не так уж сильно помогают.
Здравствуйте, dZentle_man, Вы писали:
Есть такое заболевание называется "псевдоинтелектуальность"
Покажи пример, когда ты сможешь переполнить рефкаунтер представленый 32 битным целым числом в 32 битной системе.
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, GhostCoders, Вы писали:
GC>>Здраствуйте!
GC>>Оцените плиз следующий лисапед. Z_>"Что это было, Пух?" (с) Z_>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге".
А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто.
[Цитаты не по порядку]
Z_>Почему не обозвать как ObjectCounter? Почему я должен думать зачем нужна ваша Data?
А он там не исполняет роль ObjectCounter'а, но это не важно, т.к.:
Z_>Зачем придумывать применение, когда можно сделать абстрактное название, которое передаст суть объекта, и подойдет в любом случае — с чем бы мы ни работали — с изображениями, музыкой или текстами? Например Parameter? Тогда даже название функции SetParamAImpl(int a) упростилось бы до SetParamImpl(int ParameterValue).
Вот и нашли довольно абстрактное имя, тем не менее передающее суть предмета .
Собственно, за подобные имена в примерах я выступаю — когда они к месту, конечно. Разве что на "Data" меня заклинило и я ушёл в offtop относительно изначального поста.
Z_>Вообще-то, если говорить о стандартных обозначениях, то A — используется как знак работы с ANSI-строками, что меня, например, вводит в заблуждение когда я смотрю на функцию SetParamAImpl(int a).
Если бы в коде было WinAPI, я бы тоже об это споткнулся. А так мы уже выяснили, что название было неудачным.
Z_>Я пока что таких кодов не видел, где это не важно.
Да много примеров, связанные с демонстрацией потрохов языка. Таких как я приводил по ссылкам или, особенно, в началах книг по какому-либо языку, когда объясняют синтаксис и основы. Допустим, автор хочет показать следующий синтаксис:
if( void* ptr = f() ) { // и не стал придумывать ничего сложнее ptr и f, хотя и мог
// ...
}
А вот если этот кусок будет не сам по себе, а внутри сложной ф-ции, выполняющей осмысленные действия — это будет отвратительно .
Z_>Это пример плохого программирования. Вы классический труд Кернигана с Ритчи открывали? Они там на первых же страницах рекомендуют давать переменным осмысленные имена. Да, идея не очень очевидная для начинающего, но они правильно говорят, потому что уже собаку на кодинге съели. Ну да, применение перменных типа a, b, c встречается у всех, в том числе и у Кернигана с Ритчи, и у страуструпа.
Даже спорить не о чем. Не только Керниган с Ритчи, но и каждый второй автор расписывает преимущества осмысленных имён. И это правильно — чем быстрее новичок уйдёт от "кулхацкерских" __XxX______, _$$$abc, a, b, x, xx — тем лучше.
Z_>Но, во-первых, обычно пример в книге — это 5-10 строчек кода, а во-вторых, читаемость это не всегда улучшает даже в таких небольших кусочках кода.
Важное дополнение — примеры с такими именами должны быть маленькими и "сами по себе"
Z_>А ТС вывалил 50 строк. Z_>Если давать адекватные названия, то не нужно никаких описаний и, тем более, выдуманных прикладных областей. А вот если наоборот, то даже описания и подробные комменты не так уж сильно помогают.
ИМХО, даже с именем parameter для примера в 50 строк на C++ надо было дать сопроводительные комментарии вида "зачем это всё нужно". Ибо 50 строк — не 5-10, и код для форума: даже с внятными именами надо сидеть, разбираться и угадывать, что на самом деле хотел автор. Впрочем, повторяюсь: AF>>Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.
Здравствуйте, IROV.., Вы писали:
IRO>Здравствуйте, dZentle_man, Вы писали:
Z_>>Если уж дотрахиваться до таких мелочей, то надо и на переполнение проверять) Z_>>
IRO>Здравствуйте, dZentle_man, Вы писали: IRO>Есть такое заболевание называется "псевдоинтелектуальность"
Вообще то болезнями обычно интересуются когда у самих здоровье подорвано...
IRO>Покажи пример, когда ты сможешь переполнить рефкаунтер представленый 32 битным целым числом в 32 битной системе.
А кто сказал что мы запускаем код на 32-битной системе? А если мы сделаем правку когда счетчик сможет посчитать так, что его переполнит? Вы еще скажите, что это нормально — оставить переменную без валидации если в обозримом будущем ничто не угрожает переполнением? Валидация данных — это краеугольный камень построения безглючных и безопасных приложений. Проверяются все данные, без исключения. Мы не всегда может просчитать все возможные варианты и последствия, но всегда можем предусмотреть проверку. Но, я опять же, сказал, что в данном случае — это дотрахиваться до мелочей, то есть я не считаю это самой большой проблемой этого кода.
GC>>>Здраствуйте!
GC>>>Оцените плиз следующий лисапед. Z_>>"Что это было, Пух?" (с) Z_>>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге". IRO>А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто.
С _такими_ велосипедами и правда — и голова будет болеть, и пузо будет урчать.
Здравствуйте, dZentle_man, Вы писали:
IRO>>Покажи пример, когда ты сможешь переполнить рефкаунтер представленый 32 битным целым числом в 32 битной системе. Z_>А кто сказал что мы запускаем код на 32-битной системе?
На других 64-битных системах будем использовать 64 битные целые числа.
А на других, другое.. и это норма.
Z_>А если мы сделаем правку когда счетчик сможет посчитать так, что его переполнит? Вы еще скажите, что это нормально — оставить Z_>переменную без валидации если в обозримом будущем ничто не угрожает переполнением? Валидация данных — это краеугольный камень Z_>построения безглючных и безопасных приложений. Проверяются все данные, без исключения. Мы не всегда может просчитать все возможные Z_>варианты и последствия, но всегда можем предусмотреть проверку. Но, я опять же, сказал, что в данном случае — это дотрахиваться до Z_>мелочей, то есть я не считаю это самой большой проблемой этого кода.
Я не вижу тут ответа на вопрос, троллизм в чистом виде. А если, а представте, а что если прилетит НЛО! А вдруг ктото пропишет по памяти. И куча других нелепых ситуаций не касающихся вопросу, прошу не писать.
Покажи ситуацию когда ты сможешь переполнить рефкаунтер.
Здравствуйте, dZentle_man, Вы писали:
Z_>Здравствуйте, IROV.., Вы писали:
GC>>>>Здраствуйте!
GC>>>>Оцените плиз следующий лисапед. Z_>>>"Что это было, Пух?" (с) Z_>>>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге". IRO>>А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто. Z_>С _такими_ велосипедами и правда — и голова будет болеть, и пузо будет урчать.
а что в __этом__ велосипеде такого страшного??
Интересно было посмотреть на __твои__ кошерные велосипеды тогда, и щас. Хотя я думаю можно и щас.
Интересно у тебя есть своя мало мальски интересная — зделаная тобой библиотека, контейнер, и еще чтото, на что можно вглянуть.
Z_>>Почему не обозвать как ObjectCounter? Почему я должен думать зачем нужна ваша Data? AF>А он там не исполняет роль ObjectCounter'а, но это не важно, т.к.:
Вот именно, что не понятно зачем он нужен. А из нечитаемого кода это понятнее не становится.
Z_>>Зачем придумывать применение, когда можно сделать абстрактное название, которое передаст суть объекта, и подойдет в любом случае — с чем бы мы ни работали — с изображениями, музыкой или текстами? Например Parameter? Тогда даже название функции SetParamAImpl(int a) упростилось бы до SetParamImpl(int ParameterValue). AF>Вот и нашли довольно абстрактное имя, тем не менее передающее суть предмета .
Ну Parameter хотя бы может быть и свойством предмета, а Data — это уже скорее какие-то данные, которые еще не понятно зачем могут быть нужны.
Z_>>Я пока что таких кодов не видел, где это не важно. AF>Да много примеров, связанные с демонстрацией потрохов языка. Таких как я приводил по ссылкам или, особенно, в началах книг по какому-либо языку, когда объясняют синтаксис и основы. Допустим, автор хочет показать следующий синтаксис: AF>
AF>if( void* ptr = f() ) { // и не стал придумывать ничего сложнее ptr и f, хотя и мог
AF> // ...
AF>}
AF>
AF>А вот если этот кусок будет не сам по себе, а внутри сложной ф-ции, выполняющей осмысленные действия — это будет отвратительно .
Z_>>Это пример плохого программирования. Вы классический труд Кернигана с Ритчи открывали? Они там на первых же страницах рекомендуют давать переменным осмысленные имена. Да, идея не очень очевидная для начинающего, но они правильно говорят, потому что уже собаку на кодинге съели. Ну да, применение перменных типа a, b, c встречается у всех, в том числе и у Кернигана с Ритчи, и у страуструпа. AF>Даже спорить не о чем. Не только Керниган с Ритчи, но и каждый второй автор расписывает преимущества осмысленных имён.
Вот именно, но эти два — это просто классика, как можно считать себя знающим язык не открывая труда его создателей?
AF>И это правильно — чем быстрее новичок уйдёт от "кулхацкерских" __XxX______, _$$$abc, a, b, x, xx — тем лучше.
Именно.
Z_>>Но, во-первых, обычно пример в книге — это 5-10 строчек кода, а во-вторых, читаемость это не всегда улучшает даже в таких небольших кусочках кода. AF>Важное дополнение — примеры с такими именами должны быть маленькими и "сами по себе"
Именно.
Z_>>А ТС вывалил 50 строк. Z_>>Если давать адекватные названия, то не нужно никаких описаний и, тем более, выдуманных прикладных областей. А вот если наоборот, то даже описания и подробные комменты не так уж сильно помогают. AF>ИМХО, даже с именем parameter для примера в 50 строк на C++ надо было дать сопроводительные комментарии вида "зачем это всё нужно".
Да, они желаетельны. Вообще не понятно на что можно рассчитывать вываливая нечитаемый код без комментов. Но наверное там где хорошо оплачивают время это в порядке вещей.
AF>>>Ибо 50 строк — не 5-10, и код для форума: даже с внятными именами надо сидеть, разбираться и угадывать, что на самом деле хотел автор. Впрочем, повторяюсь: AF>>>Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.
С одной стороны да. С другой — насколько внятным было бы это описание? Стал бы автор объяснять действительно нужные моменты, или он набросал бы пару абзацев булшита чтобы поставить галочку "описание — есть"? Впрочем меня эта тема не так уж интересует, я сказал свое мнение один раз — код нечитаемый, а остальное — уже в ответ на объснение мне что я не прав.
Z_>>А если мы сделаем правку когда счетчик сможет посчитать так, что его переполнит? Вы еще скажите, что это нормально — оставить Z_>переменную без валидации если в обозримом будущем ничто не угрожает переполнением? Валидация данных — это краеугольный камень Z_>построения безглючных и безопасных приложений. Проверяются все данные, без исключения. Мы не всегда может просчитать все возможные Z_>варианты и последствия, но всегда можем предусмотреть проверку. Но, я опять же, сказал, что в данном случае — это дотрахиваться до Z_>мелочей, то есть я не считаю это самой большой проблемой этого кода. IRO>Я не вижу тут ответа на вопрос, троллизм в чистом виде.
Троллизм в чистом виде — это обвинять в троллизме на пустом месте.
IRO>А если, а представте, а что если прилетит НЛО!
Вот, это тоже троллизм.
IRO>А вдруг ктото пропишет по памяти.
И это троллизм.
IRO>И куча других нелепых ситуаций не касающихся вопросу, прошу не писать.
И это. Сами в баню пойдете или банщика позвать?
IRO>Покажи ситуацию когда ты сможешь переполнить рефкаунтер.
Я сказал что есть опасность. А для того чтобы оценить насколько она реальна — надо курить код, который нечитаемый. Для того чтобы избегать возможных проблем — проводят валидацию, всех аргументов, всегда.
GC>>>>>Здраствуйте!
GC>>>>>Оцените плиз следующий лисапед. Z_>>>>"Что это было, Пух?" (с) Z_>>>>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге". IRO>>>А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто. Z_>>С _такими_ велосипедами и правда — и голова будет болеть, и пузо будет урчать. IRO>а что в __этом__ велосипеде такого страшного??
А вы выше почитайте прежде чем в десятый раз спрашивать одно и то же.
IRO>Интересно было посмотреть на __твои__ кошерные велосипеды тогда, и щас. Хотя я думаю можно и щас. IRO>Интересно у тебя есть своя мало мальски интересная — зделаная тобой библиотека, контейнер, и еще чтото, на что можно вглянуть.
Какие бы у меня ни были велосипеды, мои претензии к данному коду — конкретны и по делу. А ваше соскальзывание с темы плюс наезды — повадки бывалого, матерого, толстого тролля. Кормежка окончена.
Здравствуйте, dZentle_man, Вы писали:
IRO>>И куча других нелепых ситуаций не касающихся вопросу, прошу не писать. Z_>И это. Сами в баню пойдете или банщика позвать?
Маму позови.
IRO>>Покажи ситуацию когда ты сможешь переполнить рефкаунтер. Z_>Я сказал что есть опасность.
Если уж дотрахиваться до таких мелочей, то надо и на переполнение проверять)
Z_>А для того чтобы оценить насколько она реальна — надо курить код, который нечитаемый.
Есть желание есть тысячи возможностей, нет желаний есть тысячи проблем.
Z_>Для того чтобы избегать возможных проблем — проводят валидацию, всех аргументов, всегда.
Аргументов? я боюсь спросить каким образом рефкаунтер относиться к аргументам.
Да и опять я не получил от вас признания что Вы просто погорячились, и ляпнули, не подумавши.
Здравствуйте, dZentle_man, Вы писали:
Z_>А вы выше почитайте прежде чем в десятый раз спрашивать одно и то же.
Я спросил в первые, да и я не вижу что в нем страшного как для велосипеда
Человек решил покапаться в какомто патерне навоял себе "от руки" какойто код, его чтото начало смущать он напостил сюда
то что он немного невежливо отнесся к нам читателям это факт, но тот кто такое делал не раз его поймет.
да и на самом делел может он просто не такой матерый программист что бы видеть в этом какоето зло.
Z_>Какие бы у меня ни были велосипеды, мои претензии к данному коду — конкретны и по делу.
Тоесть либо их нету, или вы стесняетесь их показать? Понимаю
Z_>А ваше соскальзывание с темы плюс наезды — повадки бывалого, матерого, толстого тролля. Кормежка окончена.
Таков я, наезжаю вечно на всех, наверное я бывалый матерый толстый троль