Странное (о выравнивании)

MSVC:

bool 2 3 4
char 2 3 4
short 4 6 8
int 8 12 16

GCC

bool 2 3 4
char 2 3 4
short 2 4 4
int 4 8 8

Обрезалка ресурсов.

В VC2008sp1 и VC2010 в состав MFC входят новые классы для Ribbon-like UI.
Можно выбрать одну из пяти тем для приложения (aqua, blue, black, silver, windows7).
При статической компиляции внутрь экзешника попадают ресурсы всех тем.
Если в приложении есть переключение тем, это гуд.
А если Ваше приложение всегда должно быть одного цвета -- как то жалко тратить больше 700 KB на ресурсы, которые никогда не используются.
А если учесть то, что это PNG и они плохо жмутся пакерами...

Вот, набросал за часик на коленке питонячий скрипт, который это лечит.

import sys
from ctypes import *

w32 = windll.kernel32

def get_res_list(fname):
handle = w32.LoadLibraryW(fname)
if not handle:
return None

types = []

def types_callback(handle, t):
try:
types.append(cast(t, c_wchar_p).value)
except:
pass
return True

types_callback_t = CFUNCTYPE(c_void_p, c_wchar_p, c_long)
fun = types_callback_t(types_callback)
w32.EnumResourceTypesW(handle, fun, 0)

result = []

def names_callback(h, t, n):
try:
t = cast(t, c_wchar_p).value
n = cast(n, c_wchar_p).value
result.append((t,n))
except e:
print e
return True

names_callback_t = CFUNCTYPE(c_void_p, c_wchar_p, c_wchar_p, c_long)
fun = names_callback_t(names_callback)
for t in types:
w32.EnumResourceNamesW(handle, c_wchar_p(t), fun, 0)
w32.FreeLibrary(handle)
return result

NOT_USED = ('AQUA', 'SILVER', 'WINDOWS7', 'BLACK')
is_not_used = lambda x: x[1].split('_')[0] in NOT_USED

def remove_resources(fname, not_used):
handle = w32.BeginUpdateResourceW(fname, False)
if not handle:
return False
ok = True
try:
for t,n in not_used:
w32.UpdateResourceW(handle, t, n, 0x409, None, 0)
except e:
print e
ok = False
w32.EndUpdateResourceW(handle, not ok)
return ok


fname = u'd:\\app.exe'
not_used = filter(is_not_used, get_res_list(fname))
print remove_resources(fname, not_used)

Абсолютные пути -- это злейшее зло.

утка в зайце strikes back

Флеш-баннер с появляющимся и гаснущим текстом и картинкой.
50 килобайт...
Вроде и немного, но откуда?
....
Представляю внутренний монолог его разработчика:
А давай используем для красивостей tweening-компонент (на АС3), который читает, что ему делать, из xml. В котором опишем используемые шрифты, цвет фона, и переходы между "сценами" (текстом и картинкой). А текст на баннере мы будем хранить как html, конечно же в этом же xml, в percent-encoding.


БЛЁЁЁЁЁЁЁ.....

Переделал несколько либ под использование precompiled headers.
Скорость компиляции выросла в 2-3 раза.
Давно надо было это сделать.

Левая рука не знает, что делает правая

Как же я люблю Adobe....

class TheBase extends Object
{
private function test():void
{} 
}

class Derived extends TheBase
{
private override function test():void  
{}    
}

Флекс такое компилит, а Флеш -- нет.

о ёжиках.

Бьярн Страуструп - "Дизайн и эволюция языка С++" => "Как я родил ёжика"
Андрей Александреску - "Современное проектирвоание на языке С++" => "Как я трахнул ёжика"

(с) zabivator.livejournal.com

UPD:
den: ага, в таком случае "каждый программер должен знать и владеть с++" => "Який ти в чорта лицар, якщо голою сракою їжака не вб`єш?"

... утка в зайце, заяц в шоке!..

Отдекомпилил флешевый загрузчик фоток Вконтакта.

Оказалось, что они используют адобовкую Alchemy.
Это такая хрень, что позволяет компилить C/C++ код в байт-код AVM2 (ActionScript 3).
Так вот, в загрузчик фоток вконтакта вкомпилена либа по работе с jpeg (от IJG).
Пережимают фотки...


Гугление показало, что это сделано для ускорения конвертации в JPEG.

Сишный код,скомпиленный в помесь АС3 байткода и х86 (который выполняется на написанном на AC3 интерпретаторе), выполоняется в несколько раз быстрее, чем реализация джипег-энкодера на чистом AC3. Как-то странно это все.
То-ли у алхимии такой хороший эмитер кода, то-ли у флеша/флекса -- плохой.