м/у первым и вторым смещение 20, м/у вторым и третьим - 32. Соответственно, объекты в памяти располагаются не подряд (что однако не может исключать и такую ситуацию). Соответственно жду объяснений "цитата достойна башорга". По коду теста - обычный byte был обернут объектом (у нас ведь мега-труе-высокоуровневый язык), не класс, но к тому стремится. В список попадает указатель на объект. Соответсвенно, раз тут все таки мега-труе-высокоуровневый язык, то все массивы нужно делать **связным списком. Потому что зачем хранить массив целиков в памяти? все равно низкоуровнего доступа нет. Зато применение указателей позволяет почти мгновенно менять элементы массива местами (поменять всего лишь указатели, а не куски памяти м/у собой), а так же впендюривать в массив объекты различной "ширины". Туда ведь собираются пихать и строки, и числа, это ведь мега-труе-высокоуровневый язык?
TObject - не класс? и годится для представления чисел и байтов? ))) а по ссылке в вики виды списков смотрел? )) (про реализация массивов в пыхе помолчим)
armadillo а где у меня там Tobject? а это как то меняет смысл фразы ? вообще, смотрел, некоторые виды (одно и двухсвязные) реализовывал (типа нативно, в пределах класса), но только ради тренировки и интереса потому и удивляюсь, откуда там возьмуться дикие тормоза и прочие полтергейсты... ЗЫ: а вот почему это? мы ведь говорим о языке, который почти во всем повторяет функционал ПХП
тормоза при списке объектов раскиданных по памяти быть должны. оттого и башорг. record, как и класс, имеет ссылку на свой прототип. увеличивать размер сверх необходимого не стоит - наоборот, пора думать об упаковке данных при отправке в память. но это не означает невозможность такой обертки для простых видов, тем более универсального типа.
я бы понял, если бы мы сейчас говорили об оптимизации на уровне асма (или любого прикладного - Си, Дельфа), тогда да, посмеялись бы. А тут язык сродни ПХП, скорость совершенно будет незамена. А списки, как уже говорилось, куда удобнее хранят разногодные данные (потому что хранаят собсно одни указатели). Ну и от того, что объекты раскиданы по памяти - не тормозит это совершенно (при переборе да, на один вызов больше) и все. Может некоторых пугает само слово - раскиданые по памяти? Но при доступе к элементу не будет ведь перебора всей памяти чтобы найти объект, доступ по указателю идет, который совершенно ясно указывает месторасполажение. Зато какой плюс дает - при добавлении элемента в список ("массив" в ПХП) не нужно чистить область памяти "возле" массива, чтобы притулить туда новый элемент, достаточно выделить память для указателя (4 байта, или 8, а вообще емеет место оптимизация и выделение сразу блоками, про запас) и состаться на созданый объект где бы он не находился.
> Соответственно жду объяснений "цитата достойна башорга". > К плюсам "связных" списков - фрагментация в памяти > обычный byte был обернут объектом (у нас ведь мега-труе-высокоуровневый язык) труъ - не паскаль. паскаль - не труъ. (c) труъ про "чем не является труъ" почитай про ооп в яваскрипте, питоне и им подобных языках. > Соответсвенно, раз тут все таки мега-труе-высокоуровневый язык, то все массивы нужно делать **связным списком. угу, ты ещё sleep-ы понавставляй после каждой инструкции... > Потому что зачем хранить массив целиков в памяти? затем, что мы в данный момент с ним работаем и хотелось бы, чтобы процесс обработки закончился раньше, чем пользователь уснёт от скуки. > Зато применение указателей позволяет почти мгновенно менять элементы массива местами офигеть какая полезная операция. действительно, какой смысл делать со строками что-то кроме перестановок символов? > Может некоторых пугает само слово - раскиданые по памяти? Smile никогда не слышал про такую штуку - "кэш процессора" называется? говорят сильно увеличивает производительность... > Но при доступе к элементу не будет ведь перебора всей памяти чтобы найти объект, доступ по указателю идет при случайном доступе - будет.
dark-demon есть что сказать - говори, мы выслушаем. А то сливать "иди почитай" не получится, у нас серьезный холивар )) Байт обернул в объект, так как тут говорилось все типы представлять как объекты (классы с методами). очень, очень интересная фраза. Я бы очень хотел бы узнать, каким образом она отностится вообще к теме. Ну пожалуйста? %) в ПХП сильно медленно идет работа с массивами? любые операции над списками те же, что и с массивами. Только некоторые быстрее, а некоторые медленей (у массива быстрее последовательный доступ, у списка он на ОДИН такт больше выполняется на итерацию, остальное - пофиг) "говорят - кур доят". еще одна интересная фраза, продолжай, я хочу узнать, что за ней стоит )) наконец то в обсуждении мега-труе-высокоуровнего языка дошли до кеша процессора )))) я ваще фигею.. Ну сам попробуй КЛАСС хранить в массиве. Последовательно. Я бы на это посмотрел. Ладно, разрулишь ситуации, когда классы разных размеров. Ухохотаться можно, когда там будут операции над массивами, типа слияние, удаление в середине, а когда уж классу нужно будет сделать free а потом память за собой почистить и сдвинуть остальные.... )))))) В массивах хранят ДАННЫЕ, не классы, у которых из данных одно поле (ну value), а именно данные. Типа массив байт. Обычных байт, без всяких классов. данные одним махом последовательно удобно обрабатывать, потому что можно задействовать ММХ (ну есть там не операции над плавающими числами). не будет. в последовательном доступе: Код (Text): mov eax, [ebp - $04] при списке: Код (Text): mov eax, [ebp - $04] mov esi, [eax + $08] (дальше по цепочке, список ведь) итак, где тут перебор, где тут тормоза? Одна операция на доступ к следующему элементу. Учитывая как этот мега-труе-высокоуровневый будет тормозить - тут хоть сотню операций пропусти - не заметишь. приведение типов, в список помещаю указатель. st.Add(TObject(bb)); можно записать и как st.Add(bb);, т.к. bb уже указатель. Ошибки не будет. ЗЗЫ все, пошел на работу, потом почитаю оправдания )
> Байт обернул в объект, так как тут говорилось все типы представлять как объекты (классы с методами). нет никаких классов и не у всех объектов есть собственные методы. >> угу, ты ещё sleep-ы понавставляй после каждой инструкции... > Я бы очень хотел бы узнать, каким образом она отностится вообще к теме. Ну пожалуйста? нет предела идиотизму > в ПХП сильно медленно идет работа с массивами? да > Ухохотаться можно рад, что тебе весело. а теперь иди читай про прототипное программирование и про архитектуру пк. не возвращайся, пока не поймёшь, что получение данных из памяти - это далеко не один такт процессора на холостом ходу. >> при случайном доступе - будет. > не будет. > в последовательном доступе: ... > итак, где тут перебор, где тут тормоза? тролль > Учитывая как этот мега-труе-высокоуровневый будет тормозить не будет. именно потому, что писать интерпретатор для него будешь не ты.
где тут дело? человек совершенно не понимает о чём говорит и совершенно не умеет читать. ему бесполезно что-либо объяснять.
dark-demon Нинада... человек как раз говорит очень здраво (на мой взгляд из погреба). А вот ты временами опускаешься до флуда. Имхо, здесь его и так достаточно, незачем усугублять и уж фразы типа "тролль", "нет предела идиотизму" теме точно не добавляют красоты. Нафиг вы вообще ушли в вопросы реализации, не понимаю. Разберитесь хотя бы с синтаксисом сначала. Пока что я не вижу у труэ-языка никаких преимуществ даже по сравнению с PHP.
да, конечно, время на операцию с памятью значительно превышает время на работу с регистрами, однако оно с лихвой перекрывается операциями над "классами в массиве". За троля - спасибо, слив защитан.
подолжим... на этот раз о "цыклах": проверенные временем варианты: Код (Text): var $i= 1; var $res= 1; while( $i < 10 ){ $res*= $i; ++$i; }; Код (Text): var $i= 1; var $res= 1; do { $res*= $i; ++$i; } while( $i < 10 ); Код (Text): var $res= 1; for( var $i= 0; $i < 10; ++$i ){ $res*= $i; }; последний вариант имеет приятную особенность - блок инициализации, выполняющийся только один раз, но не засоряющий пространство имён вне цыкла. однако, как показывает практика, не редко этого всего не хаватает и приходится юзать специальные функции: berak, continue и return также стоит упомянуть и рекурсивный цикл: Код (Text): var $res= 1; var func= function( $i ){ $res*= $i; if( $i < 10 ) func( ); } func( 1 ); отличительной его особенностью является независимый контекст выполнения для каждой итерации, что иногда бывает полезно. однако, есть и ещё один вариант, который я ещё нигде не встречал: специальный операторный блок образует бесконечный цикл, из которого в зависимости от условий можно выходить теми же break, continue и return. Код (Text): i: 1 res: 1 loop fac10 res mult $i i inc 1 if( $i >= 10 ): break loop fac10
продолжу предыдущего оратора... иногда полезно иметь возможность создать отдельный контекст дабы не засорять общий. на яваскрпте, например, это делается так: [js]new function( ){ // тут мы имеем новый контекст }[/js] но это хак, ибо оператор function делает гораздо больше, чем просто обезопашивает общий контекст от нашего кода. [js]res: 0 sub mySub res: 1 sub mySub echo $res[/js] - выведет 0 для доступа к родительскому контексту используется специальный синтаксис: [js]res: 0 sub mySub1 sub mySub2 %%res: 1 sub mySub2 sub mySub1 echo $res[/js] - выведет 1 последний пример иллюстрирует паттерн "контролируемое лексическое замыкание". то есть, с помощью процента мы явно указываем какие переменные мы хотим замкнуть, что исключает случайное использование переменных из родительского контекста. скомбинируем контексты с лупами: [js]res: 1 sub calc i: 1 loop fac10 %%res mult $%i %i inc 1 if( $%i >= 10 ): break loop fac10 sub calc[/js] у нас получился аналог цикла for из си-подобных языков для простых циклов это может показаться слишком сложной конктрукцией, но для сложных - такой подход позволяет значительно увеличить наглядность. к тому же для простых частных случаев всегда можно "расширить язык" своими конструкциями (создать объекты принимающие определённые сообщения и тем самым эмулирующие поведение некоторых операторов доступных в других языках)
во многих языках есть поддержка многострочных строковых констант, везде есть проблема совмещения их с програмным кодом, который принято оформлять отступами. в качестве варианта решения предлагаю ввести для строковых констант символ начала строки: [js]myString > произвольный текст > пробел после угловой скобки > обязателен! myString[/js] [js]mystring:> однострочная строка[/js] [js]myString: "ну и по старинке"[/js] комментарии - аналогично, но используется другой символ: [js]myString # это комментарий > а это - строка # кто первый встал - того и тапки myString[/js]
да у меня и самого сейчас каша в голове выкладываю чтоб не забыть.. у меня есть голубая мечта - разработать язык синтаксис которого можно было бы свободно расширять средствами самого же языка.
1). Есть многосттрочные комментарии для комментов /* */ Лично я прекрасно оформляю код так: PHP: <?php class Foo { /* * Class constructor */ public function __construct(){ } } P.S. Use tab's! 2). Есть возможность делать так: PHP: <?php $str = 'bla bla bla'. 'bla bla bla;
1. если потребуется закомментить весь класс, что ты будешь делать с такими комментариями? 2. это не так лаконично, как мой вариант
1. 1 класс = 1 фаил. Закоментил require - гатавс. К тому же нормальные IDE умеют закоментить выделенный код целиком. А потом его ещё и откоментить тоже. Так что не аргумент, многострочные комментарии есть, факт. К тому же есть комменты в виде //, так что ваш # - шило на мыло. Чисто представление и привычка. Я обычно комментирую так PHP: <?php $count = 0; // Счётчик чего-то там 2. a). В PHP есть PHP: <?php усрщ <<<DATA bla bla bla bla bla bla DATA; b). Ну мы не про Basic-type языки же говорим. Честно говоря и так способов задать строку достаточно. Если вам надо вывести блок информации на HTML - ему пофигу сколько там табов или пробелов - он их не учитывает, поэтому можно не париться + исходник выглядет по человечески. В C/C++ при написании приложений вообще другой подход. Так что, ИМХО, универсального языка не создать. Либо он будет универсален, но слишком перегружен разными видами синтаксиса (и скорее всего из-за этого черезмерно сложный и не шибко шустрый), либо ограничен в возможностях в определённых сферах. ИМХО, намного проще выучить один язык для WEB программирования и ещё один для системного программирования и в зависимости от задачи выбирать один или другой и не парить себе мозг. У меня в офисе коллега спокойно работает со связкой PHP/C/C++/Java и прекрасно справляется. В основном правда работает с PHP и C/C++
> Закоментил require - гатавс. все require во всех файлах? > К тому же нормальные IDE умеют закоментить выделенный код целиком. каким образом? > К тому же есть комменты в виде //, так что ваш # - шило на мыло. решётка используется во многих языках и короче в два раза. слэши же традиционно используются для регулярок. > усрщ <<<DATA bla bla не решает проблему отступов, это вообще довольно глупая нотация > Если вам надо вывести блок информации на HTML - ему пофигу сколько там табов особенно весело потом смотреть его дамп в целях отладки... > У меня в офисе коллега спокойно работает со связкой PHP/C/C++/Java и прекрасно справляется. а у меня есть знакомый, который спокойно ходит по канату. давай отменим пешеходные переходы - пусть все ходят по проводам.