[Pascal][C++] конвертер кода

1. моск. 2. gmp

не пойдет, т.к. си я только на картинках видел. я потому и спрашиваю конвертер, что даже не представляю себе, какой у си синтаксис

> не пойдет, т.к. си я только на картинках видел

друг/приятель/товарищ/знакомый, который знает С

сильно сомневаюсь в существовании идеальных средств по конвертации, т.к. мелких моментов просто невероятное количество, не говоря уже о том, что в некоторых местах "в лоб" код просто не конвертируется, и без знающего человека не обойтись. А т.к. подобное извращение мало кому нужно, то серьезно этим явно никто не занимался :) Так что учи синтаксис Си.

> А т.к. подобное извращение мало кому нужно, то серьезно этим явно никто не занимался :)

Встречал только в учебных целях -- на лабах писали как-то простенький синтаксический анализатор для пасквиля =)

увы, таких нет.

Тривиально. Сначала компилишь, потом вставляешь как asm.

> А т.к. подобное извращение мало кому нужно, то серьезно этим явно никто не занимался :)

отнюдь, я нагуглил конвертер за $950, в котором обещают точную конвертацию

> Так что учи синтаксис Си.

похоже, придется.

в том то и дело, что не компилится :) не хватает памяти, ибо числа огроменные. научрук посоветовал написать прогу на си/фортране, а я в них ни в зуб ногой

>> отнюдь, я нагуглил конвертер за $950, в котором обещают точную конвертацию

таки мир еще более безумен, чем я думал )

>> отнюдь, я нагуглил конвертер за $950, в котором обещают точную конвертацию

>таки мир еще более безумен, чем я думал )

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

> не хватает памяти, ибо числа огроменные.

Ты ничего не перепутал? Я понимаю, программа может НЕ РАБОТАТЬ, если в ней используются огромные числа (хотя я сомневаюсь, что C в данном случае чем-то поможет), но НЕ КОМПИЛИТЬСЯ?

> в том то и дело, что не компилится :) не хватает памяти, ибо числа огроменные. научрук посоветовал написать прогу на си/фортране, а я в них ни в зуб ногой

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

> не хватает памяти,

Вы гуголплекс пытаетесь в константах задефайнить?

"Компьютерная археология" :) говорит, что для численных задач когда-то были диалекты C-XSC, PASCAL-XSC.

http://progopedia.ru/dialect/pascal-xsc/
http://www.math.uni-wuppertal.de/org/WRST/index_en.html
http://www.ozon.ru/context/detail/id/2804145/

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

>Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: >Segmentation fault.)
> 2 DENSITYPLASMA() /home/kai/Documents/eclipse/workspace/plasma/dens.pas:89 0x080489cc
> 1 main() /home/kai/Documents/eclipse/workspace/plasma/dens.pas:144 0x080491ab

>Ничего, кроме мозга, вам невозможно посоветовать.

спасибо за совет :)

> Вы гуголплекс пытаетесь в константах задефайнить?

почти :)

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

Ну дык, правильный конвертер делает что? Сохраняет поведение таким, каким оно было. Значит, в соответствии с определением, конвертер обязан превратить сегфолтящуюся (is this a word?) программу на паскале в сегфолтящуюся (I did it again) программу на сях.

> в си вообще есть такое понятие, как 8мибайтовое число, больше чем 10^4000 ?

Есть 8-байтовое double, 2.22507e-308—1.79769e+308. Есть long double, которое в зависимости от архитектуры, компилятора и его версии может обозначать 8-, 10- или 16-байтовое число.

GCC 3.x на процессорах x86_32 может работать с 4-, 8- и 10-байтовыми.
GCC 4.x на процессорах x86_64 — с 4-, 8- и 16-байтовыми.
Паскалевский тип extended обозначает 10-байтовое.
По-моему, 10^4000 достижимо и на 10- и на 16-байтовых.

Обработка 8- и 10-байтовых на x86_32 идёт с одинаковой скоростью, если доступны 16-байтовые, будет гораздо медленнее.
10-байтовые регистры в 64-разрядном режиме, имхо, недоступны.
Как со скоростью 16-байтных в 64-разрядном режиме — не знаю.

p2c