Google дал оценку Java и C++

>Этот пример ничего не показывает

Ты просто не смог или не захотел увидеть то, на чём я акцентировал внимание в этом примере. Впрочем, это не моя проблема.

Мне удобнее для чтения и понимания мой стиль написания тебе свой, комуто совсем другой

Книжку-то почитать не хочешь? Она полезная.

за коммит в репозиторий мне платят а за написание на форуме нет

Это характеризует твой уровень внутренней дисциплины. Впрочем, это не моя проблема.

В С++ педантичность как раз довольно полезна. Язык мощный, но небрежности не прощает.

>Плохому танцору и яйца мешают

Он ещё ассемблер не видел

Думаешь создатель Plan9 не видел ассемблер? ;)

>Думаешь создатель Plan9 не видел ассемблер? ;)
А что, Plan9 затачивался под конкретную архитектуру?
И к тому же, он таки «один из», а не создатель, и вполне мог разрабатывать те части которые ну никаким образом на архитектуру не завязаны.

А вот как разработчик компилятора своего «чудо языка» стопудово видел ассемблер.

>Книжку-то почитать не хочешь? Она полезная.

Я уже начитался, такого рода книжек. И жду ответы на другие мои вопросы, желательно отвечать поконкретнее.

Это характеризует твой уровень внутренней дисциплины. Впрочем, это не моя проблема.

Нет это не характеризует мой внутренний уровень дисциплины. Здесь я никому ничего не должен и поэтому у меня нет времени и желания все досконально проверять. Ты вед сам на форуме тоже не идентичные примеры привел, что означает то что ты на форуме тоже не доскональна все обдумываешь и проверяешь.

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

> Фортран ничем не лучше С для числодробилок. Есть мнение что уже даже хуже, причем только одним — ценой.

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

Кстати, для тех кто считает, что Фортран умер - на суперЭВМ доля Фортран приложений значительно превосходит долю Си и Си++ приложений вместе взятых.

Есть мнение, что широкое использование указателей в Си и Си++ мешает генерить более эффективный код. Как одна из причин, почему фортран быстрее.

> Есть мнение, что широкое использование указателей в Си и Си++ мешает генерить более эффективный код. Как одна из причин, почему фортран быстрее.

Абсолютно!

>А что, Plan9 затачивался под конкретную архитектуру?

Это показатель уровня разработчика. Вижу в теме полно любителей «а вам слабо пробежать 300 метров с бутылкой зажатой между коленями при этом с завязанными глазами и по минному полю», си таких привлекает своими колючками. Прикинь, есть люди которые могут, но им в лом и предпочитают обходить гору а не переть в нее несмотря на спортивный разряд по альпинизму. Потому что умные, а умный человек никогда не будет нагружать себя лишней работой, особенно если ее можно поручить компьютеру.

офигеть, я прочитал этот тред!

По теме. Разочарован, что нет исключений. Как-то вот уже привык к ним, что в с++, что в жаве, что в перле. panic и resume как-то вот не вдохновляют. := раздражает. Порадовало наличие func, несколько непривычна нотация типов переменных после >20 лет знакомства с Си. Слабая практическая полезность пока, так что ничего не могу серьёзного написать, чтобы оценить насколько всё хорошо или плохо. Фактически, если не считать синтаксических моментов, основные моменты языка, типа каналов и потоков выполнения довольно просто переносятся на С++. А вообще, это просто пока макропроцессо для Си, я так понимаю.

Внутренняя дисциплина как раз и проявляется тогда, когда ты никому ничего не должен. Только самому себе. DIXI.

не идентичные примеры

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

И жду ответы на другие мои вопросы, желательно отвечать поконкретнее.

Ну ты и зануда :) Список вопросов в студию, а то самому парсить твои сообщения слишком лениво.

Так еще короче:))

Странное у вас «короче».

#include <iostream>
int main()
{
  std::cout << 5 << std::endl;
  return 0;
}

И специально для С-хакеров:

#include <stdio.h>
#include <string.h>
#define S "5\n"
int main()
{
  return 1 - (printf(S) == strlen(S));
}

>> С/С++ - уникальный язык

Это два разных языка.

Не совсем. Можно сказать, что есть язык C, а есть C/C++. Сам C++ - это надстройка над C. Да, это очень удобная надстройка, имеющая много плюшек, но это не самостоятельный язык. C++ - это удобный способ организации кода в собственной программе.

Для взаимодействия с другими программами и библиотеками часто приходится использовать конструкции чистого C, ведь std::string не передашь параметром в функцию recv(), и std::vector не запишешь в порт контроллеру.

> Для взаимодействия с другими программами и библиотеками часто приходится использовать конструкции чистого C, ведь std::string не передашь параметром в функцию recv(), и std::vector не запишешь в порт контроллеру.

Да, бардак есть. Постоянно приходится делать обвязки, чтобы привести API к истинно плюсовому виду, после которого уже можно пользоваться. А можно попробовать QtCore. Полный атас, это, конечно, отлаживать программу с использованием STL. Как пройтись в gdb нормально по std::list для меня не совсем ясно. Особенно, если колупаешь уже мёртвый core dump. Так что о «Си внутри Си++» можно говорить с некоторой натяжкой. Многие вещи, всё-таки, правильнее было сделать несколько переделав язык.

> Странное у вас «короче». ... int main()

С++ допускает объявление void main(), насколько я помню. Си не допускает.

>С/С++ - уникальный язык. Другие языки - лишь небольшая часть огромных возможностей С++.

И вновь и вновь, в аналитики ЛОР'а претендует школота не на писавшая на С++ более, чем лабы.

> И фортран и си для числодробилок, языки абсолютно одного класса.

Да, да, матрицы там особенно одинаковые.

Вот ведь бида: это всё равно слишком многословно!

#!/usr/bin/env python
print 5

Да, да, матрицы там особенно одинаковые.

Одного класса не значит одинаковые, а значит требующие примерно одного и того же затрата времени и знаний на написание чего-либо.

П.С.: разница между A(i,j) и a[i+j*vdim] не велика

Ага, в Си надо понимать что такое указатели. Кстати, там часто выделяют память ещё и по рядам или столбцам, а вовсе не как у вас.

Ага, в Си надо понимать что такое указатели.

А в фортране без глобальных переменных почти не обойтись.

Кстати, там часто выделяют память ещё и по рядам или столбцам, а вовсе не как у вас.

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

Вообще аргумент «чтобы писать на си, надо чуть больше знать о компе» очень странен. Все равно надо понимать что, да как, когда будешь профайлить прогу.

Если нужен более легко-обучаемый язык или критична скорость написания, то все равно выберут МАТЛАБ или что-то вроде numpy.

> Все равно надо понимать что, да как, когда будешь профайлить прогу.

Если профайлить, то да, но в Си надо понимать и чтобы оно заработало.

А вот как разработчик компилятора своего «чудо языка» стопудово видел ассемблер.

Видел интерпртатор пролога, написанного на лиспе, написанного на форте. Читал про форт на лиспе. Gcc вроде как на плюсах. А вообще сейчас пишут компиляторы на асме?

Если профайлить, то да, но в Си надо понимать и чтобы оно заработало.

Какой смысл писать на фортране или си если не критична скорость? Научиться писать на си на достаточном для числодробилок уровне совсем не долго. В любой книги по си есть замечание (иногда глава) о связи указателей и массивов, а в практических книги по числам есть рекомендация не использовать array[][].

Фортран 77 вообще убог страшно. 90, 95 стандарт уже покрывает 95% необходимостей. Но опять же как я уже говорил сейчас все упирается в нетехнические детали — компилятор си будет дешевле (возможно более качественным, хотя это конечно далеко не факт), просто потому что он нужен большему кол-ву людей.

Это как с математическими сопроцессорами. Выпускали их для университетов. Нужно это было в малом количестве, стоили они до фига. А появились мощные видяхи для игр, ученые сразу получили все что им надо и при этом на порядок дешевле.

> Фортран 77 вообще убог страшно.

Деталями не поделитесь? Чем конкретно для Вас убог Фортран 77?

Деталями не поделитесь? Чем конкретно для Вас убог Фортран 77?

Невозможность избежать использования глобальных common blocks, неудобство работы с массивами, длина которых определяется в рантайме, идиотская (имхо) система ввода вывода, основанная на ссылках.

Плюс ко всему если не пользоваться расширениями, то в стандарте 77 прописано, что все должно писаться заглавными буквами и при этом длина названия переменных и функций должна быть не более 6-ти букв.

Ах да, забыл. Еще фортран-77 (без расширений) рекурсии не поддерживает.

При этом я не говорю, что Фортран не подходит для числодробилок, У Си как числодробилки тоже есть недостатки (например, в си-89 нету комплексных чисел). Фортран и си одного поля ягоды, выбор фортрана вместо си ничем кроме религией не подкреплен, а выбор си может быть подкреплен экономией бакса.

Понятно. Спасибо! Боюсь тогда разговора не получится.

Невозможность избежать использования глобальных common blocks

Проблемы «избегания» common block вообще говоря нет. В любом серъёзном языке программирования так или иначе решается проблема объявления глобальных переменных. Что, говорить «static» на много удобнее, чем говорить «COMMON»?

неудобство работы с массивами, длина которых определяется в рантайме

Это не к 77, а к 90. Если мне не изменяет память, фортран 77 не допускает динамических массивов (и это хорошо). Хотя, могу ошибаться. Впрочем, в чём же принципиальная разницы работы со статическими и динимическими массивами в Фортране?

идиотская (имхо) система ввода вывода, основанная на ссылках.

Знаете принципиально иную систему ввода-вывода?

Плюс ко всему если не пользоваться расширениями, то в стандарте 77 прописано, что все должно писаться заглавными буквами и при этом длина названия переменных и функций должна быть не более 6-ти букв.

Это вообще замечание несеръёзное. Документируйте программу, чаще пользуйтесь подпрограммами, чаще пользуйтесь локальными переменными.

Я ещё мог бы подумать, что вы будете жаловаться на неясность в использовании unnamed common block, сложность отладки multy-entry функций, отсутствие рекурсии, отсутствие проверки соответствия типов при вызове функций, неоднозначность объявлений и умолчания. А так всё это НЕСЕРЬЁЗНО. Вы ещё про 72 символа в строке и отступ на 6 вспомните...

> Вы ещё про 72 символа в строке и отступ на 6 вспомните...

А отступ на 6 меня вообще убил. Дальше этого я книжку по фортрану просто не смог читать ;)

> А отступ на 6 меня вообще убил. Дальше этого я книжку по фортрану просто не смог читать ;)

Наверное не следует человеку с профилем «Linux admin, C/C++/Perl programmer, Oracle DBA, Oracle programmer, Informix programmer.» пытаться обсуждать детали Фортрана. Я вот стараюсь воздерживаться от комментарииев в теме, где обсуждают базы данных.

Проблемы «избегания» common block вообще говоря нет. В любом серъёзном языке программирования так или иначе решается проблема объявления глобальных переменных. Что, говорить «static» на много удобнее, чем говорить «COMMON»?

В си можно не использовать глобальные переменные совсем. В фортране нет. В фортране-77 нету локальных структур вообще.

Если мне не изменяет память, фортран 77 не допускает динамических массивов (и это хорошо)

Чего хорошего? (Значит я пользовался расширением.)

Про ио, неясно выразился. Имел в виду лэйблы. И опять же я согласен, что это относиться к «несерьезному».

Это вообще замечание несеръёзное.

С одной стороны да, а с другой стороны ориентироваться в кучу CGERU, SMPTU и так далее чертовски сложно, даже при наличии хорошо написанной документации.

Про рекурсии уже написал выше. Умолчания известное зло, опять же IMPLICIT NONE спасает.

Хорошо, зайдем с другой стороны. А почему ты выбрал фортран а не си? Для меня что си, что фортран равнозначны как числодробилки. Использовать первый предпочтительнее по нетехническим причинам, а которых я уже писал выше.

> Хорошо, зайдем с другой стороны. А почему ты выбрал фортран а не си? Для меня что си, что фортран равнозначны как числодробилки. Использовать первый предпочтительнее по нетехническим причинам, а которых я уже писал выше.

Отвечу кратко, а на остальное - попозже.

Есть одно преимущество Фортрана, которое бъёт все его недостатки и преимущества С для численных задач: однозначность написания цикла DO, и посему возможность построения теории автоматической векторизации. Для кодов с корнями в 70-х, это чрезвычайно важно.

Как уже писалось выше, Фортран программа чаще всего быстрее чем её С эквивалент. В вычислениях, где 2% выигрыша оборачиваются тысячами сэкономленного машинного времени, это куда важнее, чем экстра 200 долларов за лицензию. Кстати, на некоторых вычислительных системах стоимость компилятора входит в стоимость ЭВМ.

> Наверное не следует человеку с профилем ...

У меня много чего не упомянуто в профиле. Например, что первые несколько курсов пришлось писать на Алгол-68... ;)

Вот, знаешь. Полазил по инету. И примерно составил такой вывод. Никто не гарантирует, что фортран даст тебе прирост в производительности (даже 2%). Все чертовски зависит от компилятора, хотя в среднем фортран выигрывает (до 20% в некоторых тестах). Ф77 активно признается ужасным языком, если надо что-то чего нету «в коробке» (типа структур и т.д.). Обсуждение «удобство написания» против «быстрота» тема весьма активного холивара. :)

Р.S. 200 баксами не обойдешься (разве что себе на машину). Если разговор о кластере то тут затраты будут на порядок выше.

> Обсуждение «удобство написания» против «быстрота»

Ни быстрота ни удобство написания никогда не будут сколь угодно значимыми факторами в вычислительном программировании. Лучшее место на сегодняшний день для обсуждения вопросов вычислительных языков будущего, наверное, Exascale Initiative при DOE.

Все чертовски зависит от компилятора

Вы не поверите, но всё на самом деле чертовски зависит от программиста, и его знания алгоритма, компилятора, архитектуры, и перспектив на будущее.

> Ф77 активно признается ужасным языком

У меня тоже есть притензии к этому языку, но вот беда, когда начинаешь разговор, в ответ слышишь только лишь «72 символа, отступ 6, и common».

Вы не думаете, что все проблемы людей, ругающих Фортран 77, обычно сводятся к попытке его использования там, где он не предназначен. Ну какие ещё структуры в вычислительном алгоритме? Вам нужно вычислить интеграл или перемножить две матрицы или решить дифуру. Зачем Вам структуры?

> Зачем Вам структуры?

Их и в Фортране90 нет? Просто любопытствую.

> Их и в Фортране90 нет? Просто любопытствую.

Есть, к сожалению...

> В си можно не использовать глобальные переменные совсем. В фортране нет. В фортране-77 нету локальных структур вообще.

Цитата из стандарта: «The variables used in a subprogram, other than its arguments, are local variables, defined only within it, and therefore distinct from any identically named variables used elsewhere.»

Пример использования. В программе ниже переменные i, N, s являются локальными.

program test implicit none real(8) A(10), B

call Initialization( 10, A ) call Summation( 10, A, B )

print *,'Sum = ', B

stop end

subroutine Initialization( N, V ) implicit none integer i, N real(8) V(N)

do i = 1, N V(i) = DBLE( i ) enddo

return end

subroutine Summation( N, V, s ) implicit none integer i, N real(8) V(N), s

s = 0d0 do i = 1, N s = s + V(i) enddo

return end

>> Если мне не изменяет память, фортран 77 не допускает динамических массивов (и это хорошо)

Чего хорошего? (Значит я пользовался расширением.)

А хорошо то, что размеры всех массивов известны во время компиляции, а значит можно лучше провести оптимизацию.

> Про ио, неясно выразился. Имел в виду лэйблы.

Оператор безусловного перехода на именованый оператор (или метку) существует во всех практических языках программирования. И хотя многим не нравится, но и лучшего не придумали. Многие алгоритмы можно записать без использования меток и переходов.

> ориентироваться в кучу CGERU, SMPTU и так далее чертовски сложно,

Во-первых, можно добавить ещё один символ (шучу),

во-вторых, стандарт не запрещает использовать цифры, что значительно повышает разнообразие идентификаторов,

и в-третьих, стандарт определяет контекст для переменных. Переменные разных контекстов могут иметь одинаковые имена. Это создаёт программисту много неожиданностей (шучу).

Я полностью согласен с Вами в этом пункте. Ограничение в 6 символов - искусственное на сегодняшний день осложнение. Справедливости ради следует заметить, что большинство компиляторов не соблюдают это ограничение (лишь различают идентификаторы по первым 6 символам).

Ну какие ещё структуры в вычислительном алгоритме? Вам нужно вычислить интеграл или перемножить две матрицы или решить дифуру. Зачем Вам структуры?

Хорошо, представь реализацию в Ф77 разреженных н-мерных матриц, кол-во элементов в которых зависит от входных данных, а вычисление элементов матрицы достаточно трудозатратная часть программы? И потом это все еще и использовать надо будет. Будешь использовать все тот же common (и параметр maxnumel что не дает гарантию хорошего использования памяти) , а это грубо говоря та же структура только глобальная. Если тебе не нужны структуры, попробуй вообще не использовать common в программе, а ограничься только глобальными переменными. При ограничении только 6 символов на название переменной, представляешь во что превратиться твой код и как тебе его предстоит расширять.

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

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

Вы не думаете, что все проблемы людей, ругающих Фортран 77, обычно сводятся к попытке его использования там, где он не предназначен.

Одназначно. Только уже все меньше и меньше областей, где он применяется. Даже в науке он все больше сдает позиции, заменяясь на что-то более высокоуровневое.

:)

Да, погорячился. Имел в виду более сложные программы. Возьми к примеру библиотеку quad написанную на фортране. Как ты собираешься передавать параметры интегрируемой функции, кроме как через коммон или глобальными?

> Хорошо, зайдем с другой стороны. А почему ты выбрал фортран а не си? Для меня что си, что фортран равнозначны как числодробилки. Использовать первый предпочтительнее по нетехническим причинам, а которых я уже писал выше.

Дело в том, что в моём окружении цена компилятора тоже не является сколько-нибудь значимым фактором, и посему этих нетехнических причин нет. Вообще говоря, люди выбирают Фортран тогда, когда 1) пишут новое на основе старого Фортран-кода, 2) думают о производительности и долговечности кода, 3) работают в большом коллективе разработчиков с разным уровнем программирования. Люди выбирают С (или С++), когда они 1) ограничены во времени и пишут прототип - демо, 2) работают в одиночку, 3) не думают о долгой поддержке. Это исключительно моё наблюдениие большого количества вычислительных проектов, и я не говорю, что любая Фортран программа по-определению проживёт 25 лет, тогда как С программа - студенческий диплом просто потому, что на С.

А хорошо то, что размеры всех массивов известны во время компиляции, а значит можно лучше провести оптимизацию.

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

>> Ну какие ещё структуры в вычислительном алгоритме? Вам нужно вычислить интеграл или перемножить две матрицы или решить дифуру. Зачем Вам структуры?

Хорошо, представь реализацию в Ф77 разреженных н-мерных матриц, кол-во элементов в которых зависит от входных данных, а вычисление элементов матрицы достаточно трудозатратная часть программы?

Уважаемый ogronom. При всём моём к Вам уважении, мне кажется Вы не очень хорошо знакомы с Фортраном, раз задаёте такой вопрос. Конечно, я могу отослать Вас к коду, скажем, NWchem, или GAMESS, где 7-мерные массивы прекрасно уживаются с очень внимательным использованием памяти (хорошо, согласен, части NWChem уже используют ALLOCATE).

Будешь использовать все тот же common (и параметр maxnumel что не дает гарантию хорошего использования памяти) , а это грубо говоря та же структура только глобальная.

Это не структура. Это определение глобальной области данных, и это правильно, поскольку 1) определено один раз, 2) доступно, если подключено, 3) структурировано.

Если тебе не нужны структуры, попробуй вообще не использовать common в программе, а ограничься только глобальными переменными.

Вы путаетесь. В Фортране глобальные переменные задаются только с помощью COMMON блока. Структурой в Фортран обычно называют пользовательский тип данных.

При ограничении только 6 символов на название переменной, представляешь во что превратиться твой код и как тебе его предстоит расширять.

Я уже ответил (правда с долей шутки), как в Фортране решается эта проблема. Сейчас не шучу - решается стрктурированием, определением контекста и документированием.

> Возьми к примеру библиотеку quad написанную на фортране. Как ты собираешься передавать параметры интегрируемой функции, кроме как через коммон или глобальными?

Чем библиотека quad отличается от любой другой, где аргументы функции передаются как dummy variables?