Начну с описания проблемы. При написании приложений на С++ некоторую сложность для начинающих разработчиков может представлять отсутствие стандартных классов для работы со строками, файлами, коллекциями, сетью и выполнения других простых операций. Конечно, есть WinAPI, Standard Library, CRT, MFC, ATL, но они достаточно сложны в использованиии.

К примеру, в серьезных коммерческих проектах считывать файлы с помощью прямых вызовов функции WinAPI СreateFile/ReadFile/CloseFile без создания классовых оберток сложно, и вообщем то неправильно. Другой пример, работа со строками, СRT — неудобно: буферы, незащищенный код. std::string — довольно неполон: отсутствуют такие часто используемые операции как например trim, split. Поэтому многие разработчики в каждом новом проекте пишут собственные классы/обертки для выполнения простых операций.

Нередко программисты для удобства и краткости переопределяют простейшие типы данных, дают им другие имена. Чаще всего это делаетс примерно так:

typedef unsingned int uint32;
typedef signed int int32;
typedef unsigned char byte;

Ну и так далее. Выступлю с предложением: а почему бы не переопределить простейшие типы, написав для каждого типа свой класс? Расход памяти при хранении таких объектов увеличиться по идее не должен(ессно, виртуальные функции не используем). Например, пишем класс Double, примерно так:

class Double
{
public:
     Double(const Double& value);
     Double          operator+(const Double &right) const;
     Double          operator-(const Double &right) const;
     Bool              IsPositiveInfinity();
     Bool              IsNegativeInfinity();
     
private:
     double _value;
     
}

Или например для типа char:

class Char
{
public:
    Char(char value);

    Bool IsDecimalDigit() const;
    Bool IsLetter() const;
    Bool IsWhiteSpace() const;
    
    Bool operator==(const Char &other);
    Bool operator!=(const Char &other);

private:
    char _value;
};

Таким образом, можно работать с простейшими типами как с объектами, повысить удобочитаемость кода, иметь больше контроля над тем что происходит в программе(например, для подсчета количества умножений, выполняемых над типом double достаточно поместить счетчик в перегруженный оператор).

Оверхеда по производительности/расходу памяти по идее быть не должно.

Пока не могу поделиться плюсами/минусами такого подхода, но постепенно внедряю его в свои C++ библиотеки.

Вообще, оно нам нужно? Вот я уже лет 5-7 этими знаниями не пользовался. Но в принципе вполне неплохо писал программный код(хотя инноваций там, признаюсь, было мало). А кто сейчас кроме различных энтузиастов, рисующих 3d сценки где можно побегать на джаваскрипте, эти знания использует?
Надо или нет? Т.е. вопрос в том, насколько эти знания применяются в web-программировании?

ЗЫ. Ну личное мое имхо это канешна блин надо это все знать, и никогда не забывать если выучил, как таблицу умножения. (правда, похвастаться этим пока не могу, не знал, но забыл)

Все думаю уже знают, но все же. Иногда нужно оценить, сколько процессорного времени занимает выполнение тех или иных функций программы(преимущественно я говорю сейчас о C++). Ну и ниже привожу свой способ, простой, но вполне меня устраивает.

Можно проинструментировать код различными специальными инструментами(не пробовал, вроде DevPartner один из них, думаю их немало сейчас).
Функции привязанные к времени не очень то хорошо работают, в WinAPI или в каком либо другом API я их не нашел.

Две функции которые мне весьма пришлись по вкусу:

QueryPerformanceFrequency
QueryPerformanceCounter

Вообще, тут можно заканчивать чтение статьи, чуть погуглить и хватит:)

С помощью этой парочки функций можно получить довольно точные оценки времени работы программных вычислений.

Собственно, QueryPerformanceFrequency возвращает количество элементарных операций которые может выполнить ваш процессор за одну секунду.
QueryPerformanceCounter возвращает количество элементарных операций, которое он уже выполнил с момента запуска компьютера.

«GetTickCount» — вроде как альтернатива, но ее точности мне как то не хватило, либо меня не устроило ее поведение, которое не слишком то внятно описано в MSDN, скорее ее можно использовать только для UI-расчетов.

Вычислить, сколько cекунд занимает вызов какой либо функции (метода класса) DoWork() с использованием QueryPerformanceFrequency/QueryPerformanceCounter собственно весьма просто:

LARGE_INTEGER performanceCounter;
::QueryPerformanceFrequency(&performanceCounter);

LARGE_INTEGER performanceCounterStart;
::QueryPerformanceCounter(&performanceCounterStart);

DoWork();

LARGE_INTEGER performanceCounterEnd;
::QueryPerformanceFrequency(&performanceCounterEnd);

double timeElapsed = (double*)(performanceCounterEnd) - (double*)(performanceCounterEnd)

Грешный код конечно, я лишь показал идею, может вдруг кому и пригодится.
Вообще, QueryPerformanceCounter, это «ReaD Time Stamp Counter(RDTSC)» инструкция ассемблера(вру о5, название инструкции #0f, #31, хотя постесняюсь сказать, на каких процессорах она работает, за что прошу меня простить:)

ЗЫ. При оценке производительности и простейших тестах, коими я иногда пользуюсь, стоит обратить внимание и на компилятор, большинство вменяемых компиляторов блок кода типа

CalculateSinus (cobst Double &x)
{
    return sin(x);
}

static const double x = PI / 4;
double y = CalculateSinus(x)

преобразуют так, что вообще ее не нужно будет считать во время выполнения, и y=sin(PI/4) будет просчитан на стадии компиляии.

Не, развернутый пост писать мне лениво. Итак, если вдруг кто-то что то увидит в моих размышлениях — плюсуйте, или минусуйте, (слова то какие страшные:). Собсно о чем я: вопрос: зачем мы уже пару десятков лет объясняем на разных языках различным процессорам КАК мы хотим выполнить задачу? Причем делаем это миллионы раз, объясняя тупым процессорам на множестве языков программирования ЧТО мы хотим в итоге получить. Причем одни и те же задачи решались уже миллионы раз.

Различные фреймворки конечно же решают общие задачи достаточно просто, но в итоге приходится одни и те же простейшие задачи решать снова и снова. А тогда нафига нам вообще компьютеры, если мы все делаем сами?.. Может пора научить эти устройства, которые мы приручили, самостоятельно принимать простые решения, а не объяснять им снова и снова что мы от них хотим? Вообще это скорее крик души, я честно говоря уже устал писать программы на традиционных языках программирования, снова и снова объясняя моему любимому ПК банальные вещи: smart pointers, ссылки, константные ссылки, указатели, виртуальные функции, стек/динамическая память. С чего вдруг мне обо всем этом заботиться?

Возьмем простую задачу: распарсить XML файл и вывести все имена тэгов на экран. Варианты решения: бесконечно много. Можно использовать множество языков программирования, можно на каждом из них написать совершенно разный код. Скорость работы этих решений: стесняюсь оценить,
может различаться на 1-2-10 порядков. А задача то ведь сверх простая, чтобы достичь максимальной эффективности нужно всего то правильно написать несколько строк(наверное, десятков строк) ассемблерного кода.

Но ведь дело даже не в этом. Сколько, продолжая тот же пример, написано XML парсеров? А ведь логика там одна и та же. И та же «грамматика», очень много общего. А почему бы не сказать нашей любимой платформе, что такое XML по сути. Чтобы он знал, что такое XML, с чем его едят, с чем не едят и т.д. И получив его на входе сам бы преобразовывал его к нужному выходу, получив задачу ЧТО нужно сделать и самостоятельно решая задачу КАК делать.

ЗЫ. XML приведен для очень грубого и простого примера, просьба XML в каментах не трогать:)
ЗЫЫ. Первый пост, не судите строго, я исправлюсь, может быть:)