|
c127
%26gt;Переменная может быть примитивной или указывать на объект
Так указателей же нет. Только не нужно говорить, что это не указатель "в понимании C". Указатель как свежесть у мяса, имеет 2 состояния или он есть, или его нет, никакого особого "понимания" у него нет.
Это не конструктивно.
Существует понятие "указатель", "указывать" в обычном смысле, как мы его используем в русском языке.
"Указатель в Си" - это указатель на адрес памяти и он сам по себе является типом данных. Над ним можно проводить кучу разных операций, не относящихся к куску памяти на который он указывает.
В java не примитивные переменные предоставляют доступ к объекту. Механизм доступа в точности соответствует понятию "указывать на что-то" в русском языке, а не языке Си.
У меня никаких проблем с пониманием нет.
Чепуха, уже надоело объяснять почему. К физическим ячейкам никто не обращается.
Опять игра слов.
"модель виртуальной памяти в java" - ограничение на кол-во объектов
"физическая память" - железо. Адресация ячеек на уровне контроллера памяти
"модель физической памяти в Cи" - эмуляция "физической памяти", т.е. ячеек, адресов на них указывающих etc.
Я сравнивал искючительно 1 и 3 пункты. Объяснять в чйм разница между 2 и 3 мне надо. И про "виртуальную память", которой OS скрывает "физическую память" тоже.
И это чушь. char - 1 байт, short - 2 байта, long - 4 байта. Только int зависит от реализации. Это стандарт, более того, на этом строится идея переносимого языка (см. Керниган, Ричи, самое начало). Похоже выяснился источник проблем.
Это источник не моих проблем, а того, кто пишет на этом языке.
Если специальным образом не обрабатывать int, то при использовании разных реализаций компилятора могут быть возникать ошибки. Разве нет?
Естественно это не неустранимая проблема, зато сколько можно получить "удовольствия" от поиска причины бага в многокилометровом чужом коде.
Или я чего-то не понял, или это какой-то бред. Извините. Почему printf() это болезнь, а System.out.println() это шаг вперед?
Болезнь не оператор, а стиль программирования, оператор симптом, - я так писал. printf ничем не хуже sout с точки зрения функциональности, даже получше, только он выпадает из общей "красивой картинки" предрасполагая к иному стилю мышления.
С точки зрения ООП (в мой интерпретации :)), метод это действие совершаемое над объектом, если есть метод, но не указан объект - это уход в сторону. Вот и всй.
Пожалуйста, пишите printf, при не обходимости можно всегда в уме приписать к кому объекту это действие относится.
Ну вроде совсем прозрачно осветил свою точку зрения.
Почему по strcpy() нужно читать маны, а по System.out.println() нет?
Не нравятся маны - читайте книги.
Это вопрос простоты языка для понимания/изучения.
Простой пример:
Как мне догадаться, что мне нужна функция atof(), что сделать из строки число? Придйтся порыться прежде, чем найти. Не важно где, в книгах, гугле, манах или спросить на форуме.
А в java? Что хотим получить? Число. Из чего? Из строки.
Пробегаем по методам класса String - не видим названия в котором есть что-то похожее на convert.
Пробегаем по классу Integer - вот он - Integer.parseInt(String s);
Тут же видим полное описание метода, какие exception'ы он может кидать и т.д. Даже посмотреть его реализацию для уточнения любых вопросов, которые могут возникнуть.
Пока досканально не выучишь библиотеки, теряется время.
Вопрос: на что потребуется больше потратить времени на изучение бибилотек java или с?
Вот и всй, что я имел в виду...
По джаве (и библиотекам) их написано не намного меньше чем по C/C++, но за гораздо более короткое время. Зачем, спрашивается, кто их покупает, платит бабки, если и так все понятно?
А если подумать?
Вышла новая спецификая jdk, вышла новая серия книг отличающихся от старых обзором добавлений в новой версии.
По сути эти книги простое переписывание java doc'ов(толстые книги) и перевода текущего туторила постоянно доступного на сайте java(по тоньше).
Сюда же можно отнести "книги" для студентов по курсам лекций и т.п. Их не много.
Другой класс книг "по java" - это описания технологий программирования с примерами на java. Это книги по использованию Uml, классич.алгоритмам, паттернам, антипаттеры, XP, рефакторинг, серверная архитектура и т.п. Но это не книги по языку, там не учат, что такое java, там излагают идеи равноприменительные к любому ООП языку. Таких книг для Java действительно больше, чем для C/C++.
Не возникло идеи почему? :)
И отдельно стоит небольшая книжечка с описание антипатернов связанных с "неправильным" использованием библиотек java. Где простым и доходчивым языком говорится о том, почему не надо делать много лишних объектов, почему использование StringBuffer иногда оказывается на порядок эффективнее чем String и т.п. проблемок.
Не вижу аргумента. Вы же только что признали, что и на джаве можно написать программы, которые не будет работать везде ("В случае java любые готовые стороннии библиотеки будут готовы к использованию без каких либо изменений, если обратное не оговорено заранее"), да это и так очевидно.
Использование native кода в джава приложение делает его не преносимым, поскольку native код написанный на том же С++ будет не переносим. Ограничение на переносимость лежит в native коде, а не java коде.
Отсюда следует:
- не используйте native код и приложение будет переносимо полностью.
- проще перенести не большой по объему native код на новую платформу (или переписать сохранив функциональность), чем переносить приложение целиком написанное на native языке.
И кто предстайт в более выгодном свете Си или Java, учитывая, что native код используется крайне редко? Единственное обоснование для его использования написать приложение именно под одно платформу, либо уже есть native код который долго переписывать и на это нет средств, но в последнем случе хуже не станет.
Хотя "жалко", кончено, что чтение реестра непоулчится организовать в linux'е... Действительно, ЭТОТ факт я признал.
Вот по Вашей логике получается: "После этого только и говорить о переносимости :)" джавы.
Что бы получилось по моей логике, нужен пример, парочки jre, которые одну и туже спецификацию java понимают по разному. Но о таких я не слышал.
Причйм примеры, о которых я писал, иллюстировали различную трактовку синтаксиса языка, а не различия в реализации стандартных библиотек, что тоже могло бы приводить к разным результатам работы программы.
Смешно. То же самое слово в слово говорилось 4.5 года назад. Придумали бы что-нибудь новое.
А что смешного? Это факт, зачем что-то придумывать?
Да медленее, но не намного.
Да больше, но сравнивать тоже надо правильно. Выдели 64 - есть вероятность что приложение съет всю, выдели 128 той же программе - опять съест, а почему нет? :) Мусор можно дольше не убирать. Ну пусть даже просто больше.
И что?
Простоту языка и удобство работы купили за счйт железа.
Есть области, где требуется написание программ критичных к скорости, там нет смысла использовать java, но ещй больше областей, где разница небольшая разница в скорости не критична.
Через год-два этих областей станет ещй больше - время отклика 1ms или 2ms велика проблема?
1) Это тестирование отличается от других тем, что там набрана статистика. Врядли нам удастся повторить этот момент, а без статистики тест не будет серьезным.
2) Скорость исполнения почти никогда роли не играет. А вот длина кода и особенно скорость разработки (а они связаны, это известный факт, и об этом, кстати, в отчете тоже написано, нужно только почитать внимательнее) играют большую роль. Если верить тестам, да и Вы вроде не спорите, только называете этот параметр сомнительным, то по размеру кода, а следовательно по скорости разработки, джава тоже в пролете.
1) Если речь идйт о статистики в смысле кол-ва вариантов программ, то это и так не серьйзно. Она определяет уровень "квалификации" программиста пишущего на языке - а не специфику языка. Хотя информация конечно, любопытная.
2) Я внимательно читал :) в том числе и оригинал. Для данной задачи скорость написания кода на Cи и Java должна быть одинакова. Сложность задачи исключительно алгоритмическая - какую структуру данных выбрать для хранения слов, понять как она должна работать, как осуществить перебор вариантов.
Их пример с 69 часами - просто прелесть.
Автор сам говорит, что примеров кода на С/C++ очень мало.
Если отбросить варианты отнявшие > 20ч, что говорит о трудности понимания, что же надо написать, то среднее время получится одинаковым, как я и говорю.
С длинной программ лидерства тоже быть не может ни у одного из этих языков при решении предложенной задачи.
Операторы языков очень похожи и для данной задачи нельзя было использовать подходящую библиотеку (нет 10нарного дерева в библиотеках ни того ни другого языка :)). В результате так и получилось, среднее кол-во строк одинаково.
На графиках (5 и 6) всё это видно.
В заключение. Все Ваши существенные аргументы относятся не к сравнению языков программирования, а к сравненнию окружения. У джавы есть виртуальная машина, у С/С++ ее нет. Так я с этим и не спорю.
java можно с натягом рассматривать как синтаксически урезанный Си++, с очень хорошим набором библиотек, сделать который удалось за счёт полного пересмотра базовых библиотек, хороших внешних библиотек (во многом благодоря кроссплатформенности) и активной пропоганды "передовых" концепций в замен старых добрых методов по 1000 строк.
Я сразу сказал, что можно было создать виртуальную машину для C/C++, а не выдумывать новый язык в угоду недоучившейся публике. И C/C++ совершенно спокойно мог бы использоваться абсолютно везде, где сейчас используется джава.
Ага, а я сразу же сказал, чем эта идея хуже, чем сделать новый язык.
"Лишнии" языковые конструкции, груз старых библиотек, костность мышления, которая заставляет старых Сшников писать на С++ как будто никаких ++ там нет.
--
А какой смысл сравнивать языки сами по себе, абстрагировавшись от библиотек и прочего?
Ясно, что java большое упрощение, всё расчитано на "чистый" ООП. Ни каких структур, записей, адресов в памяти, всего что упрощает написание кода "сплошняком". Только классы, интерфейсы, методы, набор ключевых слов для организации доступа, несколько примитивных типов.
Код java можно тупо превратить в код Си заменой ключевых слов (забудем про разницу в библиотеках и ключевое слово synchronize). Обратно тяжелее.
Выводы
- Си++ сложнее для изучения, чем Java.
(В итоге это не принципиально.)
- ОО Модель в Си++ шире, чем в Java. Множественное наследование, делгация методов, передача параметров, переопределение операторов, еtc
(Это позволяет как минимум строить "сложные" конструкции объектов и такие же связи между ними. Что лучше вылавливать в них потом ошибки или не усложнять код ровном месте - трудно сказать.)
- в Cи++ много "хаков" экономящих строчки при написании кода.
(требует достаточно большого опыта работы с языком, зато код компактнее,
главное только потом не забыть, что же он делает)
В java что-то похожее появилось в версии 1.5 (пока бета) например foreach, автоматическая обвёртка примитивных типов при добавлении в коллекции и т.п.
- В Си++ можно писать код "по-старинки", как на С.
(С одной стороны хорошо, с другой плохо. Плохо, потому что грамотно написать ОО код, который легко править, отлаживать, документировать и т.д. проще, чем написать такой же по этим параметрам код без ОО подхода (хотя и возмжно:)) Хорошо, потому что простые программы пишутся быстрее, сохраняется связь со старым кодом(?), старые добрые классич.алгоритмы существуют именно в таком виде, т.е. их легче реализовывать. )
- В с++ есть указатели и связанные с этим возможности и сложности, есть необходимость следить за удалением объектов, есть проблемы аналогичные memory leak's в java, но в меньшей степени.
Следствия:
- Читать чужой код на Си++ тяжелее, чем чужой java код, т.к. java простая до безобразия, т.е. приходится меньше фич языка держать в голове.
- В С++ больше вариантов для принятия решения - "можно так, можно этак, а что лучше, а почему, а какой ситуации и т.д." - для того, чтобы делать это эффективно, нужен баальшой опыт, намного больше, чем java юзера. (о "намного" сужу по своему опыту, может просто дурак?)
- Скорость написания кода одинакова, если пишем ОО, и C выигрывает, если "положить", на все эти объекты и писать в "столбик", т.к. не надо тратить время на выделение сущностей, связей и т.д.
Но в целом, эти различия не значительны для опытных программистов.
Разница только в скорости работы (выигрывает Си++), способе достижения переносимости (выигрывает java) и доступных библиотеках(java). Если библиотека хороша и удобна, код будет написан быстрее, чем если её совсем нет или организованна она через одно место. В области написания серверных приложений Java молодца, т.к. за этим процессом следят, существуют контейнеры для серверных приложений, фреймворки для этих контейнров и куча куча всего, что упрощающая работу не связанную с логикой приложения.
На клиентской стороне такого подавляющего преимущества нет. Разве что swing не плох :) Боятся пока писать серьёзные приложения в большом кол-ве.
Хотя пишут. Пример, той же самой IDE IntelleJIdea. Но пока ещё рановато...
Вот станут процессоры ещё на 1 Ггц побыстрее, добавят юзеры памяти чуть побольше и полетим с оpenGL'кими swing'aми вперёд :)
|
