Re: 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);

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

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

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

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? Размер в байтах? Размер в элементах? Вообще мне кажется, что постулат "чтобы работало для всего" неверен. Лучше получить от компилятора по рукам на непредвиденную ситуацию, чем работать с отладчиком

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

	От:	_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
Оценка: