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

IT>

IT>MyMethod(GetCurrentEdge());
IT>

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

В догонку. Можно привести другой пример. Я не люблю итераторы и предпочитаю юзать индексы. Поэтому вместо изврата

BlaBlaBla::iterator it;
if ( obj.end() != (it = find(obj.beg(), obj.end(), item)) )
{
  // чето мутное
}

Юзаю:

int idx;
if ( obj.find(item, idx) )
{
   obj.insert(idx, something);
}

метод find обьявлен как:

bool find(T what, int &idx);

idx вполне может быть нулем, а юзать -1, всяки-разны пары и кортежи изврат.

Т.е вот пример где out параметр правильно by design.

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

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

Я предпочитаю в случае исключительных ситуаций швырять исключения или по возможности применять null-паттерн. Прикладной код становится гораздо чище.

K>

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

K>

В данном случае вообще напрашивается свойство. Сравни.

if (CurrentEdge == null)
  return; // здесь ловить больше нечего. чао бамбино
CurrentEdge.Чик(); // 
CurrentEdge.Пук(); // CurrentEdge всегда под рукой. смотрим что к чему если нужно

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

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

Тогда нафига козе баян? Или всё же лучше продолжать жрать кактус?

_>Да. Во-первых, С/С++ многоплатформенный язык, в отличие от яв и .нетов. Правильно это или неправильно — сказать нельзя.

JavaScript тоже многоплатформенный язык, только вот со строками в нём почему-то зверинца не наблюдается

_>Оба подхода востребованы на практике. Во-вторых, С/С++ — системный язык, а разные системы под строкой понимают разные вещи.

C/C++ под строкой понимает только массив символов заканчивающихся нулём.

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

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

Так по сравнениею с си С++ кораздо лучше в отношении типобезопасности.

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

_>Шаблоны это даже круче чем ты думаешь.

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

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

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

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

_>MyMethod(get_current_anything<Edge>());

будет

MyMethod(CurrentEdge);

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

Разница в 17 символов.

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

K>idx вполне может быть нулем, а юзать -1, всяки-разны пары и кортежи изврат.

По мне так нормально

K>Т.е вот пример где out параметр правильно by design.

Какой же это правильный дизайн? Если тебе нужен лишь факт, что искомый айтем найдён или нет, то всё равно придётся заводить временную переменную.

IT wrote:

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

> _>Да. Во-первых, С/С++ многоплатформенный язык, в отличие от яв и
> .нетов. Правильно это или неправильно — сказать нельзя.
> JavaScript тоже многоплатформенный язык, только вот со строками в нём
> почему-то зверинца не наблюдается
Скажите это авторам линукса. Какого хера ядро линуха на С пишется?! Давно пора на C# или JS переписать, а то чё они всё
кактусы жрут?
А почему gcc написан на С, а вот javac/jvm не на java, а на том же С?

> _>Оба подхода *востребованы на практике*. Во-вторых, С/С++ — системный
> язык, а разные системы под строкой понимают разные вещи.
> C/C++ под строкой понимает только массив символов заканчивающихся нулём.
Ну да, есть такое, "кавычками отмечается". И чем они тебе не нравятся?

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

>> JavaScript тоже многоплатформенный язык, только вот со строками в нём почему-то зверинца не наблюдается
_>Скажите это авторам линукса. Какого хера ядро линуха на С пишется?! Давно пора на C# или JS переписать, а то чё они всё кактусы жрут?

C — это личные проблемы авторов линукса.

>> C/C++ под строкой понимает только массив символов заканчивающихся нулём.
_>Ну да, есть такое, "кавычками отмечается". И чем они тебе не нравятся?

К кавычкам у меня претензий нет

IT wrote:

> Это уже похоже на оболванивание шаблонами. Всё остальное кроме них мы
> уже просто отказываемся понимать. Это как у некоторых чудо-архитекторов
> с ярковыраженной передозировкой паттернами наблюдается правило "если я
> не могу применить никакой паттерн, то я применяю паттерн визитор" , так
> и у вас с шаблонами.
А по существу? В чём проблема кода? Или использование шаблонов — смертный грех?

> _>дописываем шаблонный метод к классу:
> Следи за руками. Весь бред с шаблонами удаляем и заменяем
> многострадальный метод свойством:

> _>MyMethod(get_current_anything<Edge>());
То что я приписал "_anything" — просто был не уверен, что С++ позволяет писать одноимённые функции и шаблоны. Сейчас
проверил — позволяет, по крайней мере MSVS2003, в стандарт лезть лениво, но скорее всего можно.

> будет
> MyMethod(CurrentEdge);
Уж свойство — точно синтаксический сахар, для меня не проблема набрать "()".

> _>разница в два символа "<" и ">".
> Разница в 17 символов.
А если так написать, то ещё короче:
M(g<E>());

Давайте будем считать количество лексем, а не букв.

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

_>А по существу? В чём проблема кода? Или использование шаблонов — смертный грех?

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

>> будет
>> MyMethod(CurrentEdge);
_>Уж свойство — точно синтаксический сахар, для меня не проблема набрать "()".

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

>> _>разница в два символа "<" и ">".
>> Разница в 17 символов.
_>А если так написать, то ещё короче:
_>M(g<E>());

_>Давайте будем считать количество лексем, а не букв.

Давайте. В моём случае их 5, в твоём 10, т.е. в два раза больше.

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

ГВ>>Вопрос: какие именно строки? В турбо-паскале, вон, были строки: до 255 символов. Это такие, как надо, или не такие? А сейчас какие они должны быть? CORBA-like, Java-like, C#-like? 16- или 32-битовые символы? Что делать с тем софтом, который уже написан на C и использует const char* ?
VD>Мне тебе рассказать о принципах проектирования?

Проектирования чего? Универсального всего для любых случаев? Расскажи.

VD>>>Это такие же вопросы как "Почему не добавить свойства? Они же никому не помешали бы." или "кому помешали бы функциональные типы?". На эти вопросы есть только отбрехи фанатов С++ и комитета. Отбрехи эти пахнут маргинальностью и старперством.

ГВ>>А требования дать свойства любой ценой пахнут непониманием неоднозначности ответа на это вопрос.
VD>Про цену, плиз, по подробнее. А то ваши слова сами пахнут не очень приятно.

Ну хорошо, не "любой ценой", а со сссылкой на: "у всех же есть".

IT wrote:

> _>А по существу? В чём проблема кода? Или использование шаблонов —
> смертный грех?
> Проблема не в использовании шаблонов вообще, а в тыкании их куда надо и
> куда не надо. Именно это я пытался выразить.
Ну это тебе понадобилось "bool get(*&)" превратить в "*get()". Если это реально понадобится, это делается очень легко,
притом позволяет управлять ситуацией, если false возвращается. А вот если описать так, как предлагаешь ты, то что будешь
делать в ситуации http://rsdn.ru/forum/?mid=1939558

Автор: Kluev
Дата: 05.06.06

и "do_something_usefull< Face >()"?

>> > будет
>> > MyMethod(CurrentEdge);
> _>Уж свойство — точно синтаксический сахар, для меня не проблема набрать
> "()".
> Зачем, если этого делать не надо. К тому же я получают от использования
> свойств дополнительные бенефиты. Например, в отладчике в студии
> достаточно подвести курсор к свойству и я сразу получу тултип со
> значением свойства. Функции так не работают.
Ладно, один бенефит. Только это бенефит не языка, а среды отладки. Та же студия при отладке JavaScript позволяет и
функции вызывать, а вот с родным "__declspec(property(...))" не умеет работать. А что ещё полезного, но, желательно,
именно для языка программирования?

> Давайте. В моём случае их 5, в твоём 10, т.е. в два раза больше.
В общем, кроме экономии на спичках я тут ничего не вижу, тем более, visual assist сам пустые скобки добавлять умеет,
если у функции нет аргументов.

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

E>>или здесь,

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

Это конечно круто, ругать комитет C++ и не знать соглашений о том, что имена с двумя подчеркиваниями означают часть реализации. __init_t в данном случае -- это такой класс специальный, для реализации счетчика Шварца. Объекты этого типа пользователю даже не нужны.

E>>Т.е.
E>>

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

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

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

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

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

Ни одной заслуживающей внимания причины. В особенности пункт 4 вообще никаким боком к текущей задаче не относится. Если бы задача допускала порождение исключения вместо возвращения значения, исходная функция get_current не возвращала бы bool.

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

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

Я же сказал, что метод MyMethod на это может быть не расчитан. Если MyMethod -- это public метод, к которому непосредственно может обращаться пользователь, то проверка аргумента на null в нем обязательна. А вот если он внутренний и снаружи не виден, да еще вызвается очень часто, то такие проверки внутри MyMethod могут оказаться избыточными.

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

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

K>>idx вполне может быть нулем, а юзать -1, всяки-разны пары и кортежи изврат.

IT>По мне так нормально

K>>Т.е вот пример где out параметр правильно by design.

IT>Какой же это правильный дизайн? Если тебе нужен лишь факт, что искомый айтем найдён или нет, то всё равно придётся заводить временную переменную.

А вот и нет Мы unused юзаем.

struct Unused
{
  template <class T> operator T ()
  {
     static T dummy;
     return dummy;
  }
};

extern Unused unused;

//=================================
void test()
{
   if ( obj.find(foo, unused) )
   {
   } 
}

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

IT>В данном случае вообще напрашивается свойство. Сравни.

IT>

IT>if (CurrentEdge == null)
IT>  return; // здесь ловить больше нечего. чао бамбино
IT>CurrentEdge.Чик(); // 
IT>CurrentEdge.Пук(); // CurrentEdge всегда под рукой. смотрим что к чему если нужно
IT>

Согласен. На строчку кода меньше.

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

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

_>>Шаблоны это даже круче чем ты думаешь.

IT>Это уже похоже на оболванивание шаблонами. Всё остальное кроме них мы уже просто отказываемся понимать. Это как у некоторых чудо-архитекторов с ярковыраженной передозировкой паттернами наблюдается правило "если я не могу применить никакой паттерн, то я применяю паттерн визитор" , так и у вас с шаблонами.

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

IT>Следи за руками. Весь бред с шаблонами удаляем и заменяем многострадальный метод свойством:

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

IT>

_>>MyMethod(get_current_anything<Edge>());
IT>

IT>будет

IT>

IT>MyMethod(CurrentEdge);
IT>

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

IT>Разница в 17 символов.

Ну, имхо, придиратся не стоит.
можно ведь и просто current<Edge>() К томуже если я не ошибаюсь глобальных функций в шарпе нет и потребуется некий класс. т.е.
будет еще синтаксический оверхед (tm) в виде
Globals.CurrentEdge. А если это все по библиотекам раскидано, то тогда еще и прийдется более явно указывать:
Core.Globals.CurrentEdge, etc

Kluev wrote:

> можно ведь и просто current<Edge>() К томуже если я не ошибаюсь
> глобальных функций в шарпе нет и потребуется некий класс. т.е.
> будет еще синтаксический оверхед (tm) в виде
> Globals.CurrentEdge. А если это все по библиотекам раскидано, то тогда
> еще и прийдется более явно указывать:
> Core.Globals.CurrentEdge, etc
Тормозишь, причём тут глобальные переменные? Он говорит, мол, круто, если CurrentEdge будет пропертей. Можно так:

var foo = new Foo();
MyMethod(foo.current<Edge>());
MyMethod(foo.currentEdge);

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

K>А вот и нет Мы unused юзаем.
K>

K>struct Unused
K>{
K>  template <class T> operator T ()
K>  {
K>     static T dummy;
K>     return dummy;
K>  }
K>};

K>extern Unused unused;

K>//=================================
K>void test()
K>{
K>   if ( obj.find(foo, unused) )
K>   {
K>   } 
K>}
K>

Во-первых этот код вобще должен не компилироваться ибо должно быть operator T& ().
Во-вторых даже если его исправить то с многопоточностью у нас будут проблемы в случае если T что-то болие сложное чем Some* или int.
Итого: имеем грабли которые могут привести к рассогласованию внутреннего состояния объекта что может привести к порче памяти и/или утечке памяти в зависимости от фазы луны. Те поймать такую ошибку практически не реально.
Вывод: unsafe вобще и С++ в частности тебе противопоказан.

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

_>А вот если описать так, как предлагаешь ты, то что будешь делать в ситуации http://rsdn.ru/forum/?mid=1939558

Автор: Kluev
Дата: 05.06.06

и "do_something_usefull< Face >()"?

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

_>Ладно, один бенефит. Только это бенефит не языка, а среды отладки. Та же студия при отладке JavaScript позволяет и функции вызывать,

Методы тоже можно вызывать, но не наведением мышкой.

_>а вот с родным "__declspec(property(...))" не умеет работать.

Видимо забили.

_>А что ещё полезного, но, желательно, именно для языка программирования?

Свойства — это удобно. Например, удобно делать отложенную загрузку. Со свойствами хорошо работает баиндинг и куча визуальных компонент. Редактор контролов в студии, например, позволяет редактировать свойства контролов прямо в дизайн тайм. Абстолютно тот же самый редактор можно использовать и в рантайм. Например, на нём сделан редактор настроек в Янусе. Вообще, компонентное программирование слабо мыслимо без свойств. Например, в джаве для этого изобрели специальное соглашение — методы, начинающиеся с get(без параметров)/set(с одним параметром) считаются свойствами и также доступны всяким компонентным приблудам.

>> Давайте. В моём случае их 5, в твоём 10, т.е. в два раза больше.
_>В общем, кроме экономии на спичках я тут ничего не вижу, тем более, visual assist сам пустые скобки добавлять умеет, если у функции нет аргументов.

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

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

E>Это конечно круто, ругать комитет C++ и не знать соглашений о том, что имена с двумя подчеркиваниями означают часть реализации. __init_t в данном случае -- это такой класс специальный, для реализации счетчика Шварца. Объекты этого типа пользователю даже не нужны.

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

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

E>Ни одной заслуживающей внимания причины.



E>В особенности пункт 4 вообще никаким боком к текущей задаче не относится. Если бы задача допускала порождение исключения вместо возвращения значения, исходная функция get_current не возвращала бы bool.

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

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

bool int.TryParse(string s, out int n)

Здесь хотя бы понятно, что вызов Try не предполагает слишком подробной информации об ошибке и bool вполне оправдан. Но в твоём случае — это по любому кривой дизайн. Либо надо проверять на null возвращаемое значение, что вполне логично, либо кидать исключение.

Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.