позивање виртуелне функције из деструктора базне класе

Данас сам имао краткотрајно помрачење ума. Покушао сам нешто што не може да ради. Чак сам се и збунио, а волим да верујем да познајем Ц++. Све је релативно, а знање нарочито.

Ради се о следећем:

class Base
{
public:
   virtual ~Base() { foo(); }

   virtual void foo() = 0;
};

class Derived
{
public:
   virtual void foo() { cout << "Derived::foo" << endl; }
};

Солидан компајлер ће дати упозорење. У зависности од верзије gcc и binutils прављење извршне датотеке може да успе, можда не. У сваком случају, ово је погрешно из простог разлога што у тренутку када деструктор класе Base позове функцију foo, изведена класа Derived је већ извршила свој деструктор и подаци у тој класи су већ уништени. Ако би компјалер дозволио позив виртуелне фунције из деструктора Base, довео би до ситуације да виртуелна функција изведене класе барата са подацима који су већ били уништени.

byobu

Већ неколико година користим "GNU screen" и веома ми је користан. Тек данас сам сазнао за "byobu".

Програм byobu даје могућност конфигурисања screen програма и приказ интересантних података у додатној статусној линији.

Ипак, оно што ми се нарочито свиђа је да вертикална подела екрана сада ради без грешке. Када сам пре неког времена то покушао са screen није све радило како треба па то нисам ни користио.

Дакле, од сада - byobu!

Занимљиво питање

Питање је стигло од корисника:

Зашто на powerpc платформи овај код завршава у бесконачној петљи:

int main()
{
   int bar = 0;
   char foo;

   for (foo = 7; foo >= 0; foo--) {
       bar++;
   }

   return bar;
}

Одговор:
зато што је на powerpc платформи char не-негативан целобројни тип (unsigned char)

C++0x

Данас коначно узмем мало времена да прочитам о новом Ц++ стандарду:
http://en.wikipedia.org/wiki/C%2B%2B0x

Оно што ми је нарочито привукло пажњу јесте увођење кључне речи auto.

Мотивација ми је потпуно јасна, и свакако је јасна свакоме ко је користио bind шаблоне. Оно чега се бојим, међутим, је могућност коришћења auto за било који тип података.

Питам се колико ће времена проћи док се не појаве "нови" пројекти који користе auto свуда (вероватно ће личити на бејзик програм).

Убунту

Прошле недеље сам инсталирао Убунту 9.10 на лаптоп. Изабрао Српски језик и инсталирао. Инталација је прошла без проблема, скоро сви периферијски уређаји су били препознати "из прве" или је требало учинити два клика мишем да би прорадили.

Брзина је завидна у односу на Висту коју сам имао пре тога, али оно што ми се нарочито свиђа је то да је подршка различитим језицима урађена изненађујуће добро. Преводи на Српски су, колико могу да видим, такође прилично добри.

sizeof(void)

Интересантно питање које ми је данас поставио колега. Стварно, колики је sizeof(void)?

Знам да може да се користи као аргумент шаблона, па сам претпоставио да је то легалан израз. Међутим, преварио сам се у величини: претпоставио сам 0, али је стварно 1. Барем како то Гну-ов компајлер каже. У стандарду "C99", брзо тражење речи "void" није дало одговор, тако да сада нисам сигуран да ли је 1 према стандарду или је то Гну-ова имплементација.


--- 5 минута касније ---

Дакле, пажљивије читање стандарда даје одговор: ово није легалан c99 израз и ради се о нестандардној имплементацији Гну-овог компајлера. Уколико користим "-std=c99 -pedantic" компајлер пријављује упозорење.

Конкретан текст стандарда који ово јасно показује се налази у поглављу 6.5.3.4 ИСО Ц стандарда 9899:1999 где каже да оператор sizeof не може да се користи на изразе који имају тип функције или некомплетни тип, итд. Како је void некомплетан тип података, sizeof(void) није легалан израз.

Проблем

Управо сам суочен са интересантним проблемом који још увек не знам да решим. Ради се о седећем:

Имам блок меморије, унутар њега елементе са заглављем и слободним простором. Уколико је задато поравнање поинтера, треба да нађем поинтер у једном од слободних простора који је поравнан на дату вредност. Другим речима, уколико имам поинтер p, и величину елемента (заглавље + слободни простор), да ли је могуће доказати да постоји такав цели број N за који ће следећа једначина да важи:

p + N * dist = M * alignment

где су
p - поинтер на први слободни простор блока
N - произвољни цели број
dist - величина елемента (заглавље + слободни простор)
M - произвољни цели број
alignment - поравнање, мора бити 2 на целобројни експонент.


----

После мало размишљања, математика би могла да буде ово:

Формулу поделим са alignment:

p / alignment + N * dist / alignment = M

Резултат дељења би могао бити:

P + Mp / alignment + N * dist / alignment = M

С обзиром да доказујем само да ли постоје такви целобројни N и M, није битно која је њихова вредност, па онда целобројну вредност P стапам са M i dobijam neki novi celobrojni broj R.

Mp / alignment + N * dist / alignment = R

Да би горња једначина била задовољена, рационални број треба да нестане, а то може само ако:

N * dist = alignment - Mp

односно

N = (alignment - Mp) / dist

Дакле уколико је остатак овог дељења 0, такви бројеви постоје:

if (mod((alignment - mod(p / alignment))/dist) == 0) -> Da
else -> NE


----
После пуно размишљања, и дискусије са Страхињом, мој закључак је да таква општа формула не постоји. На крају сам променио алгоритам за испитивање подобности датог блока и сада је овакав.

Ако су сви следећи услови испуњени, блок је подобан:

1. Све корисничке алокације унутар блока су поравнате на 2^k адресе (другим речима, првa корисничка адреса унутар блока је 2^k)
2. Тражено поравање је такође 2^k
3. Величина алокационог елемнта (кориснички простор + контролна структура) мора бити такође 2^k
4. Тражено поравање мора бити мање или једнако величини алокационог елемента.

Тако се алокација врши само ако су задовољени горе наведени услови, а све остало се одбацује и алокација се врши од општег "list allocator".