LINUX.ORG.RU

Шаблонное программирование в C++ и хвостовая рекурсия


0

3

Есть ли смысл при программировании на шаблонах применять хвостовую рекурсию?

Например, что лучше:

template <int n>
struct Fac
{
    enum { result = n * Fac<n - 1>::result };
};

template <>
struct Fac<0>
{
    enum { result = 1 };
};

или

template <int n>
class TailFac
{
    template <int counter, int mul>
    struct TailFacIter
    {  
        enum { value = TailFacIter<counter - 1, mul * counter>::value };
    };

    template <int mul>
    struct TailFacIter<0, mul>
    {  
        enum { value = mul };
    };

public:
    enum { result = TailFacIter<n - 1, n>::value };
};

Даст ли второй подход меньшее потребление памяти и большую скорость компиляции?

Ответ на: комментарий от anonymous

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

уточните о каком проектировании Вы сейчас говорите

shty ★★★★★
()
Ответ на: комментарий от shty

пруф получится в данном случае, если Вы приведёте для каждого отмеченного случая страницы, где находятся данные высказывания

Сказали же тебе, смотри в индекс.

Мультиметоды - один из интересных вопросов вроде что, если... в С++. Мог бы я в то время спроектировать и реализовать их достаточно хорошо? Было бы их при.менение настолько важ1гы.м, чтобы оправдать потраченные усилия? Какую работу пришлось бы оставить незавершенной, чтобы хватило времени на проектирование и реализацию мультиметодов? Примерно с 1985 г. я сожалею, что не включил это средство в язык. Единственный раз я официально упо.мянул о муль-тиметодах иа конференции OOPSLA, когда выступил против языковой нетерпи-.мости и бессмысленности ожесточенных баталий по поводу языков [Stroustrup, 1990]. Я привел в качестве при.мера некоторые концепции из языка CLOS, которые мне чрезвычайно нравились, и особо выделил мультиметоды.

Стр. 305.

# анонимус из зала с попкорном

anonymous
()
Ответ на: комментарий от shty

> отнюдь не претендую, Вы мне эту роль своими ответами навязываете

ну и чтобы Вы были в курсе про ментора

Цитата: Имя Ментор часто употребляется как нарицательное, в смысле наставника или руководителя юношества.

далее

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

Что вы этим хотели донести абсолютно не понятно.

anonymous
()
Ответ на: комментарий от shty

> паттерн проектирования Singleton декларирует следующее (по материалам книги GoF): гарантируется что у класса существует только один экземпляр с глобально точкой доступа; язык реализации здесь никак не упоминается, равно как не даётся никаких указаний по построению реализации такого решения; именно поэтому я Вас попросил указать язык; так ясно, или ещё подробнее?

Уделите больше внимания вводной части GoF, разъясняющей важные моменты: «Выбор языка программирования безусловно важен... Некоторые из наших паттернов напрямую поддерживаются менее распространенными языками.»

anonymous
()
Ответ на: комментарий от anonymous

Спасибо, уважаемый анонимус за то, что ты есть, и за то, что ты такой, какой ты есть. Обязательно еще пиши. Надеюсь всяких shty когда-нибудь за идиотизм заблокируют.

-- yet another anonymous

anonymous
()
Ответ на: комментарий от anonymous

Уделите больше внимания вводной части GoF, разъясняющей важные моменты: «Выбор языка программирования безусловно важен... Некоторые из наших паттернов напрямую поддерживаются менее распространенными языками.»

хм, возможно Вы включились не сразу, позвольте я напомню контекст, отстаиваемый «отважными»:

Никаких best practices & мудрости сенсеев в дописывании разработчиками ручками стандартных библиотек/окружения/рантайма *НЕТ*.

Это всего лишь означает, что язык, библиотек и окружение были криво спроектированны.

теперь поясните каким образом процитированная Вами фраза подтверждает этот постулат? что Вы вообще думаете о нём?

//я уделил, поверьте, достаточно внимания и введению, и самой книге, и её применению на практике

shty ★★★★★
()
Ответ на: комментарий от anonymous

Уделите больше внимания вводной части GoF, разъясняющей важные моменты: «Выбор языка программирования безусловно важен... Некоторые из наших паттернов напрямую поддерживаются менее распространенными языками.»

да, означает ли Ваша фраза что Вы согласны вот с этой трактовкой, связывающей появление паттернов проектирования и, внезапно, «возможности языка»:

> хме, а откуда паттерн singleton взялся по-вашему?

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

shty ★★★★★
()
Ответ на: комментарий от anonymous

> отнюдь не претендую, Вы мне эту роль своими ответами навязываете

ну и чтобы Вы были в курсе про ментора

Что вы этим хотели донести абсолютно не понятно.

что Вы школота, и непоняв весьма нетонкую аллюзию Вы этот тезис подтвердили

shty ★★★★★
()
Ответ на: комментарий от anonymous

Мультиметоды - один из интересных вопросов вроде что, если... в С++. Мог бы я в то время спроектировать и реализовать их достаточно хорошо? Было бы их при.менение настолько важ1гы.м, чтобы оправдать потраченные усилия? Какую работу пришлось бы оставить незавершенной, чтобы хватило времени на проектирование и реализацию мультиметодов? Примерно с 1985 г. я сожалею, что не включил это средство в язык. Единственный раз я официально упо.мянул о муль-тиметодах иа конференции OOPSLA, когда выступил против языковой нетерпи-.мости и бессмысленности ожесточенных баталий по поводу языков [Stroustrup, 1990]. Я привел в качестве при.мера некоторые концепции из языка CLOS, которые мне чрезвычайно нравились, и особо выделил мультиметоды.

спасибо тебе трудолюбивый анонимус

итак, поехали, тезис звучал дословно так:

>Страуструп никогда не скрывал своего восхищения CLOS'ом (1) и в частности мультиметодами (2), при этом он очень жалеет что не реализовал их в C++ (3) по причине неуверенности в своих возможностях. (4)

пруфы, плиз, для (1), (2), (3) и (4)

1) не вижу никакого восхищения CLOS, высказанного Страуструпом, вижу что ему импонируют определенные концепции , не более того
2) есть такое
3) есть такое
4) фейл, Страуструп сомневается в важности мультиметодов, сетует на недостаток ресурсов, и выражает озабоченность по поводу того насколько качественно он смог бы спроектировать/реализовать мультиметоды, итого, если говорить об обоснования приведённых Страуструпом по данному пункту, то лишь 30%, с натяжкой, могут относится собственно к неуверенности; по факту же банальное сомнение - настолько оно нужно чтобы тратить на него ресурсы или нет?

итого - 50% вранья, как люблю я пруфы :)

shty ★★★★★
()
Ответ на: комментарий от shty

> Страуструп сомневается в важности мультиметодов

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

archimag ★★★
()
Ответ на: комментарий от anonymous

> Надеюсь всяких shty когда-нибудь за идиотизм заблокируют.

Идиотов и тролей здесь любят.

anonymous
()
Ответ на: комментарий от archimag

Не передёргивайте. Сомневаться важности мультиметодов просто невозможно. Страуструп то наверняка понимал насколько это крутая фича.

прошу прощения, не совсем корректно выразился, уточню прямой цитатой:

Было бы их применение настолько важным, чтобы оправдать потраченные усилия?

всё же это сомнение в профитах отнесённое к ресурсам

shty ★★★★★
()
Ответ на: комментарий от shty

> //я уделил, поверьте, достаточно внимания и введению, и самой книге, и её применению на практике

Не верю, докажи.

теперь поясните каким образом процитированная Вами фраза подтверждает этот постулат? что Вы вообще думаете о нём?

Х%й в замочную скважину не засунешь, потому что он не подходит. Твои паттерны в другие языки так же не засунешь, потому что они не подходят. «Проектирование» с использованиям таких паттернов выльется в эпик фейл.

Так ясно?

anonymous
()
Ответ на: комментарий от anonymous

> //я уделил, поверьте, достаточно внимания и введению, и самой книге, и её применению на практике

Не верю, докажи.

как Вы себе представляете процесс такого доказательства?

Х%й в замочную скважину не засунешь, потому что он не подходит.

а Вы пытливый :)

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

давайте не торопиться, про какие «другие языки» идёт речь? перечислите пожалуйста

shty ★★★★★
()
Ответ на: комментарий от shty

> как Вы себе представляете процесс такого доказательства?

Ты начинаешь доказывать, доказываешь, заканчиваешь доказывать. Что-нибудь непонятно?

давайте не торопиться, про какие «другие языки» идёт речь? перечислите пожалуйста

Н-да, лучше перечисли те языки, с которыми ты знаком.

anonymous
()
Ответ на: комментарий от shty

> всё же это сомнение в профитах отнесённое к ресурсам

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

«Было бы их применение настолько важным, чтобы оправдать потраченные усилия? ...Примерно с 1985 г. я СОЖАЛЕЮ, что не включил это средство в язык.»

anonymous
()
Ответ на: комментарий от anonymous

> давайте не торопиться, про какие «другие языки» идёт речь? перечислите пожалуйста

Н-да, лучше перечисли те языки, с которыми ты знаком.

ты глупый щитоле? ещё раз: к каким по твоему мнению языкам не применимы шаблоны проектирования ответить внятно сможешь? не надо все перечислять, 1-2 достаточно

shty ★★★★★
()
Ответ на: комментарий от anonymous

> всё же это сомнение в профитах отнесённое к ресурсам

«Было бы их применение настолько важным, чтобы оправдать потраченные усилия? ...Примерно с 1985 г. я СОЖАЛЕЮ, что не включил это средство в язык.»

и что поменялось?

shty ★★★★★
()
Ответ на: комментарий от ky-san

Так, к слову, паттерн «одиночка» неприменим в языках без [..] ООП/объектов.

согласитесь, что несколько странно применять приёмы объектно-ориентированного проектирования к языкам которые ООП не поддерживают

shty ★★★★★
()
Ответ на: комментарий от shty

Замени слово «приёмы» на паттерны.

ООП можно использовать в любом полном по Тьюрингу языке. Дело в удобстве. Если не удобно, но по-другому никак - будут делатся библиотеки с реализованными костылями (или книги их описанием, если у подавляющего большинства синдром NIH не позвляет использовать boost^W другие реализации).

ky-san
()
Ответ на: комментарий от shty

> согласитесь, что несколько странно применять приёмы объектно-ориентированного проектирования к языкам которые ООП не поддерживают

А вот это уже полный провал - приемы объектно-ориентированного проектирования можно реализовывать, например, на Си и даже на ассемблере. На практике это используется сплошь и рядом. И даже GoF, которому вы якобы уделили достаточно внимания, ничего не говорит об обязательном требовании ООП-языка.

anonymous
()
Ответ на: комментарий от shty

> к каким по твоему мнению языкам не применимы шаблоны проектирования ответить внятно сможешь? не надо все перечислять, 1-2 достаточно

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

anonymous
()
Ответ на: комментарий от shty

Было бы их применение настолько важным, чтобы оправдать потраченные усилия?

всё же это сомнение в профитах отнесённое к ресурсам

Ну это уже чересчур толсто. Вот самое начало цитаты:

Мог бы я в то время спроектировать и реализовать их достаточно хорошо?

Пожалуйста, явно высказанная неуверенность в своих силах.

anonymous
()
Ответ на: комментарий от ky-san

Замени слово «приёмы» на паттерны.

:) книга GoF называется: «Приёмы объектно-ориентированного проектирования. Паттерны проектирования.»

ООП можно использовать в любом полном по Тьюрингу языке.

это излишне опимистичное утверждение имхо, но пусть будет так

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

Дело в удобстве.

конечно в нём, поэтому я написал не «нельзя», а «несколько странно»

Если не удобно, но по-другому никак

довольно редко так бывает на практике, чтобы «по другому никак», скорее часто бывает так, что какой-нибудь упоротый ССЗБ держится мёртвой хваткой за свой, к примеру, честно украденный в прошлом веке билдер, а между тем его задача на Erlang решается в 10 строчек и за 10 минут

shty ★★★★★
()
Ответ на: комментарий от anonymous

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

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

GoF, которому вы якобы уделили достаточно внимания, ничего не говорит об обязательном требовании ООП-языка.

прочитайте обложку, вдумчиво, и потом подумайте причём тут язык :)

shty ★★★★★
()
Ответ на: комментарий от anonymous

> и что поменялось?

У вас проблемы с восприятием связанного текста?

это удобно, обвинять оппонента в своих проблемах

shty ★★★★★
()
Ответ на: комментарий от anonymous

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

согласен, теперь давайте подумаем, что же такое шаблоны проектирования? неужели и взаправду наличие шаблонов проектирования "[..] всего лишь означает, что язык, библиотек и окружение были криво спроектированны." или что "паттерны проектирования это недостатки тех или иных языков программирования"

shty ★★★★★
()
Ответ на: комментарий от shty

> :) книга GoF называется: «Приёмы объектно-ориентированного проектирования. Паттерны проектирования.»

Не знаю, как у вас, у нас книга называется «Design Patterns: Elements of Reusable Object-Oriented Software»

Вольный-трольный перевод описания книги: «Книга разделенна на две части. Первая часть описывает недостатки ООП, вторая часть описывает 23 классических костыля, применямых для разработки ПО. В качестве примеров языков, где всё реализованно и ничего дописывать не нужно используется Smalltalk, а для языка, где ничего нет и всё нужно делать самому - С++» (С) wikipedia

ky-san
()
Ответ на: комментарий от shty

> давайте подумаем, что же такое шаблоны проектирования?

Давай. Давай посмотрим на уже надоевший singleton.

Итак, мы пришли в к выводу:

1) В некоторых языках он не нужен, потому что там нет объектов и присваивания

2) В некоторых языках он не нужен, потому что его нельзя применить, так как используемая модель ООП делает его ненужным в принципе.

3) В некоторых языках (С++) - без них сложно обойтись.

Посмотрим на пп.1-3. Сравнивая п.3 с п.1 и п.2 на примере конкретного паттерна вполне можно сделать вывод, что в данном случае этот паттерн - костыль для С++, служащий для приведения используемой модели ООП в юзабальный вид.

ky-san
()
Ответ на: комментарий от shty

> прочитайте обложку, вдумчиво, и потом подумайте причём тут язык :)

Обложка есть на википедии: http://en.wikipedia.org/wiki/File:Design_Patterns_cover.jpg. Мелковато, но читается: «Design Patterns. Elements of Reusable Object-Oriented Software», там конечно есть еще имена авторов, название издательства.

shty, а теперь будьте добры объяснить причем тут язык?

anonymous
()
Ответ на: комментарий от ky-san

Не знаю, как у вас, у нас книга называется «Design Patterns: Elements of Reusable Object-Oriented Software»

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

Вольный-трольный перевод описания книги: «Книга разделенна на две части. Первая часть описывает недостатки ООП, вторая часть описывает 23 классических костыля, применямых для разработки ПО. В качестве примеров языков, где всё реализованно и ничего дописывать не нужно используется Smalltalk, а для языка, где ничего нет и всё нужно делать самому - С++» (С) wikipedia

не, это весело конечно :) но став постарше, пережив пару-тройку серьёзных проектов, поучавствовав в каком-нибудь какмикадзе-проекте - набравшись опыта вобщем, люди, как правило, становятся весьма прагматичными

и ни разу с более или менее опытной командой у меня не было столкновения по методам проектирования

shty ★★★★★
()
Ответ на: комментарий от shty

> перечитайте моё сообщение где я разобрал все 4 пункта, внимательно

Там особо читать нечего: с 1-ым пунктом в рамках приведенной цитаты можно согласиться, по 2-ому и 3-ему согласие с вашей стороны, по 4-ому толстый неумелый тролинг. Итог: никакого разбора всех 4 пунктов нет.

anonymous
()
Ответ на: комментарий от shty

Это все ничем не подтвержденное бла-бла-бла.

anonymous
()
Ответ на: комментарий от shty

> это удобно, обвинять оппонента в своих проблемах

Ну вот, опять видим как человек уходит от ответа.

anonymous
()
Ответ на: комментарий от shty

> не, это весело конечно :) но став постарше, пережив пару-тройку серьёзных проектов, поучавствовав в каком-нибудь какмикадзе-проекте - набравшись опыта вобщем, люди, как правило, становятся весьма прагматичными

Да, становятся более прагматичными, перестают верить в серебрянные пули и полезность паттернов для макак и С++ вообще.

ky-san
()
Ответ на: комментарий от ky-san

Давай. Давай посмотрим на уже надоевший singleton.

Итак, мы пришли в к выводу:

1) В некоторых языках он не нужен, потому что там нет объектов и присваивания

2) В некоторых языках он не нужен, потому что его нельзя применить, так как используемая модель ООП делает его ненужным в принципе.

3) В некоторых языках (С++) - без них сложно обойтись.

Ок, давайте двигаться от этой точки.

Думаю очевидно, что паттерн Singleton появился в первую очередь как опыт программистов, а не как не косяк С++ или недостаток его стандартной библиотеки.

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

Однако это взгляд на проблему с одной стороны, при обсуждении же можно зайти и с другой, рассмотрев зачем же тогда в некоторых языках появляются встроенные паттерны. Здесь, думаю, уместна будет языковая аналогия. Так, известным фактом является, что в языке эскимосов есть over 100 различных терминов для снега. Нам такие описания плоскопараллельны ибо мы живём в другой среде, а если и понадобится описать обоссаный снег, мы всегда можем добавить к существительному снег соответствующее прилагательное.

У меня как то так выходит.

shty ★★★★★
()
Ответ на: комментарий от anonymous

> это я Вас спрашиваю

Уха-ха-ха! Ну ты и стрелочник! )))

Уха-ха, ну ты и тормоз! До тебя только на третье сообщение дошло что я у тебя спрашивал. :)

shty ★★★★★
()
Ответ на: комментарий от ky-san

Да, становятся более прагматичными, перестают верить в серебрянные пули и полезность паттернов для макак и С++ вообще.

всё так :)

shty ★★★★★
()
Ответ на: комментарий от shty

shty, глянул я на ваши предыдущие темы/посты: оказалось, что вы даже не знаете разницы между malloc и calloc, более того даже не в состоянии сами понять ее без постороней помощи.

PS: пруфлинк http://www.linux.org.ru/forum/development/4732932

anonymous
()
Ответ на: комментарий от anonymous

пусть камнем бросает тот, кто сам без бревна в глазу :)

shty ★★★★★
()
Ответ на: комментарий от shty

> а не как не косяк С++ или недостаток его стандартной библиотеки.

Нет, именно как недостаток. Только не с++, а кривого ООП.

anonymous
()
Ответ на: комментарий от anonymous

>Думаю очевидно, что паттерн Singleton появился в первую очередь как опыт программистов, а не как не косяк С++ или недостаток его стандартной библиотеки.

Нет, именно как недостаток. Только не с++, а кривого ООП.

Вы говорите, что всё ООП - кривое, я правильно понял? Ну тогда я просто принуждён спросить, а что же не кривое по Вашему мнению?

shty ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.