1. Возможность использовать конструкции языка Си, делающие код менее надёжным.
   
2. Отсутствие поддерживаемых языком свойств и событий.
   
3. Отсутствие стандартной библиотеки для создания пользовательского интерфейса.
   
4. Отсутствие средств сериализации.
   
5. Отсутствие метапрограммирования и их замена малопонятными и трудноотлаживаемыми конструкциями из шаблонов и макросов.
   
6. Отсутсвие СОМ Interop

Можно использовать кодогенератор для обработки информации полученной из PDB файла и от VS IDE.

--------------------------------
Решение проблемы №1
--------------------------------
Решение простое как топор . Просто надо избавится от CRT. Никто конечно не сможет запретить писать процедурно, но malloc и fopen умрут как категория. По большому счёту разве они ещё кому-то нужны? Реализовать же CRT полностью поддерживающую Си++ код не составляет большой проблемы. Фактически единственная не решённая пока мною задача это symbol demangling (undecoration), но и то больше от нехватки времени, чем из-за объективных проблем. Более того, хотелось бы перекрыть и прямой доступ к WinAPI и вообще к любому C-API. Это работа скорее объёмная, чем сложная. Да и не так страшен чёрт как его малюют. Современные заголовочные файлы Windows Platform SDK минимум на треть состоят из уже устаревших описаний.

--------------------------------
Решение проблемы №2
--------------------------------
Давайте рассмотрим одну из популярных реализаций свойств

class propABC_type
{
public:
    parent_type * _parent()
    {
        return (parent_type *)(((long)this) - ((long)&((( parent_type *)0)->propABC)));
    }

    template <typename _type_value>
    propABC_type & operator = (_type_value _value)
    {
        _parent()->propABC_put(_value);
        return *this;
    }
    operator prop_type()
    {
        return _parent()->propABC_get();
    }
} propABC;

Данный класс, часто оформляют в ввиде макроса.

#define PROPERTY(PARENT_CLASS, PROPERTY_NAME, PROPERTY_TYPE, FUNCTION_GET, FUNCTION_PUT) \
class PROPERTY_NAME##_type \
{ \
public: \
    PARENT_CLASS * _parent() \
    { \
        return (PARENT_CLASS *)(((long)this) - ((long)&(((PARENT_CLASS *)0)->PROPERTY_NAME))); \
    } \

    template <typename _type_value> \
    PROPERTY_NAME##_type & operator = (_type_value dataInit) \
    { \
        _parent()->FUNCTION_PUT(dataInit); \
        return *this; \
    } \
    operator PROPERTY_TYPE() \
    {
        return _parent()->FUNCTION_GET(); \
    } \
} PROPERTY_NAME;

Он создаёт нечто, что ведёт себя как свойство с именем PROPERTY_NAME и типом PROPERTY_TYPE. Однако у него и всех ему подобных классов есть серьёзные недостатки:

1. Описание и функциональность свойства размазаны по классу и двум функциям.
   
2. Синтаксис не удобный и не понятный. Описывая своство надо указать класс-контейнер.

Что же делать? По идее такой синтаксис

property(int, my_prop)
{
    get
    {
        return _internal_variable;
    }

    set
    {
        _internal_variable = value;
    }
}

хотя конечно и не идеален, но гораздо предпочительнее. Но указанных данных компилятору просто мало чтобы создать работоспособный код. Компилятору да, а нам? С помошью кодогенератора использование такого (или подобного) синтаксиса может стать реальностью.
Аналогично и события можно реализовать удобно и эффективно.
--------------------------------
Решение проблемы №3
--------------------------------
Имея механизм событий и свойств можно реализовать очень прозрачную GUI библиотеку. А кодогенераторы позволят избавится от явной подписки на события
Например так

class MyWindow : public Window
{
    bool OnMove(const message<MOVE> & msg)
    {
        return false;
    }
}

Код подписки OnMove на сообщение MOVE будет сгенерирован автоматически. Кроме того есть идея создания библиотеки элементов управления с расширяемых извне наподобие Office CommandBars.

--------------------------------
Решение проблемы №4
--------------------------------
Что нужно чтобы сериализовать структуру A с помошью кодогенератора?
Нужно написать
struct A
{
serializable;
int x;
int y;
}
собственно всё Особенности записи данной структуры в файл можно настраивать и в design time, хотя стандартные схемы скорее всего будут устраивать в 99% случаев.

--------------------------------
Решение проблемы №5
--------------------------------
Я уже говорил про кодогенераторы?

--------------------------------
Решение проблемы №6
--------------------------------
Именно Interop а не Support.
Итак, что надо? Проблем как таковых две. Во-первых, неудобно использовать IDispatch. Invoke это не очень удобно. Во-вторых, написание СОМ серверов всегда жёстко завязано на аттрибуты ATL или мучительно из-за необходимости использования IDL. Что же делать?
Я думаю ничто не мешает генерировать класс-обёртку (на лету или по запросу) для dispatch_ptr<IInterface>.
Что касается создания СОМ серверов тут тут всегда было два камня перткновения. Реализация методов AddRef/Release для коклассов и DllGetClassObject (да и самого class object). И та и другая проблема с лёгкостью решаются кодогенератором.

--------------------------------
Как всё это будет выглядеть
--------------------------------
Всё это будет выглядеть как Visual Studio Add-in, который по ходу дела будет сам генерировать и добавлять в проект нужные файлы.

--------------------------------
Если вы дочитали до конца
--------------------------------
И хотите послать меня в boost, etc то остановитесь и подумайте — я заранее понимал что эти идеи не могли понравится всем подряд. Если вы хотите покритиковать по мелочи, то помните что это всего лишь идея, а не продукт который я вам пытаюсь продать. Стоит ли цеплятся? Хотите упрекнуть меня в том что я привязываю межплатформенный язык Си++ к далеко не самому хорошему компилятору? Это мой выбор, тут уж ничего не поделать.Переубеждать меня бессмысленно

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

11.07.05 23:26: Перенесено модератором из 'C/C++' — Павел Кузнецов

    [Serializable]
    public class OperandCollection : CollectionBase, IBindingList
    {
        [NonSerialized] 
        private ListChangedEventHandler listChangedHandler;

        public event ListChangedEventHandler ListChanged
        {
            add { listChangedHandler += value; }
            remove { listChangedHandler -= value; }
        }

#if defined(USE_HOARD)
#pragma comment(lib, "libhoard.lib")
#endif

-Вас Гондурас не беспокоит?
-Не чеши, и не будет беспокоить

struct MyStruct{int x,y;};
template<class Archive> void serialize(Archive &ar,MyStruct 
&str,unsigned version)
{
    ar&y&x;
};

struct MyStruct{int x,y,area;};
template<> version_tag<MyStruct> {enum version=2;};

template<class Archive> void serialize(Archive &ar,MyStruct 
&str,unsigned version)
{
    ar&y&x;
    if (version==2)
       ar&area;
};

E>Не многим хуже чем Проект Visual Generator

Автор: adontz
Дата: 07.07.05

struct
{
 int x;
 int y;
}

SDB>Исходники поменять — не проблема. "Уголовное дело — это вам не брюки не с рантом, уголовное дело шьется в пять секунд..." (с) Довлатов. Искренне — овчинка того стоит? Я имею ввиду — в "маленьком" и "среднем" десктопном приложении (если уж совсем нахальничать — сходите на http://zarezky.spb.ru/projects.html и просто прикидочно выскажетесь относительно целесообразности).

class document 
{
  memory_pool mp;
  void* alloc( size_t sz ) { return mp.alloc(sz); }
}

  ______________________
 / Version 1 \ Version 2 \
|                         |
| [x] width               |
| [x] height              |
| [_] area                |
|                         |
---------------------------

  ______________________
 / Version 1 / Version 2 \
|                         |
| [x] width               |
| [x] height              |
| [x] area                |
|                         |
---------------------------

A>

int f(int);
void f(float);
char * f(my_type);

int@f@int@
void@f@float@
char@@f@my_class@

class Window : public WindowBase
{
 public:
  void OnSize(SIZE sizeOld, SIZE sizeNew);
}
BEGIN_MESSAGE_MAP(Window)
ON_MESSAGE(SIZE, OnSize)
END_MESSAGE_MAP

class Window : public WindowBase
{
 public:
  void OnSize(const message_data<SIZE> & msgdata);
}

class Window : public WindowBase
{
 public:
    [msg_handler:WM_SIZE] void OnSize(const message_data<SIZE> & msgdata);
}

C>class Window : public WindowBase
C>{
C> public:
C>    [msg_handler:WM_SIZE] void OnSize(const message_data<SIZE> & msgdata);
C>}
C>

class Window : public WindowBase
{
public:
    [msg_handler:WM_SIZE:OnSize]
};

class Window : public WindowBase
{
public:
    [msg_handler:WM_SIZE:OnSize]
    void    OnSize( unsigned int cx, unsigned int cy );
};

class Window : public WindowBase
{
public:
    [msg_handler:WM_SIZE:OnSize]
    {
       //Какие там у параметров имена????
    }
};

template <class SuperHeap>
class FreelistHeap : public SuperHeap {
public:
  
  inline FreelistHeap (void)
    : myFreeList (NULL)
    {}

  inline ~FreelistHeap (void)
    {
#if 0
      // Delete everything on the free list.
      void * ptr = myFreeList;
      while (ptr != NULL) {
    // assert (nObjects > 0);
    assert (ptr != NULL);
    void * oldptr = ptr;
    ptr = (void *) ((freeObject *) ptr)->next;
    SuperHeap::free (oldptr);
      }
#endif
    }

  inline void * malloc (const size_t sz) {
    // Check the free list first.
    void * ptr = myFreeList;
    if (ptr == NULL) {
      ptr = SuperHeap::malloc (sz);
    } else {
      myFreeList = myFreeList->next;
    }
    return ptr;
  }
  
  inline void free (void * ptr) {
    // Add this object to the free list.
    assert (ptr != NULL);
    (reinterpret_cast<freeObject *>(ptr))->next = myFreeList;
    myFreeList = reinterpret_cast<freeObject *>(ptr);
  }

  inline void clear (void) {
    myFreeList = NULL;
    SuperHeap::clear();
  }

private:

  /// The linked list pointer we embed in the freed objects.
  class freeObject {
  public:
    freeObject * next;
  };

  /// The head of the linked list of freed objects.
  freeObject * myFreeList;

};

1. Code portability — depend only on ANSI C++ facilities.
2. Code economy — exploit features of C++ such as RTTI, templates,
and multiple inheritance, etc. where appropriate to make code
shorter and simpler to use.
3. Independent versioning for each class definition. That is, when a
class definition changed, older files can still be imported to the
new version of the class.
4. Deep pointer save and restore. That is, save and restore of
pointers saves and restores the data pointed to.
5. Proper restoration of pointers to shared data.
6. Serialization of STL containers and other commonly used templates.
7. Data Portability — Streams of bytes created on one platform should
be readable on any other.
8. Orthogonal specification of class serialization and archive
format. That is, any file format should be able to store
serialization of any arbitrary set of C++ data structures without
having to alter the serialization of any class.
9. Non-intrusive. Permit serialization to be applied to unaltered
classes. That is, don't require that classes to be serialized be
derived from a specific base class or implement specified member
functions. This is necessary to easily permit serialization to be
applied to classes from class libraries that we cannot or don't
want to have to alter.
10. The *archive* interface must be simple enough to easily permit
creation of a new type of archive.
11. The *archive* interface must be rich enough to permit the creation
of an *archive* that presents serialized data as XML in a useful
manner.

template<class Archive>
void serialize(Archive & ar, const unsigned int version)

template<class Archive>
void load(Archive & ar, const unsigned int version)