да , ну и что оптимизация была включена!

MAKCim, спасибо за перевод,
но всеравно смысл этого volatilе не велик , в некоторых случаях без него никуда, но этих случаев очень мало, дабы считать их кардинальными


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

Добавлено @ 12:28 

преймущество С++ перед Дельфи

А где то нет   
(это к возврату к теме обсуждения)

прочитал , эту белеберду, осилил, но понял меньше четверти  ибо я не силен в высшей математике, до таких высот. Ибо надобности не было ее так сильно изучать , и все эти пространства чисел, их вхождения и т.п. мне не понятны (если я не ошибся с терминами) 
а что либо писать с нуля , я просто не в состоянии понять что имено надо написать, я эту хрень и на С++ тоже не напишу, и в матлабе даже  не тот уровень знаний
так что ваши фразы с ловушками и без них мне ничего не говорят.
Так что ув. Artemios предоставьте код на си и я посмотрю, реально ли его переписать на дельфи,
ибо здесь уже приводился код который говорили что нельзя написать на дельфи  но это не так.
Жду ваш код, и не только его объявления

Добавлено @ 12:47 

дык сделай что то типа такого

или вывод на консоль добавь , 
вкл фантазию 

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

в принципе согласен, это все таки не то применение, для чего эта возможность создавалась (хотя применение volatile в таком контексте - показатель все мощи этой штуки   )

этого нет в виндовсе пример из винды есть?

PS так что в конце выяснили, что преимущества С++ перед Дельфи есть , но они не существены, правильно?

неа   
это только один пример был
им дело не ограничивается
где пространства имен? где static-данные внутри функций/методов? (шаблоны не упоминаю), где explicit-конструкторы? где mutable-данные классов/структур? где явная спецификация исключений метода/функции? где placement new? где константные методы? где макросы и условная компиляция? (это, конечно, прямо к языку не относится, но все же)? где private, protected наследование? где множественное наследование? (только не надо говорить "на фига оно нужно", это уже другой вопрос)

Добавлено @ 21:26 

открой исходники     
думаю, 100% найдешь

Это сообщение отредактировал(а) MAKCim - 29.11.2006, 21:31

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

у мя его нету 
дай а?

вообще то это была шутка   
или ты тоже шутишь?   

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

так же как volatile?    

мы Delphi рассматриваем неразрывно с IDE? Тогда и С++ надо рассматривать в том же контексте
если брать чисто языки - С++ и Delphi (aka ObjectPascal) и, например какие-нибудь их компиляторы (для красоты - без GUI),то, думаю, на С++ все будет удобнее, имхо

а надо расшифровывать?

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

оки скажи аналог иде для С++, в котором также удобно работать как и в Дельфи(кроме билдера)

ну судя по смайлу ...

давай

почему не билдер?

ибо это тот же дельфи только на С++ 

завтра

и что по нему судя?

И кто тут так настойчиво требовал уважения к собственной персоне? 


 Вообще-то фразу "ловушка No..." я ввел как формальный указатель на ключевые моменты рассуждения, дабы не приводить их каждый раз заново. Судя по тому, как ты зацепился за это слово -- формализация не удалась, надо мне было просто цифры в скобках давать, как при обозначении формул. Или пунктами называть...


Ну и опять же, ты не понял, что я пытался сказать об общих принципах. Алгоритмы общие для широкого класса алгебраических структур -- по этим структурам произведена параметризация и пишутся шаблоны. Допустим, есть шаблон класса с тремя параметрами и допустим, для каждого параметра у нас заготовлено по пять реализаций. Теперь представь, что в отсутствии шаблонов для каждой комбинации фактических значений параметра мы пишем отдельный класс. Сколько будет таких классов? Правильно, 5^3=125. Другой вариант, когда пользователь будущей библиотеки захочет применить стандартный алгоритм для собственных структур. Элементарно, он пользуется библиотекой шаблонов и компилирует свою программу под свои собственные расчеты.
Хорошо, допустим, разработчик, неимеющий шаблонов, вспомнил про основы ООП и описал для каждой пятерки базовый класс. Кажется все замечательно, но только что будет с производительностью при полиморфизме времени выполнения? Учитываем, что параметрами шаблона были описаны низкоуровневые алгебраические структуры, и в ходе работы алгоритма на этих структурах производится не одна тысяча операций.
Вывод: без шаблонов конечно написать можно (я и не говорил, что нельзя принципиально), но только будет это неоптимально по объему написанного кода и/или неэффективно по времени выполнения.

Это что касалось шаблонов. Теперь о самих низкоуровневых алгебраических структурах. Например, я хочу использовать рациональные числа неограниченной точности. Для C/C++ есть билбиотека gmp (http://www.swox.com/gmp/). Реализован ли на object pascal какой-нибудь аналог для целых чисел произвольной длины и дробях на них, сопоставимый по производительности? Лично я видел только порт на дельфи все той же gmp, и врятли порт будет эффективней. Ну хорошо, gmp написана в перемешку с ассемблером, переформулирую вопрос: есть ли сопоставимый по производительности аналог, реализованный на object pascal + asm ? Нет.

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

P.S. А вообще, я не знаю ни одной системы компьютерной алгебры, написанной на object pascal. В основном как-то C, C++, Fortran, Lisp-подобные, и их комбинации c ASM ...

P.P.S. Да, и обращайся ко мне на "ты", а то как-то коробит. Все-таки ровесники  

А терь точнее , или я своими высказываниями лично вас чем то оскорбил?

ибо часто юзал

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

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

опасно такое делать имхо! ибо юзер может применить стандартные алгоритмы не правильно
(примени сортировку целых чисел , на строке чтополучится?)

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

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

Есть еще примеры проблем перевода С++ на дельфи, кроме ваших дробей?
(я еще не смотрел тот заголовочный файл предоставленый вами)

Посмотрим, и имхо
даже ровестики должны уважать собеседника, и разговаривать без наездов, имхо.

этого нет (лично я и смысла большого в нем не вижу)

вроде не видел

нет

нет (имхо из за того что нет перегрузки операторов , в частности присвоения)

нет (тоже не понятно для какой цели придумали)

это не совсем понимаю, поясни это плз

можно , но не так как в С++

может и не то


макросов имхо нет,
а условная компиляция есть (исходник Indy это хорошо подтверждает)

нет имхо

частичтно можно реализовать на интерфейсах

Добавлено @ 11:09 



и что в этом исходнике сложного для переписания на дельфи?
единственое мне не известное это
static Allocator *allocator;
что есть слово с большой буквы?
А все остальное ничего сложного, кроме тех деталей которые не реализуемы на дельфи (типа перегрузки операторов)
И кса в исходном коде нет шаблонов!?

бывает ...  

явное указание того, какие исключения может бросить функция/метод


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

однако сама функция осталась то неконстантной

при чем тут перегрузка?

сиба

да, а что нельзя обойтись без константных ф_ций?

да точно чет не туда занесло