Здравствуйте, Pzz, Вы писали:

Pzz>Прежде, чем писать что-то свое, есть смысл посмотреть на уже готовое. Например, Apache Portable Runtime, Netscape Portable Runtime, Qt, ACE.
Pzz>Последние две — это больше, чем pirtable runtime, но он туда включен.

Речь идёт о создании унифицированного качественного набора удобных классов-обёрток, которые можно постоянно использовать при написании программ на C++. Можете назвать это общим знаменателем, если хотите. А реализация функциональности может быть разная, в том числе и на базе кроссплатформенных библиотек которые вы предложили: Apache Portable Runtime, Netscape Portable Runtime, Qt, ACE. Хотя нативные тоже не стоит исключать.

Для того чтобы было понятнее, приведу простой пример:

Обёртка для хэш-таблицы.

Файл HashTable.h :

#include "Integers.h"

class HashTableMembers;

class HashTable
{
public:
 void  Insert(void *Key, void *Data);
 void  Delete(void *Key);
 void  Set(void *Key, void *Data);
 void* Get(void *Key);

 HashTableMembers *M;

 HashTable();
 ~HashTable();
};

В .cpp такой класс можно реализовать на базе любой уже готовой библиотеки. Сторонние заголовки включаются только в модуле, а вся потенциальная специфика прячется в классе HashTableMembers, объект которого создается в конструкторе.

Если Алгоритм Программы базировать только на таких вот общих обёртках, то в случае необходимости, библиотеку можно легко поменять. Достаточно просто переопределить функции класса. А Алгоритм Программы переписывать не надо.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vladrsdn, Вы писали:

V>>Как раз PHP — верх кривости из-за неортогональности функций. Одних способов искать подстрочку в строке там примерно 15, и 10 — проматчить строку регекспом!

А>Тем не менее, в PHP есть интересные процедуры, которых не хватает в стандартных библиотеках C++.

и что? В С++ их нет не из-за того что Бьярн Страутструм — тупой и ограниченый, а чтобы функциональность была минимально необходимая.

V>>Имена функций тоже беспредел — где сначала глагол потом сказуемое, где наоборот и тд.

А>Имена функций мне вообще больше нравятся с заглавных букв -- в стиле Microsoft. Например, MessageBox читать намного удобнее чем message_box.

а меня от MessageBox тошнит — надо 2 раза шифт нажимать когда набираешь, а message_box — всего 1 раз, и быстрее читать код можно.

V>>Нафиг надо такие обертки, сделанные каждым под себя на скорую руку!

А>Поэтому этот вопрос необходимо решать коллективно — через ресурсы и форумы RSDN, чтобы не было как вы говорите "на скорую руку" и "каждым под себя". Возможно кое-что следует позаимствовать из обёрток запроектированных в .NET, хотя и там далеко не всё идеально.

А>Если заняться этим серьёзно — очень многое можно реально упростить.

Это называется велосипедостроительство и графомания. В юниксе слава Б-гу все этим уже переболели.

Здравствуйте, vladrsdn, Вы писали:

V>Так и надо делать кросс-платформенные проги. При правильном проектировании и реализации, 95% кода будут собираться и одинаково работать на винде-юниксе-макоси. Оставшиеся 5% кода пишем под каждую платформу на ее родных тулкитах или пользуем кросс-платформенное WxWidgets/Qt. Не надо, как 95% программистов-подоконников, открывать и читать файлы через CreateFile/ReadFile или MFC классы, есть кросс-платформенные fopen/fread или их С++ аналоги.

я сам себе потихоньку, по-мере надобности, в стиле описанном здесь

Автор: Vamp
Дата: 26.11.08

,
пишу platform abstraction layer, и через него все и делаю. Вот видимо скоро под *nix дополню её...

Здравствуйте, 8bit, Вы писали:

8>Здравствуйте, vladrsdn, Вы писали:
V>>Так и надо делать кросс-платформенные проги. При правильном проектировании и реализации, 95% кода будут собираться и одинаково работать на винде-юниксе-макоси. Оставшиеся 5% кода пишем под каждую платформу на ее родных тулкитах или пользуем кросс-платформенное WxWidgets/Qt. Не надо, как 95% программистов-подоконников, открывать и читать файлы через CreateFile/ReadFile или MFC классы, есть кросс-платформенные fopen/fread или их С++ аналоги.
8>я сам себе потихоньку, по-мере надобности пишу platform abstraction layer, и через него все и делаю. Вот видимо скоро под *nix дополню её...

Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, 8bit, Вы писали:

8>>Здравствуйте, vladrsdn, Вы писали:
V>>>Так и надо делать кросс-платформенные проги. При правильном проектировании и реализации, 95% кода будут собираться и одинаково работать на винде-юниксе-макоси. Оставшиеся 5% кода пишем под каждую платформу на ее родных тулкитах или пользуем кросс-платформенное WxWidgets/Qt. Не надо, как 95% программистов-подоконников, открывать и читать файлы через CreateFile/ReadFile или MFC классы, есть кросс-платформенные fopen/fread или их С++ аналоги.
8>>я сам себе потихоньку, по-мере надобности пишу platform abstraction layer, и через него все и делаю. Вот видимо скоро под *nix дополню её...

А>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

А>Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

не изобретайте глючный велосипед — возьмите nspr от мозиллы — она под lgpl (то есть ее можно линковать динамически к коммерческому коду) — там файлы — сеть и сокеты — процессы -треды и еще дохрена всего.

Здравствуйте, vladrsdn, Вы писали:

А>>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

А>>Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

V>не изобретайте глючный велосипед — возьмите nspr от мозиллы — она под lgpl (то есть ее можно линковать динамически к коммерческому коду) — там файлы — сеть и сокеты — процессы -треды и еще дохрена всего.

Так я ничего не изобретаю. Обёртки, это всего лишь свой собственный набор удобных названий функций и классов + чистые алгоритмы. А библиотеку можно прикрутить любую.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vladrsdn, Вы писали:

А>>>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

А>>>Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

V>>не изобретайте глючный велосипед — возьмите nspr от мозиллы — она под lgpl (то есть ее можно линковать динамически к коммерческому коду) — там файлы — сеть и сокеты — процессы -треды и еще дохрена всего.

А>Так я ничего не изобретаю. Обёртки, это всего лишь свой собственный набор удобных названий функций и классов + чистые алгоритмы. А библиотеку можно прикрутить любую.

Тогда нечего выкладывать на rsdn — у каждого свои предпочтения к названиям классов и ф-ий. Тем более никто не будет писать нормальные доки ко своим оберткам. Нефига плодить энтропию.

Здравствуйте, vladrsdn, Вы писали:

V>Тогда нечего выкладывать на rsdn — у каждого свои предпочтения к названиям классов и ф-ий. Тем более никто не будет писать нормальные доки ко своим оберткам. Нефига плодить энтропию.

Пока что этим мало кто занимался, поэтому об энтропии говорить рано. В вопросе создания хороших обёрток важна максимальная оптимизация. Стремление к достижению удобочитаемости, максимальному упрощению в использовании. Традиционно, не следует увеличивать количество сущностей без необходимости. Всё должно быть просто, очень просто, настолько просто — насколько это возможно.

Посмотрите на PHP — он выигрывает за счёт удобства обёрток. Ими очень легко, удобно пользоваться. Всё интуитивно понятно. А ведь почти все PHP библиотеки сишные! Почему бы не сделать то же самое на C++ ?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vladrsdn, Вы писали:

V>>Тогда нечего выкладывать на rsdn — у каждого свои предпочтения к названиям классов и ф-ий. Тем более никто не будет писать нормальные доки ко своим оберткам. Нефига плодить энтропию.

А>Пока что этим мало кто занимался, поэтому об энтропии говорить рано. В вопросе создания хороших обёрток важна максимальная оптимизация. Стремление к достижению удобочитаемости, максимальному упрощению в использовании. Традиционно, не следует увеличивать количество сущностей без необходимости. Всё должно быть просто, очень просто, настолько просто — насколько это возможно.

А>Посмотрите на PHP — он выигрывает за счёт удобства обёрток. Ими очень легко, удобно пользоваться. Всё интуитивно понятно. А ведь почти все PHP библиотеки сишные! Почему бы не сделать то же самое на C++ ?

Как раз PHP — верх кривости из-за неортогональности функций. Одних способов искать подстрочку в строке там примерно 15, и 10 — проматчить строку регекспом! Имена функций тоже беспредел — где сначала глагол потом сказуемое, где наоборот и тд.

Нафиг надо такие обертки, сделанные каждым под себя на скорую руку!

Здравствуйте, Аноним, Вы писали:

А>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

Прежде, чем писать что-то свое, есть смысл посмотреть на уже готовое. Например, Apache Portable Runtime, Netscape Portable Runtime, Qt, ACE.

Последние две — это больше, чем pirtable runtime, но он туда включен.

Здравствуйте, Pzz, Вы писали:

Еще можно poco добавить.
Но своя рубаха ближе

Здравствуйте, vladrsdn, Вы писали:

V>Как раз PHP — верх кривости из-за неортогональности функций. Одних способов искать подстрочку в строке там примерно 15, и 10 — проматчить строку регекспом!

Тем не менее, в PHP есть интересные процедуры, которых не хватает в стандартных библиотеках C++.

V>Имена функций тоже беспредел — где сначала глагол потом сказуемое, где наоборот и тд.

Имена функций мне вообще больше нравятся с заглавных букв -- в стиле Microsoft. Например, MessageBox читать намного удобнее чем message_box.

V>Нафиг надо такие обертки, сделанные каждым под себя на скорую руку!

Поэтому этот вопрос необходимо решать коллективно — через ресурсы и форумы RSDN, чтобы не было как вы говорите "на скорую руку" и "каждым под себя". Возможно кое-что следует позаимствовать из обёрток запроектированных в .NET, хотя и там далеко не всё идеально.

Если заняться этим серьёзно — очень многое можно реально упростить.

Здравствуйте, Аноним, Вы писали:

А>Если Алгоритм Программы базировать только на таких вот общих обёртках, то в случае необходимости, библиотеку можно легко поменять. Достаточно просто переопределить функции класса. А Алгоритм Программы переписывать не надо.

Таких библиотек существует вагон и маленькая тележка. Чем ваша-то лучше?

Здравствуйте, Pzz, Вы писали:

Pzz>Таких библиотек существует вагон и маленькая тележка.

Не библиотека, а общая надстройка над библиотеками.

Здравствуйте, vladrsdn, Вы писали:

А>>Если заняться этим серьёзно — очень многое можно реально упростить.

V>Это называется велосипедостроительство и графомания.

Устал повторять. Ладно. Повторю ещё в 3-тий раз. Велосипедостроительство это когда библиотеки сам делаешь. А про то что я говорил — это система интуитивно простых обёрток, оптимизация в использовании языка.

V>В юниксе слава Б-гу все этим уже переболели.

Ну и к чему пришли в результате? Даже нет элементарного понимания что такое обёртка и что такое библиотека. А большинство просто смотрят друг на друга, и дёшево ведутся на так называемые "стандарты", в результате чего клепают жуткий код на углоскобном STL'е, который для зрительного восприятия невероятно ужасен.

Большинство программистов к сожалению идёт стадом, бездумно, совершенно не занимаясь фундаментальными вопросами упрощения, улучшения удобства использования С++, эволюции удобочитаемости кода...

Здравствуйте, Anonim12, Вы писали:

A>Ну и к чему пришли в результате? Даже нет элементарного понимания что такое обёртка и что такое библиотека. А большинство просто смотрят друг на друга, и дёшево ведутся на так называемые "стандарты", в результате чего клепают жуткий код на углоскобном STL'е, который для зрительного восприятия невероятно ужасен.

Следование стандарту хорошо тем, что в отличии от самодельной библиотеки его специально изучать не надо. Что при прочьих равных является заметным достоинством.

A>Большинство программистов к сожалению идёт стадом, бездумно, совершенно не занимаясь фундаментальными вопросами упрощения, улучшения удобства использования С++, эволюции удобочитаемости кода...

На C++ по-моему невозможно писать удобочитаемый код. Тут язык надо менять, а не обертки писать.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Anonim12, Вы писали:

A>>...дёшево ведутся на так называемые "стандарты", в результате чего клепают жуткий код на углоскобном STL'е, который для зрительного восприятия невероятно ужасен.
Pzz>Следование стандарту хорошо тем, что в отличии от самодельной библиотеки его специально изучать не надо. Что при прочьих равных является заметным достоинством.

Проблема только в том, что эти "стандарты" очень далеки от идеала.

A>>Большинство программистов к сожалению идёт стадом, бездумно, совершенно не занимаясь фундаментальными вопросами упрощения, улучшения удобства использования С++, эволюции удобочитаемости кода...
Pzz>На C++ по-моему невозможно писать удобочитаемый код. Тут язык надо менять, а не обертки писать.

Если есть желание — то можно. Правда, ценой отказа от "стандартов".

Я серьёзно говорю, сам язык тут совершенно не при чём. Реально не хватает удобного, рационального, сильно оптимизированного с точки зрения удобочитаемости, общепринятого набора классов с функциями и операторами.

А то что сейчас принято — STL, как раз и создаёт иллюзию сложности языка.

Здравствуйте, Anonim12, Вы писали:

A>Проблема только в том, что эти "стандарты" очень далеки от идеала.

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

A>Я серьёзно говорю, сам язык тут совершенно не при чём. Реально не хватает удобного, рационального, сильно оптимизированного с точки зрения удобочитаемости, общепринятого набора классов с функциями и операторами.

Ну я видел ваш пример. В мире C++ считается небонтонным делать хеш-таблицы, которые возвращают void* в обмен на ключ. А если вы попытаетесь сделать что-то типобезопасное, у вас как раз STL и получится. Язык такой, увы.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну я видел ваш пример. В мире C++ считается небонтонным делать хеш-таблицы, которые возвращают void* в обмен на ключ.

Указатели — простой способ передачи объекта любого типа. Наверное это не модно, но я модой не интересуюсь.

Pzz>Язык такой, увы.

Здесь всё зависит от того кому вы верите (дешёвым журнальным статьям или независимым исследованиям). На самом деле язык C++ простой. Хотя очевидно невыгодный разным богатым организациям и корпорациям типа Sun (Java) и Microsoft (VB C#.NET). Корпорации навешали ярлыков, создали иллюзию сложности — стадо поверило. Язык С++ им явно мешает привязывать программиста к конкретной среде и выбивать деньги из пирамиды.

Здравствуйте, Anonim12, Вы писали:

A>Здесь всё зависит от того кому вы верите (дешёвым журнальным статьям или независимым исследованиям). На самом деле язык C++ простой. Хотя очевидно невыгодный разным богатым организациям и корпорациям типа Sun (Java) и Microsoft (VB C#.NET). Корпорации навешали ярлыков, создали иллюзию сложности — стадо поверило. Язык С++ им явно мешает привязывать программиста к конкретной среде и выбивать деньги из пирамиды.

Я как-то все больше предпочитаю верить себе.

Здравствуйте, Аноним, Вы писали:

А> void* Get(void *Key);

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

Здравствуйте, artem_korneev, Вы писали:

А>> void* Get(void *Key);
_>Вот в этом месте мы отказываемся от возможности определять ошибки типов на стадии компилляции. Невозможно проверить, объект какого типа вернёт нам Get().

Объект типа "последовательность байтов". По-моему самый простой тип, поэтому он часто используется в ассемблере.
А как всем известно, C/C++ это кроссплатформенный ассемблер.

_>Имхо, это неудачный пример.

Может быть. Не спорю. Каждому — своё.

P.S. Единственный реально кроссплатформенный тип — это char/unsigned char.
представление целых (int) — уже зависит от процессора ( Little/Big-Endian на SPARC/Intel — отличаются )
представление дробей (float, double) — от процессора/компилятора
Объекты структур и классов — на разных платформах тоже имеют разные бинарные представления (выравнивание).
Так что самый кроссплатформенный "тип" — это байт и поток байтов.

Здравствуйте, Аноним, Вы писали:

А>Объект типа "последовательность байтов". По-моему самый простой тип, поэтому он часто используется в ассемблере.

Гораздо чаще используются "сложные" типы — классы, структуры, потоки.

А>P.S. Единственный реально кроссплатформенный тип — это char/unsigned char.

Разве? А как на счёт 7-битных артихектур? В embedded-железках или какой-нибудь самопальной экзотике попадается, AFAIK.
Или любых прочих архитектур, где размер байта != 8?

А>представление дробей (float, double) — от процессора/компилятора

Разве представление float/double зависит от _компилятора_? o_O

А>Объекты структур и классов — на разных платформах тоже имеют разные бинарные представления (выравнивание).

И что теперь? Зачем полагаться на внутреннее представление объектов в памяти? Нужно хранение/передача объектов между разными архитектурами? Тогда копаем в сторону сериализации. А если нужно просто создавать/использовать объекты — то какая нам разница, как они там внутри записываются?

А>Так что самый кроссплатформенный "тип" — это байт и поток байтов.

Угу.. а самый кроссплатформенный язык — brainf*ck (а'ля "машина Тьюринга").
Нет уж, извините. Я обычно стараюсь максимально использовать проверку типов на этапе компилляции, а всевозможные void* этому лишь препятствуют.

Здравствуйте, artem_korneev, Вы писали:

_>Разве представление float/double зависит от _компилятора_? o_O

Насколько я помню, float и double — это не стандартизированные типы. То есть, существуют только некоторые минимальные требования на счёт реализации.

Нашёл интересный кроссплатформенный набор бесплатных контролов под лицензией BSD: http://www.ultimatepp.org/src$CtrlLib$index$en-us.html

ArrayCtrl — Complex tabular widget.




RichEdit




ColorPopUp




OptionTree




MenuBar

Очень похоже, что всё рисовано "с нуля", с возможностью менять скины:

Windows XP, standard theme




Windows XP, "Tiger" theme




Linux Ubuntu 6.10, Mist theme

Здравствуйте, Anonim12, Вы писали:

Pzz>>Ну я видел ваш пример. В мире C++ считается небонтонным делать хеш-таблицы, которые возвращают void* в обмен на ключ.

A>Указатели — простой способ передачи объекта любого типа.

Что есть такое "способ передачи" и "объект"?

Здравствуйте, c-smile, Вы писали:

CS>Что есть такое "способ передачи" и "объект"?

Большинство объектно-ориентированных языков основаны на двух базовых понятиях: классы объектов и экземпляры (instances) объектов.
Здесь подрозумевается конкретный экземпляр объекта.

Способы передачи экземпляров объектов бывают следующие: по значению, по указателю, по ссылке.
Здесь экземпляр объекта передаётся по указателю.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, c-smile, Вы писали:

CS>>Что есть такое "способ передачи" и "объект"?

А>Большинство объектно-ориентированных языков основаны на двух базовых понятиях: классы объектов и экземпляры (instances) объектов.
А>Здесь подрозумевается конкретный экземпляр объекта.

А>Способы передачи экземпляров объектов бывают следующие: по значению, по указателю, по ссылке.
А>Здесь экземпляр объекта передаётся по указателю.

То что вы нам тут с претензией на новизну продаете Буч сотоварищи продавал в начале 90х. У них там была доступная для покупки удобная ООП библиотека контейнеров и алгоритмов и многого другого.
Угадайте с 1й попытки когда они перестали ее продавать ? Правильно как только реализации stl стали доступны под все платформы.
Здесь не передается никакой экземпляр — только адрес неопознанного места в памяти (даже без указания на а)занятый размер б)выделенный размер в)что с ним можно делать). С таким же успехом это может быть адрес тела malloc (это если забыть скобочки ненароком) и пишите туда что хотите — часть платформ даже не ругнется в рантайме до следующего вызова
это только по алгоритмам и контейнерам — а про то как вы собрались абстрагировать файловую систему вы еще примеров не показывали — давайте, народу будет интересно.

Здравствуйте, SleepyDrago, Вы писали:

SD>То что вы нам тут с претензией на новизну продаете Буч сотоварищи продавал в начале 90х.

Никаких претензий на новизну Наоборот. Это качественный пересмотр старого подхода, уровня даже не 90x, а 80x годов. Не спорю, так сейчас не модно.

А связываться с местными сторонниками С++ мейнстрима затрагивая больную тему неудобства STL — особого желания нет. Хотя очень кратко развернуть этот вопрос можно:

STL always seems to destroy your friendly development environment that helps you to do things quickly and efficiently if the original programmer had used straight-forward C++.

STL API Syntax is Unclear, the Designers Had No Taste There are APIs that are clear and the designers "get it", and there are APIs that are totally unclear, ambiguous, and the designers seem like they have never programmed before. STL falls into the latter camp, the designers had bad taste and little or no experience at defining APIs.

I've seen just too much code, typically written as university projects, that uses STL and totally kills an algorithm's performance. Here's an example: an algorithm to computer a Steiner Tree. The original coding was in C, and was pretty efficient using native C arrays. But a certain university group thought it would be cool to reimplement it in C++.
The resulting code, when profiled showed that a high proportion of the runtime was in the STL map code, specifically operator[]. Rewriting it with a simple array class gave a ~5x speedup.

STL Encourages (Lures?) Programmers to Use Very Complex Data Structures — STL gets beginner programmers in trouble VERY fast. In stead of figuring out how to solve a problem with a simple data structure, or without any data structures at all, STL offers full-tilt-grandiose psychotically complex data structures at the mere typing of one line.

Here is an example from code that another engineer stumbled across:

If you look at the example above, it is a case of STL gone nuts. In one line "forceUpates" is a very complex data structure, but it turns out this data structure was totally unnecessary, all the code needed to do was loop over a few files and set a flag. This example also shows how subtle and incomprehensible STL compiler problems are, can you see the error in the syntax? Hint: it is one space that needs to be added or the code will not build.

Как говорится, на вкус и цвет товарищей нет.


SD>У них там была доступная для покупки удобная ООП библиотека контейнеров и алгоритмов и многого другого.
SD>Угадайте с 1й попытки когда они перестали ее продавать ? Правильно как только реализации stl стали доступны под все платформы.

А если быть ещё точнее, то они перестали её продавать когда появилось большое количество бесплатных альтернативных реализаций удобных ООП библиотек контейнеров и алгоритмов (и не только STL), доступных под все платформы: искать здесь.

SD>Здесь не передается никакой экземпляр — только адрес неопознанного места в памяти (даже без указания на а)занятый размер б)выделенный размер в)что с ним можно делать).

Если очень нужно — первые 8 байт можно специально резервировать под размер.
Вопрос что делать — не возникал. Обычно всегда понятно что делать.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, SleepyDrago, Вы писали:

SD>>То что вы нам тут с претензией на новизну продаете Буч сотоварищи продавал в начале 90х.

А>Никаких претензий на новизну Наоборот. Это качественный пересмотр старого подхода, уровня даже не 90x, а 80x годов. Не спорю, так сейчас не модно.

А>А связываться с местными сторонниками С++ мейнстрима затрагивая больную тему неудобства STL — особого желания нет. Хотя очень кратко развернуть этот вопрос можно:
...
А>Как говорится, на вкус и цвет товарищей нет.

ох, постыдились бы ...
Я еще могу понять слезы тех, у кого весь codebase вынужденно написан в Invented-Here-Portable-Runtime и им физически неприятно что гдето есть код, который смогут понять люди без "специального посвящения", но анонимам это непростительно.

хотите бесплатный совет — разместите свое видение ("Это качественный пересмотр" итп) в виде кода на opensource хостинге с багтрекером и контролем версий и скидывайте сюда объявы "[ANN]" о релизах.
Если что то продавать его вам это не помешает а даже поможет. Вы ведь не думаете что qt — бесплатен ?