
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[216.73.216.3] |
![]() |
|
Страницы: (31) « Первая ... 3 4 [5] 6 7 ... 30 31 ( Перейти к последнему сообщению ) |
Сообщ.
#61
,
|
|
|
Первое приближение: ![]() ![]() std::string to_roman(int num) { char* ones = "IXCM"; char* fives = "VLD"; std::string result; for (; num != 0; num /= 10, ones ++, fives ++) { int d = num % 10; if (!d) continue; int r = d % 5; if (!r) result.insert(result.begin(), 1, *fives); else if (r == 4) { result.insert(result.begin(), 1, d > 5 ? ones[1] : *fives); result.insert(result.begin(), 1, *ones); } else { result.insert(result.begin(), r, *ones); if (d > 5) result.insert(result.begin(), 1, *fives); } } return result; } |
Сообщ.
#62
,
|
|
|
вот откудато из инета, на C, возможно можно еще проще.
![]() ![]() char *to_rome(int n) { int k; static char s[ 20 ] = ""; int nd[ 13 ] = {l,4,5,9,10,40,50,90,100,400,_500,900,1000}; char * sd[ 13 ] = {"I","IV","V","IX","X","XL","L","XC","C","CD","D","CM","M"}; for(k=12; k>=0; k—) { while(nd[k]<=n) { n=n-nd[k]; strcat(s,sd[k]); if(n==0) break; } } return s; } |
Сообщ.
#63
,
|
|
|
Ну хорошо, убедили, что экономия не сильная. Правда, всё-таки в больших проектах я по-прежнему считаю, что Форт экономичнее, опять же в силу большего функционального разбиения и как следствие большего повторного использования кода. Просто предлагать большой проект в качестве сравнительного теста по меньшей мере глупо.
Цитата Sazabis @ вот откудато из инета, на C, возможно можно еще проще. На Форте с использованием того же алгоритма: ![]() ![]() create numbers 1 , 4 , 5 , 9 , 10 , 40 , 50 , 90 , 100 , 400 , 500 , 900 , 1000 , : number ( i -- n ) cells numbers + @ ; : digits s" I" s" IV" s" V" s" IX" s" X" s" XL" s" L" s" XC" s" C" s" CD" s" D" s" CM" s" M" ; : digit ( n -- a n ) >r digits 12 r@ - for 2drop next r> -rot >r >r for 2drop next r> r> ; : to_roman ( n -- ) 13 for begin r@ number 2dup >= while r@ digit type - end drop next drop ; А вот здесь ты неправ: это именно слово, а не символ. В Форте слова отделяются друг от друга пробелами, так что если я определю, скажем, слово a:;b, оно не будет восприниматься как начало и конец функции. Цитата LuckLess @ Разбиение на функции хорошо - но не настолько чтоб функция из пары строк уже читалась проблематично. Именно настолько. Если я это объяснил криво - Броуди объясняет лучше. Цитата LuckLess @ Отсуствие типизации - которое ставиться плисом аргументируя это цитатой тоже вещ странная. Получаеться что перед тем как твою функцию использовать я должен в нее залесть, прочитать и решть - подходит ли она мне или нет - так как типов то нет.. На этот случай есть комментарии. В конце концов, чтобы использовать функцию на С++, ты тоже должен посмотреть её описание. Только С++ выдаст ошибку во время компиляции, а Форт - во время исполнения, принципиальной разницы я не вижу. |
Сообщ.
#64
,
|
|
|
Цитата wormball @ Именно настолько. Если я это объяснил криво - Броуди объясняет лучше. Нет ничего в этом хорошего. Это очень избыточноя повторяемость кода. Цитата wormball @ На этот случай есть комментарии. В конце концов, чтобы использовать функцию на С++, ты тоже должен посмотреть её описание. Только С++ выдаст ошибку во время компиляции, а Форт - во время исполнения, принципиальной разницы я не вижу. Если выдаст)) Он может и не выдать, а во время выполнения просто неправильно работыть - так как типы не те. На С++ я сразу вижу как надо использовать функцию чтобы она привильно работала по ее определению. мне не нужны никакие комменты. И к томуже, если уж говорить о повторяемости кода, то в форт не идет ни в какое сравнение с полиморфизмом и шаблонами в С++. |
Сообщ.
#65
,
|
|
|
Цитата LuckLess @ Нет ничего в этом хорошего. Это очень избыточноя повторяемость кода. При чём здесь повторяемость? Это же наоборот, повторная используемость: если у тебя есть много маленьких функций, у тебя больше выбор, что использовать повторно, чем если у тебя мало больших функций. Цитата LuckLess @ Если выдаст)) Он может и не выдать, а во время выполнения просто неправильно работыть - так как типы не те. Ну так на это существует тестирование, я уже про это писал. Причём за счёт возможности отдельного (и быстрого!) тестирования маленьких функций понятие "труднонаходимой ошибки" сведено к минимуму. Цитата LuckLess @ И к томуже, если уж говорить о повторяемости кода, то в форт не идет ни в какое сравнение с полиморфизмом и шаблонами в С++. Поспорил бы, если бы знал, что это такое. Поделись ссылками? |
Сообщ.
#66
,
|
|
|
Цитата wormball @ При чём здесь повторяемость? Это же наоборот, повторная используемость: если у тебя есть много маленьких функций, у тебя больше выбор, что использовать повторно, чем если у тебя мало больших функций. Имел ввиду избыточную разбиваемость на функции. Очень редко когда надо делить программу на столь маленькие функции. Цитата wormball @ Ну так на это существует тестирование, я уже про это писал. Причём за счёт возможности отдельного (и быстрого!) тестирования маленьких функций понятие "труднонаходимой ошибки" сведено к минимуму. Зачем тестировать и находить ошибки там - где это не нужно. Цитата wormball @ Поспорил бы, если бы знал, что это такое. Поделись ссылками? к примеру. ![]() ![]() template <class T> T func(const T& val1, const T& val2) { return val1 + val2; } Тут для любого типа T имеющего оператор сложения сгенерируеться своя функция с правильным сложение. Соответственно не обязательно это работает для сложения, можно и для чего угодно другого. |
Сообщ.
#67
,
|
|
|
Цитата wormball @ Правда, всё-таки в больших проектах я по-прежнему считаю, что Форт экономичнее, опять же в силу большего функционального разбиения и как следствие большего повторного использования кода. Ну, сейчас функциональное разбиение и повторная использование кода также вменяется в плюс С++. Ты спрашивал, что по шаблонам почитать... Начни со Страуструпа ("Язык программирования С++"), продолжи Александреску ("Современное программирования на С++"). Из написанного в этих книгах можно сделать вывод, что шаблоны в С++ - вполне себе полноценный язык программирования, "программы" на котором выполняются во время компиляции (как-бы "внутри" компилятора). Вот приведенный Sazabis'ом код в чисто С++-ом исполнении на шаблонах: ![]() ![]() char* g_RomanDigits[] = {"I","IV","V","IX","X","XL","L","XC","IC","C","CD","D","CM","IM", "M"}; template<int I> struct RomanDigitInfo; template<> struct RomanDigitInfo<1> {static const int m_Next = 0; static const int m_SIdx = 0;}; template<> struct RomanDigitInfo<4> {static const int m_Next = 1; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<5> {static const int m_Next = 4; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<9> {static const int m_Next = 5; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<10> {static const int m_Next = 9; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<40> {static const int m_Next = 10; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<50> {static const int m_Next = 40; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<90> {static const int m_Next = 50; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<99> {static const int m_Next = 90; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<100> {static const int m_Next = 99; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<400> {static const int m_Next = 100; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<500> {static const int m_Next = 400; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<900> {static const int m_Next = 500; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<999> {static const int m_Next = 900; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<> struct RomanDigitInfo<1000> {static const int m_Next = 999; static const int m_SIdx = RomanDigitInfo<m_Next>::m_SIdx + 1;}; template<int I, int D> struct ToRomanImpl { static void Print() { if (D <= I) std::cout << g_RomanDigits[RomanDigitInfo<D>::m_SIdx]; ToRomanImpl<(D <= I) ? (I - D) : I, (D <= I) ? D : RomanDigitInfo<D>::m_Next>::Print(); } }; template<int I> struct ToRomanImpl<I, 0> { static void Print() { } }; template<int I> struct ToRoman { static void Print() {ToRomanImpl<I, 1000>::Print();} }; // использование для преобразования на этапе компиляции: ToRoman<2459>::Print(); Выдает честные MMCDLIX. ![]() Даже лучше вот так... ![]() ![]() |
Сообщ.
#68
,
|
|
|
Вставлю свое мнение касательно исходной постановки вопроса. Имхо, будущее где-то на стыке мультипарадигменного и генеративного подходов, когда исполняется заповедь Вирта и библиотеки сконцентрированы на аккумуляции знаний, а не тулкита.
|
Сообщ.
#69
,
|
|
|
Цитата Guderian @ мультипарадигменного С++... Цитата Guderian @ генеративного Это что? Метапрограммирование чтоли?? тогда тоже С++(шаааблончики..) |
Сообщ.
#70
,
|
|
|
Цитата LuckLess @ С++... Захотел я, например, языка на базе реляционной алгебры или манипулирование многомерными OLAP-кубами в духе MDX. Или может аспектно-ориентированный подхода. А потом захотелось синтаксиса максимально удобного для SWITH-технологий. Как? Скажем хочу я что-нибудь в духе Linq: ![]() ![]() List products = GetProductList(); var categories = from p in products group p by p.Category into g select new {Category = g.Key, MostExpensivePrice = g.Group.Max(p => p.UnitPrice)}; Цитата LuckLess @ Это что? Метапрограммирование чтоли?? тогда тоже С++(шаааблончики..) Можно сказать и метапрограммирование. Но "шаблончиками" этого не решишь. Как известно, есть задача и есть потребность в ее решении, сопровождаемая критериями эффективности, сроков, бюджетов и пр. Очевидно, что задачу не интересует, на чем она будет решена, до тех пор пока решение лидирует по этим критериям. И в ней непосредственно кодирование на C++/etc, как правило, есть малая толика ее жизненного цикла. Вот взяли мы этап анализа предметной области. Есть у нас бизнес-аналитик, который оперирует на диалекте IDEF0, используя процессо-ориентированный подход и переучивать его на C++ значит попрать критерии задачи. Можем ли мы при помощи мультипарадигменности языка дать ему наиболее удобный инструмент, а при помощи генеративного подхода продуцировать из описанного им шаблоны на том же C++, которые будут доведены до конечного продукта? Да. Помогут ли нам в этом шаблоны C++? Нет. Т.е. озвученная смесь значительно расширяет участие самого принципа "программирования" на те этапы жизненного цикла, которые доселе были языкам этого самого программирования недоступны. |
Сообщ.
#71
,
|
|
|
Цитата LuckLess @ Имел ввиду избыточную разбиваемость на функции. Очень редко когда надо делить программу на столь маленькие функции. Лучше я буду иметь дело с тысячами функций, занимающих одну строчку, чем с функциями, занимающими по 2, а то и 20 экранов. Сколько я ни видел чужих исходников, функции в них, как правило, занимают именно столько. Ты вообще знаком с понятием "хороший стиль программирования"? Почитай Броуди, это будет полезно, даже если ты не собираешься программировать на Форте. Цитата LuckLess @ Зачем тестировать и находить ошибки там - где это не нужно. Если ты пишешь программы абсолютно без ошибок, то я рад за тебя. Я пока что таким умением не обладаю. Насчёт отсутствия контроля типов - в Форте (по крайней мере в моём) все программы содержатся в виде исходников, так что у меня не возникает сложностей с подачей правильных аргументов на вход функции. Цитата Flex Ferrum @ Начни со Страуструпа ("Язык программирования С++"), продолжи Александреску ("Современное программирования на С++"). Ок, буду в книжном магазине - обязательно куплю. Цитата Flex Ferrum @ Из написанного в этих книгах можно сделать вывод, что шаблоны в С++ - вполне себе полноценный язык программирования, "программы" на котором выполняются во время компиляции (как-бы "внутри" компилятора). В Форте тоже есть возможность определять так называемые слова немедленного исполнения, т. е. слова, которые выполняются в процессе компиляции. Например, так определяется слово if. То есть можно самому вмешиваться в процесс компиляции, используя при этом все выразительные возможности языка. Причём если в С++, насколько я понимаю, для шаблонов пришлось изобретать фактически новый язык программирования, то в Форте возможность перепрограммировать компиляцию - неотъемлемая часть самого языка. Именно поэтому Форт обладает безграничной способностью к саморасширению: на Форте можно сделать всё, что можно на других языках программирования, например, ООП и даже контроль типов. (Другое дело, что контроль типов никто не делает, ибо это, во-первых, геморроидально, а во-вторых, сильно снизило бы выразительную мощность.) Собственно, потому я и стремлюсь узнать про преимущества других языков программирования: любое из этих преимуществ может быть реализовано на Форте. Ещё раз напоминаю, что я не преследую цель навязать кому бы то ни было свою точку зрения или уличить кого-либо в ретроградстве или мракобесии. Я затеял этот разговор исключительно для удовлетворения своего личного любопытства, просьба воспринимать его именно так. Цитата Flex Ferrum @ Вот приведенный Sazabis'ом код в чисто С++-ом исполнении на шаблонах: Судя по длине приведённого исходника, шаблоны - не такая уж мощная вещь. Скажем, наверняка нельзя построить шаблон, по которому будут строиться шаблоны. А в Форте - запросто. Цитата Guderian @ Т.е. озвученная смесь значительно расширяет участие самого принципа "программирования" на те этапы жизненного цикла, которые доселе были языкам этого самого программирования недоступны. Сколько ни стремлюсь исключить из своего лексикона фразу "читайте Броуди!", никак не получается. У Броуди одна или две главы посвящены именно тому, что Форт, помимо всего прочего, является и языком проектирования. Вот цитата: Цитата ЯЗЫК ПРОЕКТИРОВАНИЯ ~~~~~~~~~~~~~~~~~~~ Форт - язык для проектирования. Воспитаннику традиционной компьютерной науки такое утверждение кажется противоречивым. "Нельзя проектировать с помощью языка, с его помощью реализуют. Проектирование предваряет реализацию." Опытные Форт-программисты с этим не соглашаются. Вы можете писать на Форте абстрактный, проектный код и все равно имеете возможность проверить его в любой момент, применяя преимущества разбиения на лексиконы. При продолжении разработки компонент может быть легко переписан на уровне ниже компонентов, которые его используют. Вначале слова могут печатать числа на Вашем терминале вместо управления шаговыми двигателями. Они могут печатать свои собственные имена только для того, чтобы сообщить Вам о своем выполнении. Они вообще могут ничего не делать. Используя такую технологию, Вы можете писать простую, но проверяемую версию Вашей задачи, а затем успешно изменять и улучшать ее до тех пор, пока не достигнете своей цели. Другим фактором, делающим возможным проектирование в коде, является то, что Форт, как и некоторые новейшие языки, сокращает последовательность разработки "редактирование- компиляция- тестирование- редактирование- компиляция- тестирование". Вследствие постоянной обратной связи среда окружения становится партнером в созидательном процессе. Программист, использующий обычный язык, редко может достичь того продуктивного образа мышления, которое присуще артистам, если ничто не мешает течению их творческого процесса. По этим причинам Форт-программисты тратят меньше времени на планирование, чем их коллеги классического толка - праведники планирования. Для них отсутствие такового кажется безрассудным и безответственным. Традиционные окружения вынуждают программистов планировать, поскольку традиционные языки не готовы к восприятию перемен. К сожалению, человеческое предвидение ограничено даже при наилучших условиях. Слишком сильное планирование становится непродуктивным. Конечно, Форт не исключает планирования. Он позволяет создавать прототипы. Конструирование прототипа - лучший способ планирования, так же, как и макетирование в электронике. В следующей главе мы увидим, что экспериментирование проявляет себя более надежным в деле приближения к истине, нежели стоительство догадок при планировании. |
Сообщ.
#72
,
|
|
|
Цитата wormball @ Лучше я буду иметь дело с тысячами функций, занимающих одну строчку, чем с функциями, занимающими по 2, а то и 20 экранов. Сколько я ни видел чужих исходников, функции в них, как правило, занимают именно столько. Ты вообще знаком с понятием "хороший стиль программирования"? Знаком. Но разбивка программы на столь маленькие куски - никогда не являлась и не будет являться хорошим стилем, что бы там Броуди не сказал. Цитата wormball @ Если ты пишешь программы абсолютно без ошибок, то я рад за тебя. Я пока что таким умением не обладаю. Насчёт отсутствия контроля типов - в Форте (по крайней мере в моём) все программы содержатся в виде исходников, так что у меня не возникает сложностей с подачей правильных аргументов на вход функции. Причем здесь то пишу я без ошибок или нет. Я говорю о том, что в языках без контроля типов есть возможность попасть в ситуацию - когда будет иметь место труднонаходимая ошибка, в то время как на языках с контролем типов такой ошибки быть не может в принципе. Цитата wormball @ Причём если в С++, насколько я понимаю, для шаблонов пришлось изобретать фактически новый язык программирования, Ничего подобного. Просто заменяешь тип какимто абстрактным - и все. |
Сообщ.
#73
,
|
|
|
Цитата wormball @ Скажем, наверняка нельзя построить шаблон, по которому будут строиться шаблоны. Поясни. Не совсем понял твою мысль. 14 строчек с RomanDigitInfo - это вариант инициализации своеобразной списковой структуры. Тебе ведь пришлось написать: Цитата wormball @ create numbers 1 , 4 , 5 , 9 , 10 , 40 , 50 , 90 , 100 , 400 , 500 , 900 , 1000 , ? |
Сообщ.
#74
,
|
|
|
Цитата LuckLess @ Но разбивка программы на столь маленькие куски - никогда не являлась и не будет являться хорошим стилем, что бы там Броуди не сказал. Одно дело, если бы это сказал Броуди, а другое дело - что я это на собственной шкуре почувствовал. Так находить ошибки в программе действительно легче. Просто Броуди лучше объясняет. Цитата LuckLess @ в то время как на языках с контролем типов такой ошибки быть не может в принципе. Самый избитый пример, который приходит в голову - написание одного знака равенства вместо двух. Есть множество других примеров, про них написаны горы литературы. Главные ошибки в программах - это не ошибки с контролем типов, а ошибки в алгоритме, от них тебя никакой компилятор не избавит. Цитата Flex Ferrum @ Не совсем понял твою мысль. 14 строчек с RomanDigitInfo - это вариант инициализации своеобразной списковой структуры. Я в смысле того, нельзя ли, программируя на шаблонах, записать это покороче. |
Сообщ.
#75
,
|
|
|
Цитата wormball @ Я в смысле того, нельзя ли, программируя на шаблонах, записать это покороче. Как, например? Тебе нужно проинициализировать односвязный список. Ты можешь сделать это коротко? |