C++ & Java / C++ - ReSQL.ru

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / C++ [игнор отключен] [закрыт для гостей] / C++ & Java

25 сообщений из 160, страница 6 из 7

все

C++ & Java

#32857443

Сергей Ильич

Участник

Откуда: Из Питера

Сообщения: 385

Рейтинг: 0 / 0

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

Там, кстати, нет уборки мусора, но управление памятью там сделано более по уму.

У OCaml'а ЕСТЬ сборка мусора. Безо всяких "более по уму".

Библиотека fftw (FaStest FOurier Transform in the West) была написана не НА ML, а С ПОМОЩЬЮ ML (точнее, OCaml), который использовался для генерации специализированного исходного кода.

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

awson
Мне кажется, "ранний" C++ (до появления современной трактовки шаблонов как инструментов
метапрограммирования) произвел непоправимое повреждение в умах. Если ad hoc полиморфизм
(overloading) был вполне себе насущен и уместен, то реализация как бы true полиморфизма
(на самом деле - убогой пародии на него) с помощью механизма наследования и виртуальных
функций - породила целое поколение людей, которые, в определенном смысле, уже безнадежны.
Я это, отчасти, знаю по себе.

Хм, не знаю. Помню, в fido7.ru.c-cpp приходил некто Виталий Луговский, который говорил что
ООП - говно, поскольку нет никакой гарантии, что виртуальная функция будет делать то, что
она должна делать, исходя из требований к интерфейсу.

С такой проблемой Джависты сталкиваются и решают это с помощью JUnit-тестов.
Там мы пишем тесты, насколько поведение подсистемы соответствует требованиям.
Как такие проверки делаются в системах, построенных на статических правилах, я не видел.

awson
Все эти ужимки и прыжки с "делегатами" и бог знает чем еще - борьба с ветряными мельницами.
Выкиньте в помойку "объекты" с "наследованием" и проблемы исчезнут как утренний туман
(ВАЖНОЕ ЗАМЕЧАНИЕ - в современном C++ все это используется, но для совершенно других целей
- а именно, как инструмент реализации функционального языка шаблонов,
интерпретируемого во время компиляции; здесь не должно быть путаницы
- слова остались те же, но смысл изменился).

Если делегаты придумал Микрософт, то в них может быть есть смысл. В Микрософте работают
талантливые архитекторы.

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

Если же иметь какой-то паззл, в котором все зависит от всего, то задачу можно и не решить.
Особенно, когда нет import'ов и приходится проектировать заодно топологию включений.

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

Очень легко читается. К тому же легко анализируется компьютером.

awson
Все это давно не новость в академической среде, но впервые это было (насильно) внедрено на промышленном уровне.
И это серьезный шаг вперед. Но САМ ЯЗЫК - худший из компонентов жабы как платформы.

В последнее время я почему-то стал сторонником разработки языков по административной команде и конкретному ТЗ.
Как, например была создана Ада. Идея должна быть целостной.

...

Рейтинг:

0 / 0

10.01.2005, 13:37

| Ответить | Цитировать | Написать

C++ & Java

#32857449

Сергей Ильич

Участник

Откуда: Из Питера

Сообщения: 385

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

10.01.2005, 13:40

| Ответить | Цитировать | Написать

C++ & Java

#32857486

www.fun4me.narod.ru

Участник

Откуда: Moscow

Сообщения: 1 674

Рейтинг: 0 / 0

Ну шаблоны в Java вполне можно добавить. Вот, хотя бы, как здесь: ссылка .

...

Рейтинг:

0 / 0

10.01.2005, 13:59

| Ответить | Цитировать | Написать

C++ & Java

#32857514

dwl

Гость

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

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

так что я умываю руки. пусть здесь сотрясают воздух другой.

...

Рейтинг:

0 / 0

10.01.2005, 14:16

| Ответить | Цитировать | Написать

C++ & Java

#32857563

dwl

Гость

NotGonnaGetUs
Информация, которая может тебя заинтересовать почитай .

Относительно сравнения дженериков и шаблонов. Кстати интересный пример оттуда

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

Collection<A> c;
...
c.init().next() ...
becomes
Collection c;
...
(A)(c.init().next())...

т.е. по сути Ява дженерик не является statically type safe in the simplest form . Отсюда и ограничения, коротко и ясно
автор
- cannot inherit from a type parameter (no mixins)
- cannot cast to a type parameter
- cannot construct an object
- originally could not read member classes
from a type parameter

...

Рейтинг:

0 / 0

10.01.2005, 14:36

| Ответить | Цитировать | Написать

C++ & Java

#32857565

dwl

Гость

NotGonnaGetUs
Кстати лично для себя хочу спросить насколько близко к правде это утверждение:
авторThe container library in Java was poorly designed. Just a few obvious example. Elements are copied into a temporary array from ArrayList in order to be sorted and then copied back -- this defeats the very intention of using array as the container.

...

Рейтинг:

0 / 0

10.01.2005, 14:39

| Ответить | Цитировать | Написать

C++ & Java

#32857600

Сергей Ильич

Участник

Откуда: Из Питера

Сообщения: 385

Рейтинг: 0 / 0

dwlThe container library in Java was poorly designed. Just a few obvious example. Elements are copied into a temporary array from ArrayList in order to be sorted and then copied back -- this defeats the very intention of using array as the container.
Он копирует во временный массив указатели, а не сами объекты.
Зато можно сортировать LinkedList, несмотря на то что он не поддерживает random-доступ. (n + 1) * log (n).

...

Рейтинг:

0 / 0

10.01.2005, 15:00

| Ответить | Цитировать | Написать

C++ & Java

#32857605

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

dwl NotGonnaGetUs
Кстати лично для себя хочу спросить насколько близко к правде это утверждение:
авторThe container library in Java was poorly designed. Just a few obvious example. Elements are copied into a temporary array from ArrayList in order to be sorted and then copied back -- this defeats the very intention of using array as the container.

Сортировка это o(n*logn) минимум.
Создание копии массива o(n) - елементы не копируются, копируются ссылки на них, причём для этого используется native реализация клонирования массивов, т.е. чертовски быстрая :)
В итоге, если что и тратится зря, то только n*8 байт памяти на временный массив.

Если вообще говорить про List, то это абстрактный интерфейс.
Он определят своего рода "динамический массив".
Существуют различные реализации этого интерфейса.
ArrayList реализует List как враппер над обычным массивом.
LinkedList - как двухсвязный список.
Есть синхранизрованный листы (безопасные при мультисрединг использовании), есть не модифицируемые листы и т.д.

Соответственно каждая из реализаций имеет свои плюсы/минусы по времени на добавление/поиск/изменение элементов и в зависимости от этого выбирается алгоритм сортировки (методом сортировки коллекций, а не программистом :)).

...

Рейтинг:

0 / 0

10.01.2005, 15:04

| Ответить | Цитировать | Написать

C++ & Java

#32857608

awson

Гость

Сергей Ильич
Если делегаты придумал Микрософт, то в них может быть есть смысл. В Микрософте работают талантливые архитекторы.

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

STL потому и была революционна (с точки зрения кондового ООП), что отвинтила алгоритмы от данных, то бишь это самое ООП попросту похерила.

Сергей Ильич
По поводу ООП... Если писать программу по принципу
намазал кирпич раствором - положил в кладку - намазал кирпич раствором - положил в кладку - etc
то через некоторое время обнаруживаешь, что задача решена.

Если же иметь какой-то паззл, в котором все зависит от всего, то задачу можно и не решить.
Особенно, когда нет import'ов и приходится проектировать заодно топологию включений.

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

А как раз для функционального программирования она работает на 100%. Я вижу функцию, и мне больше НИЧЕГО не нужно знать. ВООБЩЕ. По определению.

Сергей Ильич
Очень легко читается. К тому же легко анализируется компьютером.

Дико раздражает verbosity. На каждый чих - километры текста. Это при том, что, типа, язык более высокого уровня, чем, например, С.

...

Рейтинг:

0 / 0

10.01.2005, 15:07

| Ответить | Цитировать | Написать

C++ & Java

#32857628

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

dwl NotGonnaGetUs
Информация, которая может тебя заинтересовать почитай .

Относительно сравнения дженериков и шаблонов. Кстати интересный пример оттуда

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

Collection<A> c;
...
c.init().next() ...
becomes
Collection c;
...
(A)(c.init().next())...

[/quot]

Это не провакация, а не пример :)

Код: plaintext

1.
2.
3.
4.

      Collection<Integer> c =  new  ArrayList<Integer>();
      Integer i = c.iterator().next(); - ok
      String s = c.iterator().next(); - compile error;
      String s = (String)c.iterator().next(); - compile error;

...

Рейтинг:

0 / 0

10.01.2005, 15:19

| Ответить | Цитировать | Написать

C++ & Java

#32857632

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

NotGonnaGetUsЭто не провакация, а не пример :)

первое не лишнее :)

...

Рейтинг:

0 / 0

10.01.2005, 15:21

| Ответить | Цитировать | Написать

C++ & Java

#32857660

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

dwl NotGonnaGetUs

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

Collection<A> c;
...
c.init().next() ...
becomes
Collection c;
...
(A)(c.init().next())...

А, они о том, что в после компиляции код првращается в код с кастом.
А где тут проблема? :) Безопасность этого каста проверена на стадии компиляции.

...

Рейтинг:

0 / 0

10.01.2005, 15:41

| Ответить | Цитировать | Написать

C++ & Java

#32857707

dwl

Гость

NotGonnaGetUsА где тут проблема? :) Безопасность этого каста проверена на стадии компиляции.
Нет. вот тут не соглашусь. и не только я, но и доки.

1) Т.к. все классы суть ссылки(указатели),
2) все они наследуются от "нетипизированного" указателя на базовый супер-класс

поэтому на этапе компиляции проверяется правомочность таких преобразований (ну например в С++ там всякие проверки размеров типов). А остальное будет происходить в рантайм. Для таких целей например в С++ было создано преобразование static_cast, которое полность выполняется на стадии компиляции.

в случае обычных C-style преобразований, не происходит полной провероки типов. Например в каком-то месте программы у тебя стоит

Код: plaintext

1.
2.
3.
4.
5.

Base *b;
//... что-то тут происходит заполняющее b например Derived2
Derived1 *d = (Derived*)(b);
//...далее опять программа живет своим путем
d->derived1method(); // однако указатель d как и b указавать будет в результате выполнения на совсем другой тип у которого этого метода быть не может

ясна проблема? поэтому на этапе компиляции происходит ПОЧТИ чисто синтаксическая проверка. и в описанном мной примере компилятор не ругнется но при выполнении программы будет исключение.

Это и есть механизм позднего связывания о котором я так долго талдычил. Выснилось вы его по разному понимаем. Так вот, все преобзразование типов, кроме POD и static_cast, это откладывание проверки типов на этап рантайм. я не буду говорить слово "поверьте", вы не поверите. 8-)))

жаль конечно, могу надеется что кто-нить проверит (а не подгонит результат).

...

Рейтинг:

0 / 0

10.01.2005, 16:13

| Ответить | Цитировать | Написать

C++ & Java

#32857858

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

dwl
1) Т.к. все классы суть ссылки(указатели),

Если мы говорим Java, то все классы - суть классы. А переменные - суть указатели классы.

2) все они наследуются от "нетипизированного" указателя на базовый супер-класс

Все классы наследники класса Object.

поэтому на этапе компиляции проверяется правомочность таких преобразований (ну например в С++ там всякие проверки размеров типов). А остальное будет происходить в рантайм.

Не надо путать поведение с реализацией. Компилятор не позволит написать код, который выкинит в рантайм классКастЭксепшин.

Например в каком-то месте программы у тебя стоит

Код: plaintext

1.
2.
3.
4.
5.

Base *b;
//... что-то тут происходит заполняющее b например Derived2
Derived1 *d = (Derived*)(b);
//...далее опять программа живет своим путем
d->derived1method(); // однако указатель d как и b указавать будет в результате выполнения на совсем другой тип у которого этого метода быть не может

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

 class  B{}
 class  SubB  extends  B {}
 class  D {
   void  method();
}
... 
B b =  new  SubB();
D d = (D)b; 
d.method();

Данный код скомпилируется только, если D - находится в одно иерархии с В (т.е. является наследником или предком В).
А в рантайм ошибка произойдёт на строчке (D)b, а не d.method().
Тем не менее к generic этот пример не имеет отношения.
Компилятор вставит добавит каст (D)b, только если будет 100% уверенность, что объект на который указывает b это инстанс D.
Сделать каст статическим, значит пересобирать исходный класс (объявленный с темплейтами) при каждом новом его использовании. В java этого нет.
В случае если есть РЕАЛЬНАЯ необхожимость генерить классы по шаблонам, нужно использовать механизм аннотаций. Они расширяют функциональность языка без усложнения синтаксиса языка и компилятора. Что на мой взгляд большой плюс.

жаль конечно, могу надеется что кто-нить проверит (а не подгонит результат).

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

        Collection<Integer> c =  new  ArrayList<Integer>();
        c.add( 4 );

        Collection bad = c;
        bad.add( new  Object());

         for (Integer i: c){
            System.out.println("i:" + i);
        }

Получим рантайм exception в цикле.
Прична - использования не параметризованной коллекции.
Отказ от параметризации сразу переносит ответственность с компилятора на разрабочика - ничего неожиданного.
Такова цена отказа от пересборки классов.
Было бы неожиданно, если прошла такая запись:
Collection<Object> bad = c;

Можно на это ругаться, можно этим гордиться. Зависит от желания :)
Истина заключена в том, что не нужно понимать инструмент, который используешь.

...

Рейтинг:

0 / 0

10.01.2005, 17:28

| Ответить | Цитировать | Написать

C++ & Java

#32857866

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

NotGonnaGetUsИстина заключена в том, что не нужно понимать инструмент, который используешь.

Что сегодня меня на лишнии "не" потянуло %) Это опечатка!

...

Рейтинг:

0 / 0

10.01.2005, 17:33

| Ответить | Цитировать | Написать

C++ & Java

#32857916

dwl

Гость

NotGonnaGetUsДанный код скомпилируется только, если D
вы немного меня не поняли. Опишу подробней
1) есть базовый класс B
2) есть два наследника D1 и D2
3) у D1 есть method1() у D2 соответсвенно method2()
4) создаем в перемнной типа B объект типа D2
5) в переменную типа D1 преобразуем переменную B
6) вызываем method1

получается такой, что компилятор его пропустит, а рантайм сгенерит исключение. Этот пример я привел лишь к тому, чтобы сказать что преобразование типов - есть динамическое связывание. Т.е. это не строгая статическая проверка типов, как с шаблонами С++. Вот вам и еще разница.

...

Рейтинг:

0 / 0

10.01.2005, 18:03

| Ответить | Цитировать | Написать

C++ & Java

#32857944

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

dwl1) есть базовый класс B
2) есть два наследника D1 и D2
3) у D1 есть method1() у D2 соответсвенно method2()
4) создаем в перемнной типа B объект типа D2
5) в переменную типа D1 преобразуем переменную B
6) вызываем method1

получается такой, что компилятор его пропустит, а рантайм сгенерит исключение.

Вы смешиваете каст и шаблоны.
Generic java реализуется по средством "безопасного" runtime cast'a.
Но это не значит, что сравнивая generic и темплейты, нужно заменять generic на runtime каст. Это рантайм каст, но его допустимость проверена на этапе компиляции.

Этот пример я привел лишь к тому, чтобы сказать что преобразование типов - есть динамическое связывание. Т.е. это не строгая статическая проверка типов, как с шаблонами С++. Вот вам и еще разница.

Разница меджду чем и чем? Если между кастом и темплейтами, то вот пример.
Библиотечный класс. Некий его метод имеет тип возвращемого аргумента В.
На практике он возвращает одного из наследников - D1 или D2. Затем нужно вызывать метод1 или метод2.
Не меняя библиотечный класс замените динамический каст(или выяснение типа в runtime) на статический при помощи чего угодно.
Это не возможно. Потому что на этапе компиляции В ПРИНЦИПЕ нельзя узнать какой же объект будет возвращён (пусть это зависит от нажатия клиентом кнопки в веб браузере).
Шаблоны тоже не всемогущи :)

...

Рейтинг:

0 / 0

10.01.2005, 18:26

| Ответить | Цитировать | Написать

C++ & Java

#32857960

dwl

Гость

NotGonnaGetUsРазница меджду чем и чем?
то о чем вы спрашивали - между дженериками явы и шаблонами С++( кстати и дженериками C# ). Правда у последних нет специализации и они инстанцируются полностью для указанных типов. Хотя на уровне IL дружат с шаблонами С++. Вобчем то, что я упомянул плюс еще 4 различия (я их просто упоминаю чтобы подвести ИТОГ различий, а не чтобы выделить чьи-то преимущества или недостаки. пусть это вас не задевает)
- нельзя наследовать от аргумента шаблона
- нельзя кастовать от аргумента шаблона в другой тип
- нельзя контруировать класс
- нельзя читать членов класса аргумента шаблона

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

...

Рейтинг:

0 / 0

10.01.2005, 18:41

| Ответить | Цитировать | Написать

C++ & Java

#32857973

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

awson
STL потому и была революционна (с точки зрения кондового ООП), что отвинтила алгоритмы от данных, то бишь это самое ООП попросту похерила.

Сорри, я опять со своей java'ой влезу.

Возможно я не уловил что есть "кондовсое ОПП". Может его и правда надо похерить раз и навсегда, сути это всё равно неменяет.

Алгоритм нельзя отвинтить от данных, хотя бы потому, что он с этими данными работает.
Похоже революция для С-комунити была в том, что привязка к классу заменилась привязкой к сигнатуре метод(а/ов) которые в этом классе реализованны.
Мощно!
И cмешнo, если смотреть на это со стороны java, где существует такое понятие как интерфейсы.
Со стороны, как вы вырзились, "монстрообразного промышленного воплощения идей ООП", которые должны быть убиты "алгоритмами, отвязанными от данных"! :)

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

Если кирпичи кладутся как попало, и дом строится на песке, а не надёжном фундаменте - то дома не получится - вы правы.
Что бы называть себя строителем, не достаточно знать, что существуют кирпичи, нужно уметь их класть %)
Такому строителю, лучше продолжить рыть землянки новым савочком :)

Дико раздражает verbosity. На каждый чих - километры текста. Это при том, что, типа, язык более высокого уровня, чем, например, С.
Если для вас программа это огромное число чихов, которые никак не соотносятся друг с другом - тогда да, ещё то verbosity.
В остальных случаях это компактное изложение мыслей программиста.

---

В этой связи хочется вспомнить "Преступление и наказание".
Есть системные программисты и есть прикладные программисты.
А есть системные программисты, которые думают, что они прикладные и прикладыне программисты, которые думают, что они системные...

Там где ООП не эффективно - оно не нужно, там где оно эффективно, теплейты его не заменят.

з.ы. флуд, флуд, флуд... ! :)

...

Рейтинг:

0 / 0

10.01.2005, 18:57

| Ответить | Цитировать | Написать

C++ & Java

#32857987

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

dwl NotGonnaGetUsРазница меджду чем и чем?

Не хватает только пунктиков:
- не нужно пересобирать классы.
- "нельзя" превращются в "можно", если при инициализации класса передавать ему Class класса, которым он инициируется и совмещать технику генерик с интерфейсами :)

По поводу чистого генерика - согласен со всеми пунктами нельзя :)

...

Рейтинг:

0 / 0

10.01.2005, 19:09

| Ответить | Цитировать | Написать

C++ & Java

#32858075

awson

Гость

NotGonnaGetUs
Алгоритм нельзя отвинтить от данных, хотя бы потому, что он с этими данными работает.
Похоже революция для С-комунити была в том, что привязка к классу заменилась привязкой к сигнатуре метод(а/ов) которые в этом классе реализованны.
Мощно!
И cмешнo, если смотреть на это со стороны java, где существует такое понятие как интерфейсы.

Если я не путаю, интерфейсы в java == pure virtual функциям в С++. В С++ это было со времен, когда Гослинг под стол пешком ходил. Ну и что? Раз они объявлены в классе и, в конечном итоге, ссылаются на экземпляр класса, то что это вообще меняет?

В STL к классам, представляющим данные, может ВООБЩЕ НЕ ПРЕДЪЯВЛЯТЬСЯ НИКАКИХ требований и не требоваться наличия никаких специфических методов. Если нужных вам "интерфейсов" нет, вы пишете функтор и скармливаете алгоритму. Вуаля.

...

Рейтинг:

0 / 0

10.01.2005, 20:42

| Ответить | Цитировать | Написать

C++ & Java

#32858207

с127

Гость

2 NotGonnaGetUs

> А это и не должно ничего доказывать.

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

>У вас не бывает. А у нас бывает :)

У вас много чего бывает, только все без толку.

...

Рейтинг:

0 / 0

11.01.2005, 01:35

| Ответить | Цитировать | Написать

C++ & Java

#32858971

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

с1272 NotGonnaGetUs

> А это и не должно ничего доказывать.

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

Не стал лениться, нашёл откуда вытащена фраза.
NotGonnaGetUs
c127
В С++ и других языках такое тоже можно сделать, в каких-то IDE наверняка сделано, только ИМХО это бесполезное свойство. Как я уже говорил, в Паскале в этом смысле можно наворотить гораздо больше чем в джаве, потому что паскаль проще и строже, но это ничего не доказывает.

А это и не должно ничего доказывать.
Если что-то можно сделать, но этого не сделали - значит этого ещё нет.
Тем не мнее, очень рад за паскаль, только никак не могу понять причём он тут.
Но если вам интересно поговорить, то пожалйста. Можно завести отдельный топик на эту тему.

Я всего-навсего растолковал вам смысл фразы "на стадии написания",
ничего при этом не доказывая :)
Что-то доказывать стали вы, вспомнив о паскале.

А что до полезности тех или иных свойств хорошей IDE - в отдельный топик :)

>У вас не бывает. А у нас бывает :)

У вас много чего бывает, только все без толку.
[/quot]
Чувствуется глубокая аргументация. Respect.

...

Рейтинг:

0 / 0

11.01.2005, 13:29

| Ответить | Цитировать | Написать

C++ & Java

#32859231

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

awsonЕсли я не путаю, интерфейсы в java == pure virtual функциям в С++. В С++ это было со времен, когда Гослинг под стол пешком ходил. Ну и что? Раз они объявлены в классе и, в конечном итоге, ссылаются на экземпляр класса, то что это вообще меняет?

В STL к классам, представляющим данные, может ВООБЩЕ НЕ ПРЕДЪЯВЛЯТЬСЯ НИКАКИХ требований и не требоваться наличия никаких специфических методов. Если нужных вам "интерфейсов" нет, вы пишете функтор и скармливаете алгоритму. Вуаля.

Наверное путаете.
Interface отвязан от какого-либо класса. Но классы реализовывают интерфейсы.
Если с равнивать с С++, то интерфейс - это набор связанных функций.

"может ВООБЩЕ НЕ ПРЕДЪЯВЛЯТЬСЯ" это значит, что их предъявит не известно кто и не известно в каком месте.

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

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

...

Рейтинг:

0 / 0

11.01.2005, 14:42

| Ответить | Цитировать | Написать

C++ & Java

#32859340

www.fun4me.narod.ru

Участник

Откуда: Moscow

Сообщения: 1 674

Рейтинг: 0 / 0

>> Interface отвязан от какого-либо класса. Но классы реализовывают >> интерфейсы.
>> Если с равнивать с С++, то интерфейс - это набор связанных функций.

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

...

Рейтинг:

0 / 0

11.01.2005, 15:12

| Ответить | Цитировать | Написать

25 сообщений из 160, страница 6 из 7

все

Форумы / C++ [игнор отключен] [закрыт для гостей] / C++ & Java

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=57&msg=32857449&tid=2029679]:	0ms
get settings:	6ms
get forum list:	14ms
check forum access:	3ms
check topic access:	3ms
track hit:	157ms
get topic data:	11ms
get forum data:	2ms
get page messages:	83ms
get tp. blocked users:	1ms
others:	226ms

total:	506ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы