- 1
- 2
- 3
- 4
- 5
- 6
Point ReadPoint ()
{
Fixed x = ReadFixed();
Fixed y = ReadFixed();
return Point(x,y);
}-
C++ / Говнокод #13803
−11
Как же меня бесит отсутствие чётко определённого стандартом порядка вычисления аргументов!!!!!!!
Запостил:
TarasB,
17 Сентября 2013
Follow us!
Это же Тарас, наверняка карты уровней/сохранения/текстуры из файлов вычитывает.
p<<ReadFixed()<<ReadFixed();
return p;
что ли?
О боже, дефекейт не в ту сторону стрелочки нарисовал! Вот что жаба с людьми делает!
править не буду :)
но дело не в этом
объекту не важно откуда его читают (это обеспечит тебе std::istream)
зато ему важно, чтобы он сам контролировал своё состояние и целостность (это обеспечит тебе его же член класса fixed, point и т.д.)
захочешь потом читать число не из файла, а из памяти, например (принял xml из сети) - будешь писать новую функцию ReadFixed()?
поправил
как спасёт твой способ?
CreateRectBrick - это что? видимо, нечто, отдающее объект RectBrick
этому объекту виднее, как он хранится, как ему сериализоваться и десериализоваться
Сериализация есть, работает совсем иначе.
Данные для загрузки бинарные и содержат совсем другую информацию, храняющую именно текущее состояние.
Трабла в том, что стрелки для всяких int'ов перегружены под текстовый ввод-вывод. И придется либо пилить свой базовый класс для бинарных стримов (например как обертку над istream), либо обертки для примитивов...
но для задачи сериализации/десериализации я бы не стал вообще уже велосипед изобретать - boost::archive
польза в том, что правила сериализации/десериализации можно описать один раз, ну и то, что ты хочешь - boost::archive::binary_i(o)archive - есть в коробке
Везет Тарасу, его еще не поразило ООП головного мозга.
Параллелизм это отдельная тема. Там не только компилятор, но и процессор любит пошалить.
Знание модели памяти твоего языка (если, конечно, это не си) спасет отца русского параллелизма.
логично но в случае func(funca(),funcb()) порядок выполнения funca(),funcb() строго не определен. поэтому иногда нужно выносить и ставить барьер памяти
требуется многотомник по крестосмирению и крестопросветлению, 21 день слишком мало для этого
З.Ы. Язык похож на питона проглотившего паскаль и си.
от ООП нужна только парадигма "реализует интерфейс", и то желательно в виде, близком по духу к Haskell: не путём "наследования", а через отношение тип - семейство типов.
и поужинавшего Go, Scala, Haskell и, возможно, Ocaml
в остальном не понимаю только слово Unit, без него семантика обычная сишно-паскальная, только разве что множественный возврат
объект типа "Нихрена"
присваивание лучше выглядит как
a(0) <- 1
только это не очень хорошо сочетается со всякими +=. Предложи свой вариант оформления цикла.
a(i) := a(i - 1) + a(i - 2); } );
А вооще я хочу изобрести язык, где запрещены любые циклы, кроме циклов по диапазону с границами, известными при компиляции.
Рекурсия и блокирующие операции тоже запрещены.
Это позволит любому участку кода при компиляции дать оценку времени выполнения.
Да, придётся делать дохрена уиелдов для записи любого алгоритма, надо, чтоб язык это поддерживал.
На основе этого языка написать ось, которая никогда не будет виснуть - ведь в ней WndProc будет ограничена по времени.
Только в ядре, конечно же, придётся разрешить циклы итд, ядро надо писать на другом языке. А вот все прикладные программы - в виде исходников на этом языке.
Эта ось будет многозадачно работать даже без потоков, правда, как красиво использовать возможности 4 ядер, я пока не могу придумать.
по поводу инвариантов - цикл for не так уж плох, мы тут недавно с царём его обсуждали. for же по факту из трёх частей состоит: 1) установка инварианта 2) проверка инварианта 3) изменение состояния, потенциально влияющее на инвариант. Таким образом, тело цикла выполняется только в случае выполнения некого инварианта (типичный примеры - индекс массива находится в заданных рамках, нода списка не пуста, etc). Часто удобно видеть все три части вместе.
Для остальных можно оставить крестозапись.
Модель Ерланга? Там используются операции гарантированного времени или костыль, называемый потоками?
RealTime оси есть, я знаю, только дорогие. Неудивительно, что дорогие, и как сделать дешевле, даже не знаю толком.
Винда не риалтайм, и иногда это оооочень заметно и просто пиздец бесит.
А как же тогда искать файлы? Первое, что пришло на ум.
Конечно, блокирующий ReadLn идёт нафиг, а вот событийно-оприентированный подход, как в Edit, уже проканает.
Об этом есть интересная популярная книжка Хофстадтера: Гедель, Эшер, Бах, где он описывает как Рассел "избавился" от парадоксов в теории множест, но тем самым сделал ее неспособной решать настоящие проблемы. Вернее, думал, что избавился. Ну а Гедель, собственно, показал, что в любой системе такого типа парадоксы неизбежны.
> задач, где нельзя наперед знать время выполнения
Нет таких задач. Дело в том, что любой алгоритм квантуется. То есть можно разбить на несколько (возможно, бесконечное число) действий
SomeObject.NextIteration, каждое из которых имеет детерминированное время выполнения.
А в MainHandler ты просто делаешь проверку, что если мы в данный момент недовыполнили такую-то задачу, то надо выполнить следующий квант её решения.
Если оно будет бесконечным, то мы уже нарушили наше обещание отсутствия бесконечных циклов...
Пример: программа-часы.
Часы могут идти хоть вечность.
Код программы:
Ну с точностью до шелухи типа передачи параметра типа события, кода создания окна при получении MESSAGE_STARTPROGRAM, реакции на закрытие программы.
Обещание нарушает ось, а не программа. Оси мы доверяем.
Это тоже решается тем же квантованием, но в данном случае будем считать, что у виджета окно имеет конечный размер, так проще для понимания.
Чтобы это лучше понять:
1. Попробуй почитать книжку о которой я говорил двумя постами раньше.
2. Подумай, как ты реализуешь таймер без безконечного цикла.
2. Подумай.
Таймеры в ТарасоОси будут реализованы на уровне ядра, где бесконечные циклы вполне разрешены. Вот и все решение.
А без минималистичного доверенного ядра, которое может делать все что угодно, задача не имеет решения ;) По крайней мере на текущем железе.
Ну в каком-то смысле да. Только с реализацией его извне, а не с помощью средств языка.
Ага, вот только тот же BEAM (эрланговый рантайм) вполне справляется с этим квантованием на автомате. Текущий "поток" (в терминологии эрланга процесс) получает право сделать N редукций (вызовов функций), после чего он обязан отдать управление шедулеру. Циклов там вообще нет, поэтому повиснуть не делая редукции он не сможет. Простым, неблокирующим нативным функциям приписывается оценка в редукциях, в зависимости от времени их исполнения. Сложные или блокирующие нативные функции крутятся в отдельных сервисных потоках, не мешая основному планировщику.
То, что ты изобретаешь, очень напоминает эту идею. Вот только ты издеваешься над программистом, заставляя делать квантование руками.
Или процессор, OH SHI-...
Проблема только в том, что он может алгоритм порезать на части не совсем там, где тебе надо, поэтому привет 100500 проблем синхронизации и прочей фигни.
В эрланге их кардинальным образом решили: "процессы" не могут иметь общей памяти. Вообще. Инфой они могут обмениваться только передавая месаги друг-другу.
P.S. Вобщем покури эрланг, лишним не будет. Может какие-то идеи оттуда почерпнешь для себя.
1. Тарас идёт на shootout и смотрит производительность эрланга.
2. Тарас печатает книгу по эрлангу и публично сжигает её.
delay vs throughput... извечная проблема...
Большинство систем перекошено в сторону throughput, и поэтому совершенно не катят для реалтайма из-за конских и недетерминированных задержек (например квантом по 50мс в типичных осях).
Эрланг и реалтайм оси уменьшают delay, но за счет этого они медленней.
Выиграть и в том и в другом невозможно ;)
Хехе, можно ещё ввести оператор, который сохраняет состояние в специальную структуру (возвращает её ид), и возвращает управление системе (при этом в очередь сообщений запихивается MESSAGE_CONTINUE с параметром ид, чтобы можно было его схватить и продолжить выполнение). Тогда рекурсии и бесконечные циколы уже разрешены получаются. Но этот сахарок уже слишком приближает программу к классической говнопоточности.
Но без него даже удлинение строки в пиздец превращается.
Баян: call with current continuation в scheme, отчасти питоний yield, крестоблядский boost::context и boost::coroutine в конце концов :)
> классической говнопоточности
Классическая говнопоточность все-таки имеет плюс - последовательный алгоритм выглядит как последовательный алгоритм, а не как распидорашенная асинхронная кастрюля с лапшой.
Ну, это дело привычки, надо подождать, и народ проникнется же!
...какое-то пидорко заботовало 16 раз...
К сожалению народ уже проникся... И эта кастрюля с лапшой называется NodeJS.
Кстати, взгляни на питонскую либу twisted. Вот где имхо асинхронщину красиво вывернули на изнанку. Там последовательный код неплохо смотрится. Емнип, добавляется только yield перед каждой "блокирующей" операцией.
Async руки, у кого нету - сосет.
Ну вот async/await в шарпе и yield в аналогичных целях в twisted'е, это таки кошерная асинхронщина, в которой линейный алгоритм выглядит линейно.
А вот тот же node.js - ебучая лапша.
Елда тут не причем, в твистеде там елда с декоратором работает. И отдельное ключевое слово лично мне больше нравится.
а ещё пиздец, что есть разные операторы и
> анальный 31-битный инт
> есть разные операторы
ты путаешь с Окамлом
Так это другой язык!
Интересно...
> хорошо спроектированной библиотекой
> модульной системой
> прозрачной семантикой
>> Forth.
/0
Ну а типизации нет никакой. Если сильно хотелось строгую типизацию, то конечно Форт не подходит, но по сравению со всем остальным... ну, еще Оккам - интересный вариант, но он, на сколько я понимаю, остался только в книжках.
Ага... ее просто нет... ибо вся семантика скрыта в словах. И каждое слово может иметь такую семантику, как хотелось его автору. Впрочем и синтаксиса тоже нет.
Форт и так не язык. Это конструктор для своих языков. Ну и набор стандартных слов, которые при желании можно выкинуть или переделать.
Для примеров того, как это делается / может выглядеть - все та же замечательная книжка Б. С. Пирса. Там он разбирает семантику очень простого языка (в котором есть 5 ключевых слов, цифры и ложь / истина). И это занимает три-четыре раздела в книжке. И это только один из подходов (он описывает операционную семантику).
http://books.google.co.il/books?id=ti6zoAC9Ph8C&lpg=PP1&pg=PA23#v= onepage&q&f=false
Но насчет форта - ну да, можно описать семантику изкоробочного набора слов. Но дальше то язык можно менять как угодно ;)
Никаких специальных конструкций в форте нет. Даже кавычка это обычное слово (из-за чего приходится писать после нее пробел, что довольно некрасиво), и при желании можно ее переделать, прикрутив другой формат для хранения строк.
Запилить что-ли на досуге такой диалектик...
Хотелось бы именно замену сишке, чтобы лоулевел и никакой магии. Ассемблер высокого уровня с нормальной семантикой и без вагона костылей.
C++98, 5.2.2 Function call, пункт 8 гласит:
The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations take effect before the function is entered. The order of evaluation of the postfix expression and the argument expression list is unspecified.
Так что нехуй полагаться на этот порядок, нехуй.
> __cdecl (по умолчанию)
На cdecl свет клином не сошелся. Особенно на таких платформах, как х86_64.
Типичная парадигма, которая в переводе на челевеческий означает: "мешает компилятору оптимизировать."
Я когда-то находился по граблям порядка вызова конструкторов полей объекта. Вашу боль понимаю.
O_o. А с ним то что не так? Емнип, порядок конструкторов-деструкторов очень строго расписан, без всяких undefined и unspecified.
> в порядке как они были указаны после двоеточия в конструкторе
На такое говно сейчас все адекватные компиляторы выдают ворнинг, уговаривая написать их в одинаковом порядке и в классе и в конструкторе ;) Что в общем-то решает проблему.
Отсюда и решение: забить на порядок в конструкторах (и выдавать ворнинг, если он кривой), верить только порядку полей в классе.
причем, очевидно, проблема легко могла быть не выявлена годами - когда в классе все поля Form1, Button5 и Label666
А списки инициализации в конструкторах девственно пусты?
Пиздец. Хотя код, зависящий от порядка исполнения дефолтных конструкторов\списка инициализации пиздец еще больший ;)
> 5й билдер
Его поди до стандарта писали... Ему простительно.
Ит ол мэйкс сэнс нау.
Всегда в одном и том же.
Студия всегда с конца, гцц всегда с начала.
А если опции оптимизации пощелкать? Или на x86_64 собрать? :)
Это твой автопортрет.
Это твой автопортрет.
Значит жопа-то твоя, а, петушок?
Окей. что и требовалось доказать. 12 ботов, +-2. 12-ый плюс кто-то другой поставил.
Если ты такой разговорчивый, почему проигнорировал мое лс? я отправлял с [email protected]
То есть ты говно пидорское, которое ссыт назвать себя?
Что прикажете делать, троллить его дальше, или заткнуть? Вы жаждете зрелищ, я знаю..
(
Мне кажется, его кто-то жестоко обманул.
Годные посты ведь были: http://govnokod.ru/13544
И доставляющее "Можно заблокировать тролля, но нельзя забанить троллинг, ибо это не причина, а следствие.".
А сраться с Тарасом и постить гоатсе - как минимум уныло.
Дичайший быдлокод, что и говорить. Но я постоянно совершенствую свои познания в Делфи, особливо учитывая, что я самоучка.
Ещё кое-кто любит сообщения редактировать. На почту приходит одно, отвечаешь уже на другое.
Подними уже трубку, мать твою.
yadelphi.ru/форум/фак/воспроизведение звуков через сис. динамик
Сколько ж можно это терпеть??
http://ru.wikipedia.org/wiki/%C1%E8%F1%E5%EA%F1%F3%E0%EB%FC%ED%EE%F1% F2%FC