- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
void AClass::registerApplication( int pCaller )
{
if ( mRegistry == NULL )
{
// we will be the first application in registry
mRegistry = createRegistryElement( pCaller );
}
else
{
// there are other applications already registered
// first create registry entry
Application *lApplication = NULL;
lApplication = createRegistryElement( pCaller );
// put entry in front
lApplication->mNext = mRegistry;
mRegistry = lApplication;
}
}
добавляем новый элемент в односвязный список. mRegister голова списка. кто не видит говна - идти читать матчасть.
Follow us!
Не хватает многопоточной синхронизации?
подсказка. добавление в односвязный список можно делать совсем без if'ов.
слегка подразжую: что произойдет в else ветке, если mRegistry будет NULL?
>слегка подразжую: что произойдет в else ветке
Зачем писать велосипед с квадратными колесами, если уже есть с круглыми? Берите STL\QT\BOOST или ещё откуда угодно и используйте.
поинтеры там нестандартные используются - но я это говно высокоэтажное перед постом сюда убрал. оно ни смешно, ни загадачно, ни интересно - а просто говно.
Не оправдание.
1)В списке не обязан храниться сам элемент, можно, например, указатель или врапер.
2)STL, как и другие библиотеки, позволяет указывать свои аллокаторы.
3)В конце концов, всегда в С++ можно переопределить operator new.
>(что бы к ним можно было доступатся из многих процессов)
Тут не видно, но многозадачная синхронизация на добавление элементов списка точно есть?
Если в между строкамипроизойдет переключение задач, то это будет эпичный фейл.
Я вот в душе минималист и перфекционист, я лучше завелосипедю свой маленький контейнер, чем потяну в проект мегабайты какого-то говна, над которым ещё плясать надо, чтобы скомпилировалось.
>10ком практически одинаковых контейнеров
Фактически мне это напоминает обычную копипасту новичков, только скрытую.
Как приятно, когда по всему проекту, в том числе и в сторонних библиотеках, используется одинаковый набор контейнеров, а не 10 практически одинаковых наборов контейнеров.
Я имею введу семантические различия в контейнерах, а не синтаксические или прочие, например list и vector - семантически разные контейнеры.
В Qt отличный дизайн, но это слишком тяжеловесная dependency.
Линус вон внушает (http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918), что давно пора
># cat /lang/c++ > /dev/null
># cat /lang/c > /dev/head
Старый маразматик и консерватор... Замедляет развитие ОС... :(
P.S. Юзайте Haiku, там всё на С++.
А если бы не тщеславие Линуса — было бы ядро под BSD или MIT, с аналогичным развитием драйверов. Тут уж о тивоизации говорить смешно.
он открыто одобряет тивоизацию
Статься доставляет. Написано правильно, в начале вежливо, а когда позиция целиком опровергнута появляются строчки "The amount of bullshit he writes, once again, is just amazing" : )
в с++ шаблоны и виртуальные функции очень полезны. а остальное -- фуфло, особенно стандартные классы. то бишь, если язык чё-то предлагает, это не значит что нужно абсолютно всё тащить в рот.
?
Application* AClass::registerApplication( int pCaller )
{
if ( Application *lApplication = createRegistryElement( pCaller ) ) {
return mRegistry ? lApplication->mNext = mRegistry, mRegistry = lApplication : mRegistry = lApplication;
};
return NULL;
}
Бляя.. Ну и нотация. Уволил бы нах.
В многопоточности еще нужно ввести и ожидание, где первое событие - это прерывание приложения, а второй - освобождение списка, или тупой лок. Ну или семафор, пофиг.
А программист от говнокодера отличается тем, что обрабатывает все и возможные реакции, а не тупо пишет a = new (...); a->c = n; Типа памяти до хрена. Допусти такого до тонких или встроенных клиентов - похоронит же все. Вот пример настоящего говнокодера, не стесняющегося понтово публиковать свой говнокод.
И от говнокоментатора он отличается тем, что не делает предположений на пустом месте. Вы написали
> А что будет, если createRegistryElement вернет NULL?
Это ваши фантазии и предположения. createRegistryElement может никогда не возвращать NULL by design. Также как может бросать исключение в случае ошибки.
Ваша поправка высосана из пальца и к говнистости оригинального говнокода отношения не имеет.
От себя добавлю, рабочий в большинстве ситуаций.
P.S. Спецификацию исключений обязательно декларируют - признак хорошего тона a::b /* throw .. */
> Короче мне фиолетово.
Фиолетово на стандарт? Без комментариев.
2.
То что творится в вашей голове - это просто невообразимый пиздец. Если я написал функцию которая не возвращает 0 никогда, задокументировал это поведение и пользуюсь им - то это говнокод?
3.
Спецификации исключений как минимум бесполезны. Даже из зарегистрированного unexpected_handler можно разве что завершить приложение. Ни о каком graceful recovery не может быть и речи. А например в шаблонах они просто вредны. Кто знает что бросит тип использованный клиентом?
Признаком хорошего тона Спецификации исключений являются только в вашей голове. Все ведущие специалисты не рекомендуют их использовать.
Например Герб Саттер:
http://www.gotw.ca/gotw/082.htm
4.
> Удачи.
Уже сливаетесь? Печаль... Ато бы повеселили посетителей сайта ещё вашими глупостями. На то ведь и говнокод : )
Мне вас жаль : ( Так уж и быть объясню вам неразумному: Трай-кэч там где можно обработать ошибку и восстановить ход выполнения прорамы. Это место не обязано совпадать с функцией registerApplication.
Вы, видимо, никогда не работали на больших проектах, где десятки людей много лет пишут одну систему - что дали, то и пишут. Суть в том, что программист обязан думать в рамках функции, как о замкнутой системе. А by design - это ему модель дали, кого вызывать и кого звать, а не рассказали, что "ниможыт вернуть нуль!!!111". Программист обязан обработать все и возможные исключения и ошибки. А Вы, уж простите, пытающийся выкрутиться говнокодер.
За сим прощаюсь.
Думать за других как раз пытаетесь вы. Программист обязан Реализовать порученный ему модуль в рамках технического задания. И сделать его поддерживаемым и читаемым.
Вылетает исключение - поймай его в подходящем месте до интефейса, не можешь/не нужно сделай исключение частью интерфейса - задокументируй.
Вы видимо слишком много потратили времени в ваших "больших проектах". И представления об дизайне и архитектуре системе подменили парой говнокодерских правил типо "всегда лови исключения в каждой функции". Вы не умеете пользоваться инструментами, о которых разговариваете.
> программист обязан думать в рамках функции, как о замкнутой системе
Вы вообще с модификаторами доступа знакомы? Частная функция тоже обязана это делать? Функции класса спрятанного от клиента тоже вам обязаны?
По вашим кусочкам кода и комментариям складывается ощущение что вы не знакомы с элементарным ООП. Отсюда и перлы про "функцию как замкнутую систему", отсутствие представления об exception safety, желание переплести код отвечающий за нормальное выполнение программы с кодом отвечающим за обработку ошибок.
Вы так ничего и не поняли. Только выкручиваетесь. Я кривовато, но пытаюсь до Вас донести парадигмы defensive programming. То есть крайне необходимо вставлять код обработки "невозможных" случаев, которые теоретически не должны случиться, но из-за косяков или рантайм сбоя где-то в другом участке программы (Вы же не один пишите? Железки чего, не сбоят? Стек кармически не портится?) - случаются. Кто знает, что там Пупкин, уволившийся год назад написал? И вроде модель говорит, что невозможно - ан нет...
Кстати судить по двум строкам об уровне - это мощно. Внушает. Вангой в свободное время не подрабатываете? :)
Про вангу замечание совершенно не по адресу, первая оценка уровня было от вас и на мои три строчки кода. Ещё и с предложением "убивать нах".
А оголтелое defensive programming до добра не доводит. То есть наличие чудака, который способен написать
Не оправдывает повсеместное использование конструкций
Эти конструкции настолько засрут код, что поддерживать и искать ошибки станет невозможно. Это как носить стальной зонтик, вдруг метеорит упадёт.
Такой подход может быть оправданным, но в очень редких случаях.
С такими убеждениями вам надо писать на пуре ц. В ц++ ваши убеждения идут в разрез с общепирнятыми практиками.
a = new myClass;
a->c = n;
при условии конечно что в myClass не переопределён operator new со спецификацией throw() ?
unless an allocation function is declared with an empty exception-specification (15.4), throw(), it
indicates failure to allocate storage by throwing a bad_alloc exception (clause 15, 18.4.2.1); it returns a non-null pointer otherwise.
По данному куску кода проверить порядок выхода элементов из контейнера мы не можем.
Может они вообще никогда оттуда не выходят до завершения приложения.
Мне в обсуждении больше всего доставило что в двух самых длинных лесенках говорилось примерно об одном и том же, только с разных сторон.
Доо, мой аватар