Home
Заметки перфекциониста
Свежий бред 

Реклама

Настроить
9-Фев-2009 11:37 pm - The Zen of Python [python, программинг]
The Zen of Python Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one and preferably only one obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
Qt becomes LGPL licensedКомпания Nokia объявила, что начиная с версии 4.5 (ориентировнчно март 2009) платформа Qt будет доступна также под лицензией LGPL 2.1.
Это означает что разработчики могут использовать более либеральную, по сравнению с GPL, схему лицензирования. Другими словами, это даcт возможность бесплатно использовать библиотеку Qt для коммерческого ПО.

За столь щедрым жестом компании стоит тот факт, что в отличии от Trolltech, Nokia не ставит целью заработать на Qt. Ее стратегия продолжает линию «10х», анонсированную в прошлом году, суть которой сводится к десятикратному увеличению количества разработчиков и пользователей библиотеки. Такая популяризация позволит компании расширить клиентскую базу именно за счет большего числа коммерческих разработчиков и является заключительным этапом кампании «Qt повсюду» ("Qt Everywhere").
____

Бесплатно — это хорошо, но что дальше? Дальше есть надежада, что Embarcadero все же сможет включить поддержку Linux в следующей версии Delphi (Comodore, середина 2010-го года). Ну или в следующей.

На самом деле, это может означать, мы, наконец, сможем получить основательно преработанную и "подчищенную" CLX позволяющую писать кроссплатформенные программы, в нативном для платформы коде. Это означает, что заброшенный Kylix может возродится.

Но пойдем дальше. Если архитектура компонентов Delphi будет пересмотрена в пользу возможности создания настоящих Qt виджетов, то выиграют все. Embarcadero сможет расширить свою базу клиентов за счет компоненто-писателей для Qt. А те тоже будут плодится как грибы в благоприятных условиях — это как освоение целины: Qt не имеет большого выбора из сторонних компонентов, и такие компании как DevExpress или ТМС, смогут сделать неплохой апгрейд к ее базе виджетов. Ну и по понятным причинам выиграет сама Qt.
Нифига себе! Незнал что такая штука работает в дельфе:

case i of
 0: ;
 1: ;
 else  // Несколько операторов вне блока begin..end !!!!
   D:=SQRT(abs(sin(random)*cos(random)));
   D:=SQRT(abs(sin(random)*cos(random)));
   D:=SQRT(abs(sin(random)*cos(random)));
end;

Работает как в Delphi7 так и в Delphi 2009
WTF?Не совсем патология. Но знать полезно.

Вопрос: с какой целью в реализациях IUnknown.Release используют InterlockedDecrement? Наверное, для потокобезопасности. Но реализация Release вовсе не выглядит потокобезопасной: что будет если другой поток в этот момент вызовет IUnknown.AddRef?

На пальцах:

1. Поток 1 проверяет валидность и копирует указатель на интерфейс
2. Выполняется переключение контекста. Управление передается потоку 2
3. Поток 2 вызывает Release(). Счетчик ссылок достигает нуля. Объект уничтожается. Указатель зануливается
4. Переключение контекста. Передача управления обратно в поток 1
5. Поток 1 для скопированного указателя (уже невалидного) вызывает AddRef(). Бабах!!!

Баг или фича? Решать вам.
(Хм, наверное для устранения сей баго/фичи и придумали межпотоковый маршаллинг интерфейсов ☺)

Ссылки:
  1. If there's already a bug, it's not surprising that there's a possibility for error

  2. Avoiding double-destruction when an object is released

Read more... )

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

Итак, код:

procedure Foo;
  function Bar: string;
  var
    i: integer;
  begin
    for i := 1 to 5 do
      Result := Result + IntToStr(i);
  end;
var
  i: integer;
begin
  for i := 1 to 5 do
    Writeln(Bar);
end;

Что не так? Забыл инициализировать Result?

Хех, менеджед-типы инициализируются автоматически при входе во scope (тем более что ни D7 ни D2009 даже не пискнули о неинициализированном Result), ответил бы я, да не тут то было....

Вот вывод:

12345
1234512345
123451234512345
12345123451234512345
1234512345123451234512345

Оказывается, что для локальных процедур не создается отдельный фрейм стека, а используется фрейм родителя. Потому Result и хранила состояние от предыдущего вызова. Вот так вот.

WTF?Для маршаллинга COM-интерфейсов между потоками есть такой функционал системы COM, как CoMarshalInterThreadInterfaceInStream / CoGetInterfaceAndReleaseStream.

Функции выполняют именно то, что указанно в названии. А именно работу по облегчению "обмена" информацией об интерфейсе между потоками: в одном потоке сохранили данные о интерфейсе в IStream, а в другом восстановили их из этого же IStream’а.
Вроде ничего проще быть не может, все ясно, все понятно и очень удобно. Но разработчики подсунули свои грабли…

Читать далее... )
WTF?К сожалению, далеко не у всех и не всегда удается сходу придумать хорошую архитектуру и "правильный" API. Часто бывает, что архитектура и API должна пройти несколько итераций и метаморфоз перед тем как лишится недостатков и "устаканится". Но на это нужно время. Хотя бы на то, чтоб кто-то мог опробовать это дизайнерское решение в действии.

Настоящая засада начинается когда это "действие" некому и некогда пробовать и ляпы API просачиваются в стандарты.

Речь идет о ляпе в жизненно важном для COM методе QueryInterface, о способе оповещении, что интерфейс не поддерживается. Казалась бы, что тут может быть проще, либо интерфейс поддерживается, либо — нет. Но грабли нашлись даже в такой простой вещи. Вот что написано в MSDN:
"If the object does not support the interface specified in iid, *ppvObject is set to NULL. ... S_OK if the interface is supported, E_NOINTERFACE if not”
Т.е. согласно спекам, любая "хорошая" имплементация QueryInterface, в случае отсутствия запрашиваемого интерфейса, должна вернуть как код ошибки, так и занулить out-параметр *ppvObject.

Читать далее... )
Кросспост на perfectcoding
Не очень долго думал как написать:
* написать базовый класс, с общим функционалом
* или завести еще один класс путем откопипастчивания от имеющегося
Выбрал второе

Вот так из идеалиста, я потихоньку превращаюсь в говнокодера...
OpenGL3
11 августа в публичном доступе появилась спецификация долгожданного OpenGL 3.0. Но, увы, ожидания не оправдались. В новой версии стандарта практически не добавилось ничего нового: только стандартизированы старые расширения, и введен раздел "The Deprecation Model". Это почти тот же облом что и с версией 2.0, когда по-сути ничего не изменилось. Вот и новую версию тоже следовало б назвать, скажем, OpenGL 2.2, а не так как сейчас.

Хотя на официальном форуме полно матов и ругани в сторону Khronos'а, но считаю что не все так плохо, и хоронить OpenGL еще очень и очень рано... )
Стали известны подробности долгожданных нововведений в языке Delphi

Читать далее... )
Вот сегодня посетила мысль, что не совсем это и плохо, мания идеализма. Ведь если б не стремление к этому «идеальному коду», если б
не переписанный четырежды движок (перелопачены полтора метра исходников) то, наверное, я б не был тем, кто я сейчас есть.
В смысле я б не умел проектировать архитектуру программы.

Как говорится, на ошибках учатся.
Только это работает на 100%, если эти ошибки исправляешь сам.

Реклама

Настроить
Страница загружена Дек 8 2009, 1:39 am GMT.