Re: Tcl как обоснование ненужности поддержки компонентности в С++ - Философия программирования

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

C>IT wrote:
>> C>#import — это решение аля-MS. Правильное С++ное решение — это Comet,
>> он тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.
>> Без исключений он тоже обходится?
C>Наоборот, превращает HRы в исключения и автоматически добавляет поддержку ISupportsErrorInfo к серверным классам.

А почему же тогда отказались от свойств? Не потому ли, что их не поддерживает стандарт?

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

ГВ>Да? А где он такое говорит?

Везде. У него основные слова о типобезопасности и быстродействии.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

_>А какие проблемы?

Так переопределяешь или нет? Со строками в C++ всё просто. Из-за отсутствия стандартной строки каждая уважающая себя библиотека имеет свою реализацию строки. Но я не замечал, что каждая уважающая себя библиотека имеет свою реализацию double, int, long. Не потому ли, что возможность раализовать и необходимость в этом — это очень разные вещи. Но вот что касается строк в плюсах, то возможность раелизации своих строк становится необходимостью из-за отсутствия нормальной стандартной строки.

VladD2 wrote:
> C>Далеко не все.
> Почти все! Для реализации любой логики достаточно одного оператора
> сравнения и goto.
Есть свойства языка, которые можно выразить через другие свойства — это
сахар. Операции циклов — сахар над if/goto, а вот switch — уже нет, так
как это абстракция таблицы переходов.

Точно так же — в C++ не являются сахаром шаблоны, исключения,
автоматические классы, и т.п.

Сахар — это перегрузка операторов, implicit-преобразования и т.п.

> C>На Лиспе как раз сахаром при желании можно обожраться по полной.
> В Лиспе его вообще практически нет. Другое дело, что там есть макросы с
> помощью которых он делается. Вот это путь и видится мне перспективным.
В связи с (повторным) увлечением Emacs'ом, мне стало интересно как же
используются макросы в Emacs'е. Оказалось, что почти никак.

Я честно говоря, не могу представить где мне нужны будут нетривиальные
метапрограммы. Простенькие типа "кастануть к типу из списка с номером N"
— неплохо, но чего-то большего не особо хочется.

> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
> C>класса я могу взять ссылку (в С++).
> Понимшь, С++ с его догами идет в лес.
Изначально IT привел отсутствие свойств как пример отстоев С++.

Posted via RSDN NNTP Server 2.0

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

K>или я должен сделать функцию которая возвращает Object* а дальше dynamic_cast-om развлекатся? Или целое семейство наплодить get_curr_face, get_curr_edge, ...

Вот видишь, ты же сам всё знаешь. Это как раз будет более правильным решением

Можно ещё шаблоны/дженерики зарядить, если получится.

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

C>Изначально IT привел отсутствие свойств как пример отстоев С++.

Не надо путать. Я это привёл как пример отстоя работы комитетчиков. Чтобы больше у нас в этом не было никаких домыслов, предлагаю в дальнйшем все мои притензии к языку относить исключительно на счёт комитета, т.к. сегодняшнее плачевное состояния языка — это их прямая заслуга.

IT wrote:

> Так переопределяешь или нет? Со строками в C++ всё просто. Из-за
> отсутствия стандартной строки каждая уважающая себя библиотека имеет
> свою реализацию строки. Но я не замечал, что каждая уважающая себя
> библиотека имеет свою реализацию double, int, long. Не потому ли, что
> возможность раализовать и необходимость в этом — это очень разные вещи.
> Но вот что касается строк в плюсах, то возможность раелизации своих
> строк становится необходимостью из-за отсутствия нормальной стандартной
> строки.
Посмотри что такое DWORD, BYTE, UINT, или ещё всякие Int32, UInt32. А так же интересно поглядеть на это (gcj):

class ::com::lowagie::text::DocWriter : public ::java::lang::Object
{
...
   virtual jboolean setMargins (jfloat, jfloat, jfloat, jfloat);
...
   static const jint NEWLINE = 10;
   static const jint TAB = 9;
}

Оно, конечно, обычно не реализуется через class, обычно через #define либо typedef, но всё-таки многие библиотеки имеют
фактически все типы собственной реализации.

Ты вообще понимаешь принципиальную (теоретическую) разницу между типом int (и ему подобными) и string?

Posted via RSDN NNTP Server 2.0

VladD2 wrote:

> C>Свойства — это не более чем простенький синтаксический сахар.
> Да, тысячу раз да! Почти все конструкции современных ЯП — это
> синтаксический сахар. Иначе нельзя было бы писать на Лисп-е или
> ассемблере. Всем кто хочет и дальше жрать кактус даже не закусывая
> сахаром мой большой привет. Только не нащдо пропагандировать нищету и
> убожество. ОК?
Лично я не вижу большой семантической (только синтаксис разный) разницы между:

class Obj
{
   property value = {getValue, setValue}; //или как-то так, не важно как.
   int getValue(){return callCOMMethod();}
   void setValue(int v){callCOMMethod(v);}
};
obj.value = obj2.value;
// и
class Obj
{
   int getValue(){return callCOMMethod();}
   void setValue(int v){callCOMMethod(v);}
};
obj.setValue(obj2.getValue());
// или иногда пишут даже
class Obj
{
   int value(){return callCOMMethod();}
   void value(int v){callCOMMethod(v);}
};
obj.value(obj2.value());

просветите, в чём принципиальная разница??

Зато здесь, например:

std::auto_ptr<Obj> obj(new Obj);
obj->method();
return obj->method2();
// и
Obj *obj = new Obj;
obj->method();
Result r = obj->method2();
delete obj;
return r;

есть разница семантическая, разница не только в синтаксисе, но и в смысле кода, так что сахар далеко не всё.

Posted via RSDN NNTP Server 2.0

IT wrote:
>> > Без исключений он тоже обходится?
> C>Наоборот, превращает HRы в исключения и автоматически добавляет
> поддержку ISupportsErrorInfo к серверным классам.
> А почему же тогда отказались от свойств? Не потому ли, что их не
> поддерживает стандарт?
Они там есть:

#ifdef COMET_ALLOW_DECLSPEC_PROPERTY
     __declspec(property(get=GetChildren))
     com_ptr<WidgetOGLLib::I3DObjectCollection> Children;
#endif

Хотя зачем они нужны, если есть Get/Put-методы — мне непонятно.

Posted via RSDN NNTP Server 2.0

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

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

K>>или я должен сделать функцию которая возвращает Object* а дальше dynamic_cast-om развлекатся? Или целое семейство наплодить get_curr_face, get_curr_edge, ...

IT>Вот видишь, ты же сам всё знаешь. Это как раз будет более правильным решением

Можно ещё шаблоны/дженерики зарядить, если получится.

Не не будет. eao197 насчет шаблонов верно написал. Такой код с шаблонами не подружишь. Перегруженные функции лучше полюбому.

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

FR>>Мне приходилось подменять double своим специализированным классом.

IT>В каждом новом приложении? И long наверное приходилось подменять, и short, и int? И так в каждом новом проекте?

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

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

_>Посмотри что такое DWORD, BYTE, UINT, или ещё всякие Int32, UInt32.

Да, да, да. Как же, как же, про макросы я совсем забыл

_>Оно, конечно, обычно не реализуется через class, обычно через #define либо typedef, но всё-таки многие библиотеки имеют фактически все типы собственной реализации.

А теперь представим, что ты пишешь метод в своём коде, который принимает int, и должен его передать методу A из библиотеки аа, в кторой используется INT32, и также методу B из библиотеки bb, в которой int объявлен как Int32. Какой тип ты будешь использовать в своём методе?

_>Ты вообще понимаешь принципиальную (теоретическую) разницу между типом int (и ему подобными) и string?

А ты вообще понимаешь принципиальную (практическиу) разницу между наличием одного стандартного типа string и зверинца из std::string, LPCTSTR, CString, BSTR, _bstr_t и пр.?

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

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

FR>>Нет не задвинул. У меня VC (с правильными ключиками) быстрее.

VD>Ключи в студию.

Не помню, помню только прагму: #pragma inline_recursion(on)

VD>ЗЫ

VD>Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?

Ну у gcc тоже много ключиков, надо поискать которые за инлайнинг отвечают.

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

FR>>Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот
FR>>N уступает C++, так что слово слили здесь неуместно.

VD>Это банальная подтасовка результатов. При этом VC вычислит промежуточные результаты во время компиляции. Эдак Немерел всегда будет победителем, так как любое статическое вычисление на нем можно частично или полностью предвычислить.

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

#include <iostream>
#include <sstream>

#pragma inline_recursion(on)

inline int akk( int a, int b )
    {
        if( 0 == a )
            return b + 1;
        else if( 0 == b )
            return akk( a - 1, 1 );
        else
            return akk( a - 1, akk( a, b - 1 ) );
    }

int main(int argc, char *argv[])
    {
         int n = 0, m = 0;
         if(argc > 0)
          {
          std::istringstream in(argv[1]);
          in >> n;
          m = n + 9;
          std::cout << n << " " << m << std::endl;
          std::cout << akk( n, m) << std::endl;
          }

    }

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

IT>>Вот видишь, ты же сам всё знаешь. Это как раз будет более правильным решением

Можно ещё шаблоны/дженерики зарядить, если получится.

K>Не не будет. eao197 насчет шаблонов верно написал. Такой код с шаблонами не подружишь. Перегруженные функции лучше полюбому.

Это заблуждение. eao197 вообще приверженец птичьей нотации. Для него идеальным вариантом было бы даже не get_curr_face, get_curr_edge, а g_c_f, g_c_e

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

К тому же шаблоны — это конечно круто, но перегрузка не дасть тебе возможности написать, например, такой код.

MyMethod(GetCurrentEdge());

придётся тебе вместо одной строчки писать минимум три.

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

K>>Не не будет. eao197 насчет шаблонов верно написал. Такой код с шаблонами не подружишь. Перегруженные функции лучше полюбому.

IT>Это заблуждение. eao197 вообще приверженец птичьей нотации. Для него идеальным вариантом было бы даже не get_curr_face, get_curr_edge, а g_c_f, g_c_e

Пора в суд подавать, за клевету. Попробуй найти такие названия в моем коде. Например, здесь или здесь, или даже в Ruby коде

IT>Но это всё весело до тех пор пока мы пишем код, не думаю о последствиях. А последствия таковы, что код во много раз чаще читается чем пишется. И подобные неоднозначности при чтении приводят к плохой читаемости кода.

Т.е.

Face * f;
if( get_current( f ) ) { ... }

менее читабельно, чем это?

Face * f = get_current_face();
if( f ) { ... }

Если да, то почему?

IT>К тому же шаблоны — это конечно круто, но перегрузка не дасть тебе возможности написать, например, такой код.

IT>

IT>MyMethod(GetCurrentEdge());
IT>

IT>придётся тебе вместо одной строчки писать минимум три.

Зато в таком подходе MyMethod должен ожидать получение нулевого указателя. Если же он на это не расчитан, то по количеству строчек оба подхода не будут сильно различаться.

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

E>Пора в суд подавать, за клевету. Попробуй найти такие названия в моем коде. Например, здесь

Жмотный народ.ру очень медленно в буржуинии открывается. Экономят ребята на международном трафике.

E>или здесь,

В первой же строчке: so_4::rt::__init_t. Из всего этого чириканья я понял только что такое init. Да и его мне предлагается запомнить с двумя подчёркиваниями, что может оказаться уже выше моих сил.

IT>>Но это всё весело до тех пор пока мы пишем код, не думаю о последствиях. А последствия таковы, что код во много раз чаще читается чем пишется. И подобные неоднозначности при чтении приводят к плохой читаемости кода.

E>Т.е.
E>

E>Face * f;
E>if( get_current( f ) ) { ... }
E>

E>менее читабельно, чем это?
E>

E>Face * f = get_current_face();
E>if( f ) { ... }
E>

E>Если да, то почему?

Как минимум есть четыре причины.
1. Вполне возможно, что мне не надо будет создавать промежуточную переменную.
2. Проверка была сделана выше и повторно её делать не имеем смысла.
3. Уровень доверия в моём коде может быть выше необходимости проверять возвращаемое значение.
4. Вместо возврата null вызываемая функция может генерировать исключение.

IT>>К тому же шаблоны — это конечно круто, но перегрузка не дасть тебе возможности написать, например, такой код.

E>Зато в таком подходе MyMethod должен ожидать получение нулевого указателя. Если же он на это не расчитан, то по количеству строчек оба подхода не будут сильно различаться.

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

IT wrote:

> _>Оно, конечно, обычно не реализуется через class, обычно через #define
> либо typedef, но всё-таки многие библиотеки имеют фактически все типы
> собственной реализации.
> А теперь представим, что ты пишешь метод в своём коде, который принимает
> int, и должен его передать методу A из библиотеки аа, в кторой
> используется INT32, и также методу B из библиотеки bb, в которой int
> объявлен как Int32. Какой тип ты будешь использовать в своём методе?
Без разницы, компилятор приведёт автоматически INT32 к Int32 и наоборот, особенно если они определены через typedef или
#define. А если что-то не так — будет warning.

> _>Ты вообще понимаешь принципиальную (теоретическую) разницу между типом
> int (и ему подобными) и string?
> А ты вообще понимаешь принципиальную (практическиу) разницу между
> наличием одного стандартного типа string и зверинца из std::string,
> LPCTSTR, CString, BSTR, _bstr_t и пр.?
Да. Во-первых, С/С++ многоплатформенный язык, в отличие от яв и .нетов. Правильно это или неправильно — сказать нельзя.
Оба подхода востребованы на практике. Во-вторых, С/С++ — системный язык, а разные системы под строкой понимают
разные вещи.

Posted via RSDN NNTP Server 2.0

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

IT>К тому же шаблоны — это конечно круто, но перегрузка не дасть тебе возможности написать, например, такой код.

IT>

IT>MyMethod(GetCurrentEdge());
IT>

IT>придётся тебе вместо одной строчки писать минимум три.

Нет. Я всегда предпочитаю заводить локальную переменную. Отлаживатся гораздо проще.

Foo *f;
if (!get_curr(f))
  return; // здесь ловить больше нечего. чао бамбино
f->чик(); // 
f->пук(); // f всегда под рукой. смотрим что к чему если нужно

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

IT wrote:

> К тому же шаблоны — это конечно круто, но перегрузка не дасть тебе
> возможности написать, например, такой код.
Шаблоны это даже круче чем ты думаешь.

дописываем шаблонный метод к классу:

bool get_current(Face *&);
bool get_current(CFace *&);
bool get_current(Edge *&);
...
template<class T> T *get_current_anything()
{
   T *obj;
   if(get_current(obj)) return obj;
   else throw something();// или "return NULL;" или, скажем, "return get_default(obj)".
}

и тогда вместо:

> MyMethod(GetCurrentEdge());

будет

MyMethod(get_current_anything<Edge>());

разница в два символа "<" и ">".

Posted via RSDN NNTP Server 2.0

От:	IT	linq2db.com
Дата:	05.06.06 15:13
Оценка:

От:	VladD2	www.nemerle.org
Дата:	05.06.06 15:14
Оценка:

От:	IT	linq2db.com
Дата:	05.06.06 15:17
Оценка:

	От:	Cyberax
	Дата:	05.06.06 15:18
	Оценка:	-1

От:	IT	linq2db.com
Дата:	05.06.06 15:20
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	05.06.06 17:20
Оценка: