Re[9]: Cpp-Object - C/C++

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

Для решения этих и других проблем был создан проект C++ Object.

Основные цели проекта:

Создание иерархие типов. (например int32 <- value_type <- object).

Встроенная сериализация каждого типа.
Дальнейшие цели будут добавленны мере развития библиотеки.

Пример использования

Стандартный код:

#include <iostream>

void f(int& i)
{
 i = 1;
}

void g(int i)
{
 std::cout << i;
}

int main()
{
 int i;
 f(i);
 g(i);
}

Код с использованием библиотеки:

#include <iostream>

void f(out_int32 i)
{
 i = 1;
}

void g(in_int32 i)
{
 std::cout << i;
}

int main()
{
 int32 i;
 f(i);
 g(i);
}

Комментарии приветствуются.

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

__>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

__>Для решения этих и других проблем был создан проект C++ Object.

__>Основные цели проекта:
__>

Создание иерархие типов. (например int32 <- value_type <- object).
__>

Встроенная сериализация каждого типа.
__>Дальнейшие цели будут добавленны мере развития библиотеки.

Зачем? Жабой заболели?
Мотивация ни в чем не убедила, кроме как в том что время свободное у вас есть.

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

__>void f(out_int32 i)
^^^^^^^^^^^
__>{
__> i = 1;
__>}

__>Комментарии приветствуются.
как это интересно возвращает результат?

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

__>>

void f(out_int32 i)
V>    ^^^^^^^^^^^
__>>{
__>> i = 1;
__>>}

V>как это интересно возвращает результат?

Очевидно out_int32 — ссылка.

Хотя как тогда обозначается ссылка на константу?
И наличие 2х разных синтаксисов — для ссылок на POD и не-POD типы ИМХО произведёт кашу.

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

__>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

Благая идея. А можно поподробнее и где, собственно, можно посмотреть на эту библиотеку? На sourceforge никаких исходников не нашел, не там искал?

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

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

__>>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

__>>Для решения этих и других проблем был создан проект C++ Object.

__>>Основные цели проекта:
__>>

Создание иерархие типов. (например int32 <- value_type <- object).
__>>

Встроенная сериализация каждого типа.
__>>Дальнейшие цели будут добавленны мере развития библиотеки.

G>Зачем? Жабой заболели?
Вы про Java ?
G>Мотивация ни в чем не убедила, кроме как в том что время свободное у вас есть.
Мотивация в том, что хочется писать нормальный код.

Зачем нужно писать & и * если можно без них.
Почему нельзя определить семантику передачи аргументов ?
Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
Почему нельзя написать код так, чтобы он работал для всего ?

Из-за того, что небыло представленно решение этих и других проблем придумали обходные решения, вместо того, чтобы решить саму проблему.

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

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

__>>>

void f(out_int32 i)
V>>    ^^^^^^^^^^^
__>>>{
__>>> i = 1;
__>>>}

V>>как это интересно возвращает результат?

GN>Очевидно out_int32 — ссылка.

GN>Хотя как тогда обозначается ссылка на константу?
GN>И наличие 2х разных синтаксисов — для ссылок на POD и не-POD типы ИМХО произведёт кашу.
Наоборот, нужен один синтаксис на все.

Тут есть несколько вариантов:
1.

void f(out<int32> i);
void f(out<myclass> m);

2.

void f(out_int32 i);
void f(out_myclass m);

Насчет ссылки и ссылки на константу можно добавить: ref и cref:
1.

int32 i;
ref<int32> j(i);

2.

int32 i;
ref_int32 j(i);

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

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

__>>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

_>Благая идея. А можно поподробнее и где, собственно, можно посмотреть на эту библиотеку? На sourceforge никаких исходников не нашел, не там искал?

Исходников нет, т.к. проект только открылся.
На данный момент хочется обсудить детали проекта.

P.S.
Если вы хотите поучавствовать в проекте, могу вас добавить в разработчики

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

__>Зачем нужно писать & и * если можно без них.
Можно. Смарт-пойнтеры и фабрики в помощь.
__>Почему нельзя определить семантику передачи аргументов ?
Гм... ее из сигнатуры функции почти всегда видно. Разве нет? отрабатывайте стиль.
__>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
__>Почему нельзя написать код так, чтобы он работал для всего ?
Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.

__>Из-за того, что небыло представленно решение этих и других проблем придумали обходные решения, вместо того, чтобы решить саму проблему.

Полноте... я вот о такой проблеме до вчерашнего вечера и не подозревал. В чем проблема то?

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

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

__>>Зачем нужно писать & и * если можно без них.
G>Можно. Смарт-пойнтеры и фабрики в помощь.
Без ссылок там все равно не обойтись.
__>>Почему нельзя определить семантику передачи аргументов ?
G>Гм... ее из сигнатуры функции почти всегда видно. Разве нет? отрабатывайте стиль.
void f(int& i);
Это out или in-out аргумент ?
Без документации нельзя узнать.
__>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
А как вы решаете эти проблемы:

template<typename T>
size_t f(T const& t)
{
 return t.size();
}

f(1); // не работает.

Обход:

template<bool primitive>
struct f_impl
{
 template<typename T>
 static void f(T const& t)
 {
  return sizeof(t);
 }
};

template<>
struct f_impl<false>
{
 template<typename T>
 static void f(T const& t)
 {
  return t.size();
 }
};

template<typename T>
size_t f(T const& t)
{
 return f_impl<is_primitive<T>::value>::f(t);

f(1); // теперь работает

А можно ведь было:

size_t f(object& t)
{
 return t.size();
}

__>>Почему нельзя написать код так, чтобы он работал для всего ?
G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
А мне кажется наоборот.
Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.
__>>Из-за того, что небыло представленно решение этих и других проблем придумали обходные решения, вместо того, чтобы решить саму проблему.

G>Полноте... я вот о такой проблеме до вчерашнего вечера и не подозревал. В чем проблема то?
Смотрите выше.

> G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
> А мне кажется наоборот.
> Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.

А что делать с классами, которые нужно передавать по значению?

Posted via RSDN NNTP Server 2.0

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

__>>>Почему нельзя определить семантику передачи аргументов ?
G>>Гм... ее из сигнатуры функции почти всегда видно. Разве нет? отрабатывайте стиль.
__>void f(int& i);
__>Это out или in-out аргумент ?
__>Без документации нельзя узнать.
Я же говорил — стиль вырабатывайте. Определенно out-параметр. Был бы ин — был бы конст. Был бы ин-оут — имел бы префикс io_

И вообще — что за маразм — инаут параметры? дизайн с штангенциркулем проверьте...

__>>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
__>А как вы решаете эти проблемы:
__>

__>template<typename T>
__>size_t f(T const& t)
__>{
__> return t.size();
__>}

__>f(1); // не работает.
__>

__>Обход:
__>

__>template<bool primitive>
__>struct f_impl
__>{
__> template<typename T>
__> static void f(T const& t)
__> {
__>  return sizeof(t);
__> }
__>};

__>template<>
__>struct f_impl<false>
__>{
__> template<typename T>
__> static void f(T const& t)
__> {
__>  return t.size();
__> }
__>};

__>template<typename T>
__>size_t f(T const& t)
__>{
__> return f_impl<is_primitive<T>::value>::f(t);

__>f(1); // теперь работает
__>

__>А можно ведь было:
__>

__>size_t f(object& t)
__>{
__> return t.size();
__>}
__>

__>>>Почему нельзя написать код так, чтобы он работал для всего ?
А они у меня почти не возникают. Можно еще вот так:

template <typename T>
typename boost::enable_if<T, boost::is_integral<T>::value >::type objSize(T primitive);
template <typename T>
typename boost::enable_if<T, !boost::is_integral<T>::value >::type objSize(T const &notPrimitive);

Т ч учите матчасть, а не городите 3звеньевые шаблоны.
Но еще лучще — ввести концепт на то, что параметром функции является только класс с определенным методом size()

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

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

>> G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
>> А мне кажется наоборот.
>> Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.

S>А что делать с классами, которые нужно передавать по значению?
На то вам будет отдельный классик val_object

Хочется в оффтоп немного высказаться.
Когда я пишу на плюсах — я могу не совсем точно представлять, что я делаю, но я точно знаю, как это сделать. Если у меня нет ответа "как" — я сажусь моделировать, и для этого выбираю уже любой инструментарий. В программировании на плюсах всегда оч. важную роль играла профессиональная подготовка программиста. А в случае вашей неродившейся библиотеки человека профессионального будет прежде всего напрягать избыточный, фальшивый и уж поверьте совсем не интуитивный метод работы с переменными. А человека непрофессионального наборот отвратит от изучения основ языка и к сведению программирования на плюсах как на еще одном диалекте жабы (видал таких, с опытом от жабы — классный полиморфичный код пишут, но это не плюсы). В общем, на мой взгляд — ненужное баловство.

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

>> G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
>> А мне кажется наоборот.
>> Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.

S>А что делать с классами, которые нужно передавать по значению?

Например те кто наследуется от value_type будут передаваться по значению.

struct a : value_type
{
 int i;
}

void f(in<a> x); // по значению

class b : object
{
 int i;
}

void f(in<b> y); // по ссылке

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

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

__>>>>Почему нельзя определить семантику передачи аргументов ?
G>>>Гм... ее из сигнатуры функции почти всегда видно. Разве нет? отрабатывайте стиль.
__>>void f(int& i);
__>>Это out или in-out аргумент ?
__>>Без документации нельзя узнать.
G>Я же говорил — стиль вырабатывайте. Определенно out-параметр. Был бы ин — был бы конст. Был бы ин-оут — имел бы префикс io_

io_ это хорошо, а inout это плохо ?

G>И вообще — что за маразм — инаут параметры? дизайн с штангенциркулем проверьте...
А что делать с тем кодом, который не я писал ?

__>>>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>>>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
__>>А как вы решаете эти проблемы:
__>>

__>>template<typename T>
__>>size_t f(T const& t)
__>>{
__>> return t.size();
__>>}

__>>f(1); // не работает.
__>>

__>>Обход:
__>>

__>>template<bool primitive>
__>>struct f_impl
__>>{
__>> template<typename T>
__>> static void f(T const& t)
__>> {
__>>  return sizeof(t);
__>> }
__>>};

__>>template<>
__>>struct f_impl<false>
__>>{
__>> template<typename T>
__>> static void f(T const& t)
__>> {
__>>  return t.size();
__>> }
__>>};

__>>template<typename T>
__>>size_t f(T const& t)
__>>{
__>> return f_impl<is_primitive<T>::value>::f(t);

__>>f(1); // теперь работает
__>>

__>>А можно ведь было:
__>>

__>>size_t f(object& t)
__>>{
__>> return t.size();
__>>}
__>>

__>>>>Почему нельзя написать код так, чтобы он работал для всего ?
G>А они у меня почти не возникают. Можно еще вот так:
G>

G>template <typename T>
G>typename boost::enable_if<T, boost::is_integral<T>::value >::type objSize(T primitive);
G>template <typename T>
G>typename boost::enable_if<T, !boost::is_integral<T>::value >::type objSize(T const &notPrimitive);
G>

Это вы считаете красивее ?
G>Т ч учите матчасть, а не городите 3звеньевые шаблоны.
G>Но еще лучще — ввести концепт на то, что параметром функции является только класс с определенным методом size()

Ну ну, попробуйте реализовать универсальный has_method

G>А если серьезно — ни к чему засорять язык ненужными надстройками, мощь плюсов — в том числе и в поддержке интегральных типов. А вот если вы строите концептуально красивую систему — ну не будет у вас там нужды оперировать интегральными типами, классики в основном бегать будут...
А передачу типов как осуществлять ?
В конечном итоге где-то есть интеракция с API который написан на С

>>> G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
>>> А мне кажется наоборот.
>>> Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.
>
> S>А что делать с классами, которые нужно передавать по значению?
>
> Например те кто наследуется от value_type будут передаваться по значению.
>

> struct a : value_type
> {
> int i;
> }
> 
> void f(in<a> x); // по значению
> 
> class b : object
> {
> int i;
> }
> 
> void f(in<b> y); // по ссылке
>

А если класс библиотечный? А если мне надо его в одном месте передавать по ссылке, в другом — по значению?

Posted via RSDN NNTP Server 2.0

Здравствуйте, _nn_, Вы писали:
__>void f(int& i);
__>Это out или in-out аргумент ?
__>Без документации нельзя узнать.

void f(int& i);// i - inout
void f(int i);// i - in
void f(const int& i);// i - in

__>>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
Согласен с Garrrrr, хотя иногда примитивные типамы и доставляют некоторые неудобства (а иногда — преимущества

).

__>А как вы решаете эти проблемы:
__>

__>template<typename T>
__>size_t f(T const& t)
__>{
__> return t.size();
__>}

__>f(1); // не работает.
__>

__>Обход:
...

__>>>Почему нельзя написать код так, чтобы он работал для всего ?

ИМХО крайне неудачный пример. Что должна возвращать f? Размер в байтах? Размер в элементах? Вообще мне кажется, что постулат "чтобы работало для всего" неверен. Лучше получить от компилятора по рукам на непредвиденную ситуацию, чем работать с отладчиком

G>>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
__>А мне кажется наоборот.
__>Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.
А вот это я уж сам как-нибудь решу.

__>>>Из-за того, что небыло представленно решение этих и других проблем придумали обходные решения, вместо того, чтобы решить саму проблему.

G>>Полноте... я вот о такой проблеме до вчерашнего вечера и не подозревал. В чем проблема то?
__>Смотрите выше.
Ничего убедительного выше я не увидел

.

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

>>>> G>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
>>>> А мне кажется наоборот.
>>>> Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.
>>
>> S>А что делать с классами, которые нужно передавать по значению?
>>
>> Например те кто наследуется от value_type будут передаваться по значению.
>>

>> struct a : value_type
>> {
>> int i;
>> }
>> 
>> void f(in<a> x); // по значению
>> 
>> class b : object
>> {
>> int i;
>> }
>> 
>> void f(in<b> y); // по ссылке
>>

S>А если класс библиотечный? А если мне надо его в одном месте передавать по ссылке, в другом — по значению?

Обычно.

P.S.
У вас есть предложение как красивее решить ?

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

<skip>

__>>>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>>>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
B>Согласен с Garrrrr, хотя иногда примитивные типамы и доставляют некоторые неудобства (а иногда — преимущества

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

<sip>

B>ИМХО крайне неудачный пример. Что должна возвращать f? Размер в байтах? Размер в элементах? Вообще мне кажется, что постулат "чтобы работало для всего" неверен. Лучше получить от компилятора по рукам на непредвиденную ситуацию, чем работать с отладчиком

Надо будет придумать пример получше

> S>А если класс библиотечный? А если мне надо его в одном месте передавать по ссылке, в другом — по значению?
>
> Обычно.

>
> P.S.
> У вас есть предложение как красивее решить ?

Я вообще не понимаю, для чего вы все это затеваете. Умному оно не надо, а дураку все равно не поможет.

Posted via RSDN NNTP Server 2.0

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

>> S>А если класс библиотечный? А если мне надо его в одном месте передавать по ссылке, в другом — по значению?
>>
>> Обычно.

>>
>> P.S.
>> У вас есть предложение как красивее решить ?

S>Я вообще не понимаю, для чего вы все это затеваете. Умному оно не надо, а дураку все равно не поможет.
Исправить С++

P.S.
Иногда нужна фабрика, которая позволит создать любой тип, а не некоторые типы

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

Имхо, чем больше типов, тем сложнее в них разобраться. Этот проект имеет право на жизнь в коком-то совсем кастомном фреймворке, но не повсеместно. Самый большой нерулез — необходимость насделоваться от val_obj, object

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, _nn_, Вы писали:

КЛ>Имхо, чем больше типов, тем сложнее в них разобраться. Этот проект имеет право на жизнь в коком-то совсем кастомном фреймворке, но не повсеместно. Самый большой нерулез — необходимость насделоваться от val_obj, object
Это из-за кривого дизайна С++

Можно в макрос обернуть, тогда наследование автоматически будет.

> S>Я вообще не понимаю, для чего вы все это затеваете. Умному оно не надо, а дураку все равно не поможет.
> Исправить С++

>
> P.S.
> Иногда нужна фабрика, которая позволит создать любой тип, а не некоторые типы

Создавать вообще любой тип без поддержки языка все равно не получится. Создавать "почти любой" тип требуется крайне редко, а поддержка такой функциональности вряд ли будет бесплатной. Как минимум — приведет к увеличению времени компиляции-линковки, возможно существенному. Ну и ручками про каждый тип все равно писать что-нибудь придется. Вряд ли это будет сильно востребовано.

Posted via RSDN NNTP Server 2.0

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

>> S>Я вообще не понимаю, для чего вы все это затеваете. Умному оно не надо, а дураку все равно не поможет.
>> Исправить С++

>>
>> P.S.
>> Иногда нужна фабрика, которая позволит создать любой тип, а не некоторые типы

S>Создавать вообще любой тип без поддержки языка все равно не получится.
Увы это так

S>Создавать "почти любой" тип требуется крайне редко, а поддержка такой функциональности вряд ли будет бесплатной. Как минимум — приведет к увеличению времени компиляции-линковки, возможно существенному. Ну и ручками про каждый тип все равно писать что-нибудь придется. Вряд ли это будет сильно востребовано.

Но можно все классы пронаследовать от object, в каждый класс добавить идентификатор и можно будет писать:

smart_ptr<object> create_object(id_type id);

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

__>Но можно все классы пронаследовать от object, в каждый класс добавить идентификатор и можно будет писать:
__>

__>smart_ptr<object> create_object(id_type id);
__>

А в фабрике большой-большой свитч по id? Я так же могу сделать шаблонную фабрику и специализировать ее под все поддерживаемые типы.

__>Это из-за кривого дизайна С++

Поясните, пожалуйста.

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

G>>Но еще лучще — ввести концепт на то, что параметром функции является только класс с определенным методом size()

__>Ну ну, попробуйте реализовать универсальный has_method

Гм... концепт — это не enable_if, а то, что дает вменяемую и быстро понимаемую лшибку компиляции. Учите матчасть, раздел буста о концептах. Весьма там здравые идеи, хотя реализация как обычно подкачала

G>>А если серьезно — ни к чему засорять язык ненужными надстройками, мощь плюсов — в том числе и в поддержке интегральных типов. А вот если вы строите концептуально красивую систему — ну не будет у вас там нужды оперировать интегральными типами, классики в основном бегать будут...
__>А передачу типов как осуществлять ?
__>В конечном итоге где-то есть интеракция с API который написан на С

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

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

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

__>>Но можно все классы пронаследовать от object, в каждый класс добавить идентификатор и можно будет писать:
__>>

__>>smart_ptr<object> create_object(id_type id);
__>>

G>А в фабрике большой-большой свитч по id? Я так же могу сделать шаблонную фабрику и специализировать ее под все поддерживаемые типы.

switch, как вы могли произнести это слово ?

Фабрика с саморегистрацией ! http://rsdn.ru/forum/?mid=1788774

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

__>>Это из-за кривого дизайна С++

L_L>Поясните, пожалуйста.

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

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

Может тогда нужен другой язык, а не С++ ?

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

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

L_L>Может тогда нужен другой язык, а не С++ ?
Нужен.
Но что делать если надо на С++

> __>>Но можно все классы пронаследовать от object, в каждый класс добавить идентификатор и можно будет писать:
> __>>

> __>>smart_ptr<object> create_object(id_type id);
> __>>

> G>А в фабрике большой-большой свитч по id? Я так же могу сделать шаблонную фабрику и специализировать ее под все поддерживаемые типы.
>
> switch, как вы могли произнести это слово ?

>
> Фабрика с саморегистрацией ! http://rsdn.ru/forum/?mid=1788774

Вы хорошо себе представляете, во что это выльется, если регистрировать абсолютно все типы? Лично мне такой хоккей не нужен — разве что в каких-нибудь мелких проектах, где всего сотня-другая типов используется.

Posted via RSDN NNTP Server 2.0

> S>Создавать вообще любой тип без поддержки языка все равно не получится.
> Увы это так

> S>Создавать "почти любой" тип требуется крайне редко, а поддержка такой функциональности вряд ли будет бесплатной. Как минимум — приведет к увеличению времени компиляции-линковки, возможно существенному. Ну и ручками про каждый тип все равно писать что-нибудь придется. Вряд ли это будет сильно востребовано.
>
> Но можно все классы пронаследовать от object, в каждый класс добавить идентификатор и можно будет писать:
>

> smart_ptr<object> create_object(id_type id);
>

Кто будет следить за уникальностью идентификаторов? Что будете делать в случае шаблонов? Что будете делать с Dll'ками — экспортировать/импортировать функции создания объектов? Все три тыщщи штук? А что делать с объектами без конструкторов по умолчанию?

Posted via RSDN NNTP Server 2.0

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

__>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

__>Для решения этих и других проблем был создан проект C++ Object.

__>Основные цели проекта:
__>

Создание иерархие типов. (например int32 <- value_type <- object).
__>

Встроенная сериализация каждого типа.
__>Дальнейшие цели будут добавленны мере развития библиотеки.

Быть может managed C++ спасёт Отца русской демократии ?
(просто предположение)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

L_L>>Может тогда нужен другой язык, а не С++ ?
__>Нужен.
__>Но что делать если надо на С++

Уволится и поступить на работу в контору, где разработки ведутся на Java

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

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

__>>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

__>>Для решения этих и других проблем был создан проект C++ Object.

__>>Основные цели проекта:
__>>

Создание иерархие типов. (например int32 <- value_type <- object).
__>>

Встроенная сериализация каждого типа.
__>>Дальнейшие цели будут добавленны мере развития библиотеки.

S>Быть может managed C++ спасёт Отца русской демократии ?
S>(просто предположение)

Тогда уже C#

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

>> S>Создавать вообще любой тип без поддержки языка все равно не получится.
>> Увы это так

>> S>Создавать "почти любой" тип требуется крайне редко, а поддержка такой функциональности вряд ли будет бесплатной. Как минимум — приведет к увеличению времени компиляции-линковки, возможно существенному. Ну и ручками про каждый тип все равно писать что-нибудь придется. Вряд ли это будет сильно востребовано.
>>
>> Но можно все классы пронаследовать от object, в каждый класс добавить идентификатор и можно будет писать:
>>

>> smart_ptr<object> create_object(id_type id);
>>

S>Кто будет следить за уникальностью идентификаторов? Что будете делать в случае шаблонов? Что будете делать с Dll'ками — экспортировать/импортировать функции создания объектов? Все три тыщщи штук?
Если будут одинаковые иднетификаторы программа просто не запустится например

S> А что делать с объектами без конструкторов по умолчанию?
boost.in_place_factory

Решение не настроенно на универсальность, в рамках С++, видимо, полной универсальности не выйдет

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

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

S>>Быть может managed C++ спасёт Отца русской демократии ?
S>>(просто предположение)

__>Тогда уже C#

Я, в принципе к тому клоню

Но Вы же сами написали:

Но что делать если надо на С++

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

S>>>Быть может managed C++ спасёт Отца русской демократии ?
S>>>(просто предположение)

__>>Тогда уже C#

S>Я, в принципе к тому клоню

S>Но Вы же сами написали:
S>

S>Но что делать если надо на С++

Вы предложили MC++, я говорю, что лучше уже C#.
Но пока надо С++ обычный

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

__>>>Почему нельзя определить семантику передачи аргументов ?
G>>Гм... ее из сигнатуры функции почти всегда видно. Разве нет? отрабатывайте стиль.
__>void f(int& i);
__>Это out или in-out аргумент ?

Это in-out.

void f(const int& i);
Это in.

__>Без документации нельзя узнать.

По прототипу?

__>>>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
G>>Ну у каждого свои склонности. Кто то только через извращения проблемы решать может.
__>А как вы решаете эти проблемы:
__>[c]
__>template<typename T>
__>size_t f(T const& t)
__>{
__> return t.size();
__>}

__>f(1); // не работает.

...skip...

В таком случае можно полностью отказаться от встроенных типов.

__>>>Почему нельзя написать код так, чтобы он работал для всего ?
G>>Угу, в отдельно взятых 2 тысячах строк кода. Для того, чтобы ваш подход работал для всех, он должен стать стандартом. А предпосылок для этого в мотивации как то маловато. Скажу более — эта библиотека будет даже вредна для неокрепших умов.
__>А мне кажется наоборот.
__>Намного проще знать, что все типы это классы, чем вспоминать, что иногда есть примитвные типы, которые нужно передавать по значению, а не по ссылке.

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

А для нового кода часто используется принцип "чем меньше кода тем он лучше". Если можно использовать просто int или вместо этого создать класс Int производный от Object и следить чтобы ни кто int не использовал, то 99.9% имхо не сильно задумываясь будут использовать int.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

__>>>>

void f(out_int32 i)
V>>>    ^^^^^^^^^^^
__>>>>{
__>>>> i = 1;
__>>>>}

V>>>как это интересно возвращает результат?

GN>>Очевидно out_int32 — ссылка.

GN>>Хотя как тогда обозначается ссылка на константу?
GN>>И наличие 2х разных синтаксисов — для ссылок на POD и не-POD типы ИМХО произведёт кашу.
__>Наоборот, нужен один синтаксис на все.

__>Тут есть несколько вариантов:
__>1.
__>

__>void f(out<int32> i);
__>void f(out<myclass> m);
__>

__>2.
__>

__>void f(out_int32 i);
__>void f(out_myclass m);
__>

__>Насчет ссылки и ссылки на константу можно добавить: ref и cref:
__>1.
__>

__>int32 i;
__>ref<int32> j(i);
__>

__>2.
__>

__>int32 i;
__>ref_int32 j(i);
__>

А, добавить in/out/ref/ptr/... классы для каждого типа? И не забыть в функциях для каждого out объекта распределить память, даже если значение в него в случае ошибки мы помещать не будем. Для in-ot/ref наверное надо освободить и распределить память? CORBA получится?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

__>>Без документации нельзя узнать.

O>По прототипу?
Что делает эта функция?

int * f(int *);

И что делать с обоими указателями? Удалять или нет?

Вам не нравится синтаксис С++? Пишите на Java.
А то, что вы предлагаете — всего лишь уродство.
Это мое имхо.

Кстати, есть где-то пример с дефайнами на тему преведа. Может так будем программировать?

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

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

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

__>>>Одна из проблем C++ в том, что существуют так называемые примитивные типы.
__>>>Стандарное решением было ввести специализацию для примитивных типов и для остальных типов.

__>>>Для решения этих и других проблем был создан проект C++ Object.

__>>>Основные цели проекта:
__>>>

Создание иерархие типов. (например int32 <- value_type <- object).
__>>>

Встроенная сериализация каждого типа.
__>>>Дальнейшие цели будут добавленны мере развития библиотеки.

G>>Зачем? Жабой заболели?
__>Вы про Java ?
G>>Мотивация ни в чем не убедила, кроме как в том что время свободное у вас есть.
__>Мотивация в том, что хочется писать нормальный код.

__>Зачем нужно писать & и * если можно без них.
__>Почему нельзя определить семантику передачи аргументов ?
__>Почему нужно делать разного рода извращения, чтобы работать с примитивными типами ?
__>Почему нельзя написать код так, чтобы он работал для всего ?

__>Из-за того, что небыло представленно решение этих и других проблем придумали обходные решения, вместо того, чтобы решить саму проблему.

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

int * f(int *);

PC>И что делать с обоими указателями? Удалять или нет?

Если это C++, а не C, то тут довольно понятно.
Если бы функция хотела, чтобы мы отдали ей int во владение, она бы принимала auto_ptr<int>. Раз оно не так, мы должны его убить сами. Напротив, если бы функция хотела вернуть нам int, чтобы мы его потом удалили, она бы вернула его через auto_ptr<int>. Это не так, значит, вернутый указатель не наш, и удалять его не нам

__>Это из-за кривого дизайна С++

__>Можно в макрос обернуть, тогда наследование автоматически будет.

Я лежу! мля...
напиши свой язык! поглядим, что получится...
кривой дизайн... исправитель нашелся... уморил...

__>Но что делать если надо на С++

выпей йаду!

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

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

__>>>

void f(out_int32 i)
V>>    ^^^^^^^^^^^
__>>>{
__>>> i = 1;
__>>>}

V>>как это интересно возвращает результат?

GN>Очевидно out_int32 — ссылка.
ну лучше уж обернуть int в int_class и написать как
void f(_out int_class& i) или void f(OUT int_class& i) — как в МС более-менее понятно что.

GN>Хотя как тогда обозначается ссылка на константу?
GN>И наличие 2х разных синтаксисов — для ссылок на POD и не-POD типы ИМХО произведёт кашу.
ага, какая уже имеется в MSVC2005 в переписанных макрософтом хидерах сишной библиотеки и не только :P

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

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

__>>>Это из-за кривого дизайна С++

L_L>>Поясните, пожалуйста.

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

А в чём проблема? (с шаблонной функцией)

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

А>.............
А>................................................
А>.....................................................

Что означает 599 справа от вашего имени?

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

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

void f( void * );

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

MTP>

MTP>void f( void * );
MTP>

MTP>

Это уже не любой тип.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

_nn_ wrote:

> Одна из проблем C++ в том, что существуют так называемые примитивные типы.

В чем же конкретно с ними проблема?

--
Maxim Yegorushkin

Posted via RSDN NNTP Server 2.0

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

I>Что означает 599 справа от вашего имени?

Идентефикатор Анонимов

Теперь видно, что Re[3]: Cpp-Object и Re[7]: Cpp-Object написаны одним человеком, а Re[7]: Cpp-Object — другим. (хотя верить этим цифрам на 100% нельзя)

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

ВВ>Это уже не любой тип.
То есть все проблемы от того, что я не могу передать в функцию с такой сомнительной сигнатурой rvalue или о чем идет речь?

P.S. Вообще, было бы интересно посмотерть на реализацию функции, "которая будет принимать любой тип".

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

O>А, добавить in/out/ref/ptr/... классы для каждого типа? И не забыть в функциях для каждого out объекта распределить память, даже если значение в него в случае ошибки мы помещать не будем. Для in-ot/ref наверное надо освободить и распределить память? CORBA получится?

Никаких лишнийх выделения памяти нет.
2 следущие функции равнозначны:

void f(in<int> i) { cout << i; }
void f(int i) { cout << i; }

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

__>>>>Это из-за кривого дизайна С++

L_L>>>Поясните, пожалуйста.

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

R>А в чём проблема? (с шаблонной функцией)

Ее не сделать виртуальной.
Нельзя вызывает ее из dll.

R>

Спасибо всем за комментарии.

Итак, что будет в библиотеке:
1. Возможность рефлексия для любого типа (требуется определение структуры типа).
2. Возможность использовать рефлексию как во времени компиляции, так и во времени выполнения.
3. Сериализация и десериализация за счет рефлексии.
4. Унифицированная передача аргументов.

Требования:
1. Минимум оверхеда.
2. При использовании рефлексии времени компиляции код должен приближаться к прямому обращению с объектом.

Примеры:

1. Рефлексия:

Во времени выполнения:

object o;
o.invoke("f", 1); // o.f(1);

Во времени компиляции:

object o;
o.invoke<f_tag>(1); // o.f(1);

object — Некий аналог boost::any с поддержкой рефлексии:

a x;
object o(x);

o.invoke<f_tag>(1); // x.f(1);

a z = object_cast<a>(o);

2. Унифицированная передача аргументов:

in:

void f(in<int> x); // <=> void f(int x);

out:

void f(out<int> x); // <=> void f(int& x);

inout:

void f(inout<int> x); // <=> void f(int& x);

ref:

void f(out<int> x) // <=> void f(int& x);
{
 ref<int> y(x); // int& y(x);
}

cref:

void f(in<int> x) // <=> void f(int x);
{
 cref<int> y(x); // int const& y(x);
}

Код выше дан в качестве примера, это не окончательный вид.

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

MTP>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Это уже не любой тип.
MTP>То есть все проблемы от того, что я не могу передать в функцию с такой сомнительной сигнатурой rvalue или о чем идет речь?

MTP>P.S. Вообще, было бы интересно посмотерть на реализацию функции, "которая будет принимать любой тип".

void f(object const& o)
{
 try
 {
  o.invoke("f", 1); // o.f(1);
 }
 catch(invalid_invoke)
 {
 }
}

Сойдет ?

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

__>Сойдет ?

Ясно. Про reflection в исходном сообщении речи не шло, это несколько меняет дело. Хотя, насколько необходима такая функциональности в C++ для меня не очевидно, но в любом случае удачи в этом проекте

.

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

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

__>>Сойдет ?

MTP>Ясно. Про reflection в исходном сообщении речи не шло, это несколько меняет дело. Хотя, насколько необходима такая функциональности в C++ для меня не очевидно, но в любом случае удачи в этом проекте

.
Представьте, что можно передавать любой тип, работать с ним, а потом сохранить состояние.
Далее другая программа создает этот тип только из данных в виде байтов и может работать с ним.
(Допустим реализация типа находится в одной библиотеке (Dll), а 2 программы используют ее).

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

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

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

__>>>Сойдет ?

MTP>>Ясно. Про reflection в исходном сообщении речи не шло, это несколько меняет дело. Хотя, насколько необходима такая функциональности в C++ для меня не очевидно__>Представьте, что можно передавать любой тип, работать с ним, а потом сохранить состояние.
__>Далее другая программа создает этот тип только из данных в виде байтов и может работать с ним.
__>(Допустим реализация типа находится в одной библиотеке (Dll), а 2 программы используют ее).
MTP>>, но в любом случае удачи в этом проекте

.
Спасибо

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

MTP>P.S. Вообще, было бы интересно посмотерть на реализацию функции, "которая будет принимать любой тип".

Шаблонная функция с перегрузкой сойдет?

Здравствуйте, _nn_, Вы писали:
__>Без ссылок там все равно не обойтись.
и что?
__>void f(int& i);
__>Это out или in-out аргумент ?
__>Без документации нельзя узнать.
Хаха*3

Это out-аргумент, ибо не константный. Если константный — то in.
__>А как вы решаете эти проблемы:
__>

__>template<typename T>
__>size_t f(T const& t)
__>{
__> return t.size();
__>}

__>f(1); // не работает.
__>

Неверный код потому и не работает. Это только у Вас такие проблемы, у нас таких нет

__>Обход:
__>

__>template<bool primitive>
__>struct f_impl
__>{
__> template<typename T>
__> static void f(T const& t)
__> {
__>  return sizeof(t);
__> }
__>};

__>template<>
__>struct f_impl<false>
__>{
__> template<typename T>
__> static void f(T const& t)
__> {
__>  return t.size();
__> }
__>};

__>template<typename T>
__>size_t f(T const& t)
__>{
__> return f_impl<is_primitive<T>::value>::f(t);

__>f(1); // теперь работает
__>

__>А можно ведь было:
__>

__>size_t f(object& t)
__>{
__> return t.size();
__>}
__>

__>Смотрите выше.

Изучите библиотеку "Boost Concept Check Library (BCCL)" — и проблема отпадёт сама.
Хотя при большом Вашем желании она (проблема) может у Вас и остаться...

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

__>void f(in<int> x); // <=> void f(int x);

А если имеем класс X определенный как

class X {
    int a[1000];
};

, то

void f(in<X> x); // <=> void f(X x);

или

void f(in<X> x); // <=> void f(X const& x);

?

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

Про in/out-параметры мысль есть:
Семантика взаимодействия вызывающей и вызываемой сторон не исчерпывается примитивами in/out/inout, так же как и value/reference/const_reference.
Devil in details — примитивы маскируют замысел, что потворствует ошибкам.

Как оно бывает на самом деле:

Далее — вызывающая и вызываемая стороны именуются клиентом и сервером, для краткости.
Примеры — на С++, хотя без труда их можно перевести на практически любой язык.
Если кого-то возмущают глобальные переменные — представьте себе, что это всё члены одного объекта одного класса. И клиент, и сервер — методы этого объекта.
Я привожу дистиллированные примеры для краткости и ясности; в жизни всё может выглядеть не так прозрачно, хотя и с теми же самыми эффектами.

1) Рандеву. Клиент и сервер выполняют совместную работу над одним экземпляром данных. Серверу может быть предоставлен некоторый интерфейс объекта (например, только константные члены).

void foo(ostream& ost)
// очевидно, что ostream - не value-тип, поэтому говорить об inout здесь сложно
// (значение туда-сюда не передаётся)
{
  ost << "hello";
  cout << endl;
  // в результате, если ost и cout - одно лицо, то ost будет очищен (endl вызывает flush)
}

Как клиент может выполнять совместную работу? да через callback-функции, например. Или ещё через какие-то побочные эффекты.

Самая простая и естественная реализация — передача по ссылке (константной или нет).

2) Передача значения. Клиент рассчитывает, что сервер разрывает связь между клиентским и серверным экземплярами данных.
Сервер не может модифицировать клиентский объект. Модификации клиентского объекта не отражаются на сервере.

// дистиллированный пример модификации (вместо int можете подставить какой-нибудь тяжеловесный объект)
void foo(int /*const&*/ fnf, int* hack) // раскомментируйте, чтобы взорвалось
{
  int x = fnf;
  ++(*hack);
  int y = fnf;
  assert(x == y);
}
int main()
{
  int x;
  foo(x, &x);
}

Самая простая реализация — принудительное создание копии (aka передача по значению). И поэтому иногда неэффективная.
Во многих случаях достаточно передавать по константной ссылке (причём обе стороны должны соблюдать аккуратность).
Изощрённая реализация — механизм copy-on-write. То есть объект передаётся посредством умной ссылки, и любая попытка модификации приводит к расщеплению копий.

3) Обязательное возвращение значения.
Если экземпляр клиента уже существует, то он заведомо не совпадает с экземпляром сервера, откуда происходит однократная передача значения.

string g;
string foo()
{
  string tmp = "(";
  tmp += g;
  tmp += ")";
  return tmp;
}
void foo2(string& dst) // по неопытности сделали рандеву
{
  dst = "[";
  dst += g;
  dst += "]";
}
void foo3(string& dst)
{
  string tmp = "{";
  tmp += g;
  tmp += "}";
  // ошибочка (см.ниже)
}
void foo4(string& dst)
{
  string tmp = "{";
  tmp += g;
  tmp += "}";
  dst = tmp;
}
int main()
{
  g = "hello";

  g = foo(); // "(hello)"

  // пример практически идентичен предыдущему: там тоже создаётся временный объект
  string tmp; foo2(tmp); g = tmp; // "[(hello)]";

  // а вот пример некорректной реализации: не обеспечили изоляцию
  foo2(g); // "[[]";

  // багфикс на стороне сервера
  foo3(g); // "[[]" - изолировать изолировали, а присвоить в конце забыли
  foo4(g); // "{[[]}" - теперь всё правильно
}

Языки обеспечивают изоляцию через временный объект (размещённый на стеке или в регистре — не важно) и иногда позволяют оптимизировать копирование (RVO, NRVO). Но только для единственного параметра (return) и исключительно по прихоти компилятора.
Чистоплотный выход — возвращать кортежи вместо разрозненных retval-параметров — может стоить довольно дорого и не всегда удобен.

pair<string,int> foo()
{
  string s = "{";
  s += rand()%2 ? "hello" : "goodbye";
  s += "}";
  int x = s.size();
  return make_pair(s,x);
}
int main()
{
  string s; int x;
  tie(s,x) = foo();
}

4) Необязательное возвращение значения.
Отличается от предыдущего тем, что значение может быть присвоено от 0 до 1 раза, по обстоятельствам.
Посредством return такое уже выразить сложно — разве что через бросок исключения.

Самая простая реализация — передавать ссылку и быть аккуратным.

5) Наконец, загадочный in-out. За ним может скрываться либо рандеву, либо экономичный способ сделать передачу исходного значения и обязательное/необязательное возвращение нового значения.

Обёртки параметров играют две роли
— обеспечивают подходящий транспорт (передачу копии или ссылки; COW и отложенное присваивание)
— выполняют проверки (было ли присвоено значение out-параметру, например)

boost::call_traits?

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

C>Здравствуйте, Pavel Chikulaev, Вы писали:

C>

int * f(int *);

PC>>И что делать с обоими указателями? Удалять или нет?

C>Если это C++, а не C, то тут довольно понятно.
C>Если бы функция хотела, чтобы мы отдали ей int во владение, она бы принимала auto_ptr<int>. Раз оно не так, мы должны его убить сами. Напротив, если бы функция хотела вернуть нам int, чтобы мы его потом удалили, она бы вернула его через auto_ptr<int>. Это не так, значит, вернутый указатель не наш, и удалять его не нам

+1. Или shared_ptr. Но обычно следует передавать ссылку если не происходит передача владения и объект всегда существует.

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

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

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

I>

__>>void f(in<int> x); // <=> void f(int x);
I>

I>А если имеем класс X определенный как

I>

I>class X {
I>    int a[1000];
I>};
I>

I>, то

I>

I>void f(in<X> x); // <=> void f(X x);
I>

I>или

I>

I>void f(in<X> x); // <=> void f(X const& x);
I>

I>?

ССылкой, зачем передавать объект по значению ?

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

__>Спасибо всем за комментарии.

__>4. Унифицированная передача аргументов.

Раз пошла такая пьянка, то как на счет типа результата функции? В COM обычно это оформляется как out<T>. Но, такой синтаксис

void GetProperty(out<int> &i);

int i;
GetProperty(i);
if(i==5) ...

мягко говоря, не очень приятный. Если out<T> это оболочка над T &, то:

out<T> GetProperty()

не подойдет. Как насчет result<T>?

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

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

__>>Спасибо всем за комментарии.

__>>4. Унифицированная передача аргументов.

_>Раз пошла такая пьянка, то как на счет типа результата функции? В COM обычно это оформляется как out<T>. Но, такой синтаксис
_>

_>void GetProperty(out<int> &i);

_>int i;
_>GetProperty(i);
_>if(i==5) ...
_>

_>мягко говоря, не очень приятный. Если out<T> это оболочка над T &, то:
_>

_>out<T> GetProperty()
_>

_>не подойдет. Как насчет result<T>?

Это тоже в планах.
Раз вы затронули эту тему то вопрос:
Насколько можно сделать перемещение эксклюзивным, т.е. без изменения самого класса ?

Идеальный вариант:

struct a
{
 void q(){}
};

ret<a> f()
{
 a x;
 x.q();
 return x;
}

int main()
{
 a y(f());
}

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

__>Насколько можно сделать перемещение эксклюзивным, т.е. без изменения самого класса ?

struct a
{
 void q(){}
};

move_t<a> f()
{
 a x;
 x.q();
 // Создание - явное, защита от самого себя :-)
 return move(x);
}

int main()
{
 // move_t использует swap, поэтому для обмена нужно сначала создать объект.
 // Если без изменения класса, то только так (я не знаю других вариантов эффективных):
 a y;
 move_ref(y) = f();

 // Или создавая сразу уже move_t<a> и используя операторы * и ->
 move_t<a> y1(f());
}

См: http://www.rsdn.ru/Forum/?mid=1585748. Последний вариант http://svn.berlios.de/viewcvs/cbear/trunk/cbear.berlios.de/base/swap.hpp?view=markup.

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

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

__>>Насколько можно сделать перемещение эксклюзивным, т.е. без изменения самого класса ?

_>

_>struct a
_>{
_> void q(){}
_>};

_>move_t<a> f()
_>{
_> a x;
_> x.q();
_> // Создание - явное, защита от самого себя :-)
_> return move(x);
_>}

_>int main()
_>{
_> // move_t использует swap, поэтому для обмена нужно сначала создать объект.
_> // Если без изменения класса, то только так (я не знаю других вариантов эффективных):
_> a y;
_> move_ref(y) = f();

_> // Или создавая сразу уже move_t<a> и используя операторы * и ->
_> move_t<a> y1(f());
_>}
_>

Тут можно пойти еще по другому пути создать тип переменной, которая перемещаемая (moveable):

ret<string> f(in<string> s)
{
 var<string> s2(s + " "); 
 return s2; // implicit ret<T>::ret(var<T>)

 // Аналогично
 // string s2(s + " ");
 // return move(s2);
}

_>См: http://www.rsdn.ru/Forum/?mid=1585748. Последний вариант http://svn.berlios.de/viewcvs/cbear/trunk/cbear.berlios.de/base/swap.hpp?view=markup.

Скажите, какая лицензия у этого кода ?

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

Тут можно пойти еще по другому пути создать тип переменной, которая перемещаемая (moveable):

move_t<string> f(in<string> s)
{
 move_t<string> s2(s + " "); 
 return s2; // implicit ret<T>::ret(var<T>)
}

Да, конечно. Одного типа move_t достаточно.

_>>См: http://www.rsdn.ru/Forum/?mid=1585748. Последний вариант http://svn.berlios.de/viewcvs/cbear/trunk/cbear.berlios.de/base/swap.hpp?view=markup.

__>Скажите, какая лицензия у этого кода ?

MIT. Близкая к BSD и Boost. Не GPL

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

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

_>Тут можно пойти еще по другому пути создать тип переменной, которая перемещаемая (moveable):
_>

_>move_t<string> f(in<string> s)
_>{
_> move_t<string> s2(s + " "); 
_> return s2; // implicit ret<T>::ret(var<T>)
_>}
_>

_>Да, конечно. Одного типа move_t достаточно.

Здесь я хотел чтобы была синтаксическая разница.
Т.е.
var — переменная
ret — возвращаемое значение

Аналогично
out vs. inout

_>>>См: http://www.rsdn.ru/Forum/?mid=1585748. Последний вариант http://svn.berlios.de/viewcvs/cbear/trunk/cbear.berlios.de/base/swap.hpp?view=markup.

__>>Скажите, какая лицензия у этого кода ?

_>MIT. Близкая к BSD и Boost. Не GPL

Я не очень силен в лицензиях.

Могу ли я этот код немного изменить для общего стиля библиотеки ?
Авторство будет сохраненно.

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

_>>MIT. Близкая к BSD и Boost. Не GPL

__>Я не очень силен в лицензиях.

__>Могу ли я этот код немного изменить для общего стиля библиотеки ?
Да, все что угодно. Главное что бы ко мне никаких претензий, если из за этого куска кода у кого то деньги со счета не пропали и т.п.

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

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

_>>>MIT. Близкая к BSD и Boost. Не GPL

__>>Я не очень силен в лицензиях.

__>>Могу ли я этот код немного изменить для общего стиля библиотеки ?
_>Да, все что угодно. Главное что бы ко мне никаких претензий, если из за этого куска кода у кого то деньги со счета не пропали и т.п.

Ок, включу в библиотеку.
Хотите я вас в разработчики добавлю ?

На данный момент будут следущие типы:

in — для входных аргументов

out — для выходных аргументов

inout — для входных и выходных аргументов

ref — для ссылки на out/inout

cref — для ссылки на in (inout ?)

ret — для возврата функций

var — для обычных переменных

Думаете стоит еще что-нибудь добавить ?

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

__>Хотите я вас в разработчики добавлю ?

На форума вашего проекта cpp-objects в Open Discussion есть встречное предложение

Отвечайте туда, что бы не засорять RSDN.

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

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

__>>Хотите я вас в разработчики добавлю ?

_>На форума вашего проекта cpp-objects в Open Discussion есть встречное предложение

Отвечайте туда, что бы не засорять RSDN.

Согласен, лучше писать в форум проекта.

	От:	_nn_
	Дата:	18.05.06 19:27
	Оценка:	+1 -5

	От:	Garrrrr
	Дата:	18.05.06 20:07
	Оценка:	+1

От:	Vain	google.ru
Дата:	18.05.06 23:33
Оценка:

	От:	gear nuke
	Дата:	19.05.06 04:27
	Оценка:

От:	sergey_shandar	http://getboost.codeplex.com/
Дата:	19.05.06 04:43
Оценка:

	От:	Константин Л.
	Дата:	19.05.06 08:47
	Оценка:

	От:	Lorenzo_LAMAS
	Дата:	19.05.06 09:55
	Оценка:	+4

От:	olexandr	http://demotivation.me/images/20140818/lxz0l278b9ep.jpg
Дата:	19.05.06 15:10
Оценка:

	От:	Pavel Chikulaev
	Дата:	19.05.06 15:34
	Оценка:

От:	remark	http://www.1024cores.net/
Дата:	19.05.06 17:59
Оценка:

	От:	Воронков Василий
	Дата:	19.05.06 23:35
	Оценка: