If a C programmer asks "do you want to see something cool?", run away.
--John Van Enk

Wednesday, November 26, 2008

Ваш блог заблокирован за спам :(

Вот уж не думал :) зайти и увидеть такое в dashboard

Хорошо что на почту пришло извещение да и операция разблокирования заняла всего-то пару минут. Будем надеяться, что все обойдется :)

Friday, November 21, 2008

Getting Ruby Array.uniq! work for array of objects

Иногда возникает задача удалить дубликаты из массива объектов. В Ruby для решения этой задачи в классе Array есть методы uniq и uniq!. Отличие первого от второго состоит лишь в том, что второй производит in place модификацию массива, а первый возвращает результат в виде массива. Для того, чтобы эти методы работали для custom классов необходимо чтобы у классов были определены методы hash и eql?.

class TestClass

attr_reader :a, :b, :c

#Ctor

def initialize(a,b,c)
@a, @b, @c = a, b, c
end


def hash
"#@a #@b #@c".hash
end

def ==(p)
@a ==p.a and @b == p.b and @c == p.c
end

def eql?(p)
self == p
end

def to_s
"#@a,#@b,#@c"
end
end

a = []
a << TestClass.new(1,2,3)
a << TestClass.new(1,2,3)
a << TestClass.new(3,2,1)
a << TestClass.new(3,2,3)
a << TestClass.new(2,3,3)

a.uniq!

a.each do |elem|
p elem.to_s
end

Т.е. одного eql? не достаточно, как это указано в PickAxe а нужен еще и hash method который должен возвращать целое число. И чтобы я делал, если бы не USENET?

Update 20:10: тут меня коллеги попинали чуток, так что слегка изменил пример ;-). И почему мне сразу в голову не пришла мысль, что String.hash есть?

Update 25/11/2008: в ri Hash собственно нашлось объяснение :) : +Hash+ uses +key.eql?+ to test keys for equality. If you need to use instances of your own classes as keys in a +Hash+, it is recommended that you define both the +eql?+ and +hash+ methods. The +hash+ method must have the property that +a.eql?(b)+ implies +a.hash == b.hash+.

Wednesday, November 19, 2008

Just More videos on C++ from Google Tech Talks

1) C++ Stylistics



2) An Overview of the Coming C++ (C++0x) Standard



3) Elkhound, Elsa and Cqual++: Open-Source Static Analysis for C++



Monday, November 17, 2008

Блоговщина #2

Как-то провтыкал, что в субботу блогу исполнилось 2 года. Чтобы не нарушать традицию сделаю обзор статистики блога за этот период.
Итак
  • в номинации "Самая Популярная Статья" места распределились следующим образом
    1. std::string vs. const char* . Comparison - 1 405 просмотров
    2. С & C++ useful resources - 888 просмотров
    3. "Must Read" C++ Books - 874 просмотра

    Последние две наверное потому, что ссылки на них висят в сайдбаре блога :)

  • в номинации "Самый Популярный Бразуер" победила, как и в прошлый раз, огненная лиса.


  • в номинации "Самый Популярная ОС" снова победила самая популярная ОС.


  • в номинации "Страна Где-Меня-Больше-Всего-Читают" тоже ничего не изменилось



А всего за 2 года блог посетило аж 10 432 уникальных посетителей =), а судя по тому что всего посетителей было 17 600, то можно сделать вывод, что некоторый приходили сюда аж по нескольку раз =). Вот где-то так в общем :)

Спасибо вам большое за то, что вы читаете то, что я пишу :)

Friday, November 14, 2008

Empire strikes back: Steven Dewhurst's response to Linus's criticism against C++

Помните нападки Линуса на С++ о которых я когда-то писал? Когда он в довольно жесткой форме высказался в отношении того, что он думает о С++?

Ну вот Steven Dewhurst ему отвечает:

I think it's only fair to point out that Linus' diatribe is more than a year old, and he has spoken in more measured and printable tones elsewhere about the same subject. Less excusable, however, is that he makes the claim that C++ cannot be used in resource-constrained areas with nothing but anecdotal evidence to support his claim. Linus has done good work and has earned his soap box, but he also has a professional obligation to make sense while he’s holding forth. (For those who follow such things, this is an instance of Gotcha #12, “Adolescent Behavior,” from C++ Gotchas.)

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer, and has the significant advantage of being usable by a developer who is not expert in the minutia of the board's design. Unlike Linus, I haven't written a commercial OS, but I have written a policy-based, pre-emptive tasker in C++. It occupies just 3k of RAM and is pretty zippy in addition to being easy to understand, customize, and maintain. Just to annoy people like Linus, I've also used typelist meta-algorithms to generate exception handlers with identical efficiency to hand-coded C. In a number of recent talks given at the Embedded Systems conferences, I've shown that commonly-criticized C++ language features can significantly outperform the C analogs. As an old-school, Bell Labs C hacker I've nothing against C. But C++ provides tools and capabilities that are hard to come by in C, and often make it easier for a competent C++ programmer to produce cleaner and typically smaller and faster code than the C equivalent.

Regarding competence, Linus’s implied argument that C++ attracts bad programmers the way other things attract flies is, in spite of the effective metaphor, both unfair and a little over the top. Inexperienced or incompetent programmers have been lured into writing bad code in other languages as well; I've inherited my share of poorly designed and rendered C. There's no question that C++ is a significantly larger and more complex language than C, and a competent C++ programmer should be familiar with many more design styles (including, among others, that "idiotic 'object model' crap") than a competent C programmer. Wider experience with different design approaches and coding idioms is an advantage if the programmer actually has more than a passing understanding of the techniques. Problems typically arise when teams of competent C programmers are thrown onto a C++ project without adequate preparation simply because C++ syntax looks something like C syntax. The results are usually about the same as you’d get by throwing the same team into a COBOL project. But you’re not going to catch me criticizing COBOL. That’s Linus’s job.

via InformIT: C++ Reference Guide > A Response to Linus Torvalds' C++ Diatribe

Tuesday, November 11, 2008

Concepts: Extending C++ Templates For Generic Programming

По ссылке с Google Open Source Blog обнаружилось интересное видео про новую фичу С++ - concepts.





Это же видео на video.google.com