Почему Java так похож на С++?

Можно реализовывать несколько интерфейсов.

это не множественное наследование

Множественное наследование реализаций тривиально реализуется через делегирование.

например? не помню такой возможности.

ну под ЛСД и мальчики на девочек похожи, так чтооо...

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

функция освобождения памяти (в некотором смысле деструктор).

задачи деструктора не сводятся к освобождению памяти

Да тоже похожи, хотя и не так сильно. Вот Piet тот не похож.

задачи деструктора не сводятся к освобождению памяти

Формально может и нет.

А физически именно это и происходит.

А что делают ваши деструкторы?

это не множественное наследование

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

например? не помню такой возможности.

возможности чего? вызвать метод? паттерн delegate посмотри.

мешает в тех случаях, когда ёмкости знакового хватает, а беззнакового — нет.

Ещё раз. Что мешает использовать знаковые числа в качестве беззнаковых? Ровно с той же ёмкостью в 16/32/64 бита?

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

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

1) finalize — потенциально опасная конструкция? круто, что.

конкретно finalize в java присутствует.

сборщик мусора на джаве не умеет освобождать память, выделяемую С-функциями

lol, а должен?

дают нечитабельное нечто

проблема архитектуры приложения. сама по себе ява многословна, но вполне понятна. с-модули должны аккуратно выноситься и обвёртываться.

проще сразу было написать на плюсах

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

конкретно для OpenCL уже есть обвёртка - jocl. я про частный случай ускорения критических участков.

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

конкретно для OpenCL уже есть обвёртка - jocl

Вот сидел и ждал именно этой фразы.

А скажите пожалуйста, не иcпользует ли эта, как вы выразились «обёртка» тот самый JNI?

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

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

Никогда не программируй больше, ламер.

lol, а должен?

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

с-модули должны аккуратно выноситься и обвёртываться.

на практике это «аккуратно» сводится к тому, что сама программа пишется на, а на явке — только морда.

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

до сих пор не встречал ни разу ни одного опенсорсного нечитабельного приложения на плюсах.

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

интерфейсы уже научились содержать в себе не только методы, но и данные?

возможности чего? вызвать метод? паттерн delegate посмотри.

причём тут паттерн delegate и множественное наследование? //сперва решил, что речь про шарповские делегаты

специально, чтобы прикинуться С++. также, как С++ специально похож на С, чтобы им прикинуться. также, как С похож на BCPL.

Но да, ООП везде одинаковое

нет, оно везде разное: CLOS/MOP, io/JavaScript/Self, Eiffel, Component Pascal/Modula-2/Oberon-2,Linux kernel insmod, Simula67/C++/Java/C#/D/.../Swift/Python, SmallTalk/ObjectiveC/..., Delphi (рефлексия между классами, а не объектами класса), Go, Rust, и т.п.

динамическая/статическая типизация, одиночная/множественная диспетчеризация, first class object и метаклассы либо FBC, делегирование и прокси-объекты и категории и протоколы в objC, прототипное ООП, метаклассы, метаобъектный протокол, тайпинфо, трейты, миксины и рефлексия

интерфейсы уже научились содержать в себе не только методы, но и данные?

Данные это закрытая деталь реализации. При наследовании значение имеют только методы.

interface I1 {
  void f1();
}
interface I2 {
  void f2();
}
class C1 implements I1 { ... }
class C2 implements I2 { ... }
class D implements I1, I2 {
  private C1 c1;
  private C2 c2;
  public void f1() { return c1.f1(); }
  public void f2() { return c2.f2(); }
}

вот пример множественного наследования.

Данные это закрытая деталь реализации.

с чего бы? а если я их публичными сделать хочу?

Чем они похожи? Ключевые слова одни и те же? Так это незначительные мелочи. В C++ первый и второй плюсы — RAII, чего в Java вообще никак нет. Одного этого достаточно, чтобы не валить их в одну кучу, а там ещё вагон и маленькая тележка отличий разного калибра.

с чего бы? а если я их публичными сделать хочу?

Значит ты нарушаешь все мылимые и немыслимые рекомендации. Делай геттер-сеттер в интерфейсе.

Значит ты нарушаешь все мылимые и немыслимые рекомендации.

я пишу код так, как необходимо в конкретной ситуации, а не так, как в каком-нибудь Коране написано

Делай геттер-сеттер в интерфейсе.

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

Делай геттер-сеттер в интерфейсе.

кстати, ещё один пример ущербности явы. в С++ если мне из переменной потребуется сделать метод, я воспользуюсь перегруженными операторами приведения к типу, в С# — встроенной концепцией геттеров и сеттеров. в Java на уровне языка задача прозрачного изменения переменной на метод не решаема, поэтому мы руководствуемся ущербной логикой в виде «рекомендаций».

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

наконец, в яве нет инлайн-ф-ций, поэтому геттеры-сеттеры на каждый чих втройне идиотизм

Данные это закрытая деталь реализации. При наследовании значение имеют только методы

А ты молодец!

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

писать нормально на связке жабы и си

а мешает?

на практике

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

динамическая/статическая типизация, одиночная/множественная диспетчеризация, first class object и метаклассы

Это нюансы. ООП одинаковое. Само понятие ООП не зависит от нюансов реализации.
Мне, сишнику(скорее даже плюсовику), даже в ПХПшный код приходилось залазить. Да, работа с памятью странная. Так она и в Жабе странная. Но ничего. Справлялись. Идея аналогичная.
Но сама идея — ООПшная.

Сам себе пишешь? ;)

Софт на жабе тормозит весь, а на крестах только если он на Qt.

а что, софт на Qt тормозит? я-то не в курсе, мне реально интересно

Классная мамка у тебя в руках! Мне какраз такая нужна! Продаёшь? ;)

нет, стоит в работе уже полгода
и да, стоит она недешево

та ладно... какая-то супермикро на два ксеона 2011 ну доларов 700 максимум

стоит она недешево

оговорился. Имел ввиду итоговую систему. И недешево - это по моим собственным меркам.

супермикро

верно

на два ксеона 2011

два опетрона g34

А почему рптероны?

Они вроде совсем устарели?

Или таки поддерживают ЕЦЦ?

Хотя может я спутал с Семпронами

А почему рптероны?
Они вроде совсем устарели?
Или таки поддерживают ЕЦЦ?

ну ты даешь!
хоть загуглил бы что-ли
http://www.amd.com/ru-ru/products/server/opteron/6000/6300

Говорил ведь выше - спутал с Семпронами... прошу прощения.

Говорил ведь выше - спутал с Семпронами... прошу прощения.

не за что
всё нормально... бывает :)

Спасибо :)

Я хочу спросить по вашему хардваре, но чувствую выходит за рамки топика...

мыло в профиле

Спасибо за разрешение.

Да, относительно софта на GTK. А на глаз может не быть заметно, если топовое железо, ну или сам юзер неторпоплив, например.

Данные это закрытая деталь реализации. При наследовании значение имеют только методы.

Из-за этого меня страшно бесит широкая мода последнего времени в ORM'а на разных платформах обеспечивать доступ к данным через свойства, а не через методы. Чуть что менять — так начинается зоопарк со всякими геттерами/сеттерами.