Здравствуйте, _Obelisk_, Вы писали:
Об этом речь не идет. Я говорю о том, что из одного порядка можно получить другой. Вренмся назад:

Архитекор в рамках ООП ДЛЯ ДАННОЙ ЗАДАЧИ может ъхорошо спроектировать обьект. Когда задача измениться, часто приходится делать новый класс обьектов.

Про бардак ничего сказано не было.
Ты спросил:

Есть ли подход, который решает эту проблему ?

Я тебе ответил.

Здравствуйте, Hacker_Delphi, Вы писали:

H_D>Все то же самое, но чайник с водой уже стоит на плите. Действия
H_D>программиста: вылить воду из чайника и выполнить предыдущий объект.
H_D> — Грустно. А нырнуть внутрь объекта нельзя? Туда, где надо газ
H_D>зажечь?
H_D> — Нельзя. Можно добавить новое свойство или действие. В нашем случае

Полная ахинея. В данном случае обьект будет иметь метод — "Вскипятись!". Обьект при этом обладает всей информацией о своём состоянии. И реалиация метода интерфейса обьекта имеет полный доступ к инкапсулированной информации о состоянии обьекта. И поэтому чайник спокойно пропускает ненужные этапы и зажигает под собой газ.
Дык штааа... "Неча на зеркало пенять, коли рожа крива" (С)
А если кто-то сдуру расколотит микроскоп об гвоздь — это не значит что микроскоп SUX, а кувадла — RULEZZ

Здравствуйте, Hacker_Delphi, Вы писали:

H_D>Вот отрывок из книши одного очень хорошего писателя:
H_D>Которая лишь подтверждает мысль, что ООП везде — это вред и блед, хотя и не отрицает что в бизнес приложениях ООП — это просто круто

Отрывок говорит о вреде излишней инкапсуляции.
Но инкапсуляция не есть фича ООП!!! Она также присуща и процедурному программированию.
В данном случае — имеем криво спроектированный процедурный API.

Здравствуйте, _Obelisk_, Вы писали:

_O_>Это пример криво спроектированного чайника, который инкапсулирован с газовой плитой и водопроводным краном . Поддерживает сия штука лишь методы "ВылитьВоду", "НалитьВодуПоставитьНаПлитуВключитьГаз". Брр....
_O_>Такие "мины с часовым механизмом" закладываются не технологией, а архитектором.

Это пример криво проектирующего Чайника-архитектора

К>Отрывок говорит о вреде излишней инкапсуляции.
К>Но инкапсуляция не есть фича ООП!!! Она также присуща и процедурному программированию.
К>В данном случае — имеем криво спроектированный процедурный API.

Как же инкапсуляция не фича ООП?
три фичи (кита) ООП — инкапсуляция полиморфизм и наследование. гыгы

(Все сказанное не отнсится к самому первичному посту — явно литературный диспут)

Собственно, факт известный. ООП жертвует частью скорости в пользу более простому программированию. Например, как ни крути, а string работает медленнее непосредственной работы с char* (не верите? попробуйте написать оператор + для строк и посчитайте, сколько будет копирований в операции a=b+c).
Просто скорость работы программы — это лишь один из факторов. ООП предлагает переспределить ресурсы в пользу экономии времени программиста.
Asm -> C -> C++ -> C#. Налицо всё большая удобность для программиста и всё меньшая эффективность. Но процессорное время дешевле, чем время работы программиста.
Office 97 весом в 2М и летающий на 486-й машине сейчас никому не нужен.

Здравствуйте, dad, Вы писали:

К>>Но инкапсуляция не есть фича ООП!!! Она также присуща и процедурному программированию.
К>>В данном случае — имеем криво спроектированный процедурный API.

dad>Как же инкапсуляция не фича ООП?
dad>три фичи (кита) ООП — инкапсуляция полиморфизм и наследование. гыгы

Полиморфизм и инкапсуляция также (в ограниченной степени) присущи процедурному программированию. С наследованием действительно обломс.

Глупый пример.

Почему при демонстрации ООП автор предполагает, что все что можно запехнуто в один большууууууший и еле ворочащийся объект, а в функциональном программировании все гибко?.

Тогда противопоставлю ему такой же плохой пример из функционального программирования:

Его же задача решенная одной монолитной и неповоротливой функцией, ну и... размещенной для сложности в dll поставляемой сторонней компанией:

function Вскипятить_чайник(координаты чайника, координаты крана, координаты плиты, объем газа)
begin
наполнить чайник водой из-под крана
поставить на плиту
зажечь газ
дождаться пока не закипит
end;

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

Поэтому присоединяюсь к предыдущим сообщениям о кривости рук проектировщика — тут уже ни ООП ни функциональное програмирование не поможет.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>как ни крути, а string работает медленнее непосредственной работы с char* (не верите? попробуйте написать оператор + для строк и посчитайте, сколько будет копирований в операции a=b+c).

На каких-то операциях медленнее, а на каких-то — не очень. Смотря что за операция и смотря что за реализация string.

ЕК>Office 97 весом в 2М и летающий на 486-й машине сейчас никому не нужен.

Office 97 заметно тормознее офиса XP имхо.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Собственно, факт известный. ООП жертвует частью скорости в пользу более простому программированию. Например, как ни крути, а string работает медленнее непосредственной работы с char*
ЕК>(не верите? попробуйте написать оператор + для строк и посчитайте, сколько будет копирований в операции a=b+c).
Ха-Ха-Ха. Еще один! Пару недель как обсуждали строки в С и в С++. Ребята, С++ порвет С на строках на раз-два. Просто потому, что на нем можно написать код, который выльется в простых случаях ровно в тот же асм, что и аналог на С, а в сложных — выберет более оптимальную стратегию благодаря возможности обмениваться дополнительными данными. Нет никакого просада производительности в ООП.
ЕК>Просто скорость работы программы — это лишь один из факторов. ООП предлагает переспределить ресурсы в пользу экономии времени программиста.
ЕК>Asm -> C -> C++ -> C#. Налицо всё большая удобность для программиста и всё меньшая эффективность. Но процессорное время дешевле, чем время работы программиста.
Это миф. На практике оказывается, что чем более общие концепции предоставляет язык для выражения программистской мысли, тем лучше все работает. Введение инлайнов в плюсах позволило порвать С на коротких функциях. Введение шаблонов помогло порвать его там, где раньше вылизывали библотеки вручную.
Блин, ребята тут на конференции выступали с шаблонным алгоритмом Кули-Тьюки для быстрого фурье-преобразования. Когда число точек — степень 2, он выполняется с той же скоростью, что библиотечный аналог на С. Зато если у вас всего 1000 точек, а не 1024, вокруг библиотечного алгоритма приходится делать кучу припрыгиваний, типа перемасштабирования или добивания 24 точек экстраполяцией. Т.е. либо терять в точности, либо в производительности. А шаблонному алгоритму по барабану — он раскладывает его как 2*2*2*5*5*5 и выполняет за то же время.

Ладно, давайте дальше смотреть. Ага, неэффективная Джава? Ребята, в очень большом классе задач джава рвет серверные приложения на плюсах на раз-два. Потому, что сборка мусора выполняется ой как редко. А плюсы, несмотря на все свои преимущества по сравнению с С, тем не менее все построены на постоянных перевыделениях памяти. Стоит нам попытаться использовать динамический полиморфизм — и упс! мы начинаем считать ссылки, передача указателей теперь не простое копирование, а инкремент/декремент, и каунтер все время колеблется около нуля, пока наконец это пламя ен погаснет... .NET пока еще не прошел горнила оптимизации, ну, да первый С++ тоже действительно имел траблы с производительностью. Ничего, нагонят через пару лет.

>Ребята, С++ порвет С на строках на раз-два. Просто потому, что на нем можно написать код, который выльется в простых случаях ровно в тот же асм, что и аналог на С, а в сложных — выберет более оптимальную стратегию благодаря возможности обмениваться дополнительными данными.

Глупости. Код (на С++) будет более читабелен. Но менее эффективен. Вот пример:
string operator + (const string& s1,const string s2)
{
string res(...); // private конструктор без инициализации
res.set_length(s1.length()+s2.length());
strcpy(res.m_ptr,s1.m_ptr);
// strcat(res.m_ptr,s2.m_ptr); — неправильно
strcpy(res.m_ptr+s1.length(),s2.m_ptr);
return res;
}
Можешь предложить более эффективную реализацию?
Далее,
x=a+b;
Что тут будет? a и b передадутся по ссылке, тут всё нормально. Внутри оператора сначала в стеке создастся res (конструктор приватный, всё нормально). Заполнится данными (тоже нормально). А вот с возвратом значения — жопа. Сначала res скопируется в анонимную переменную (конструктором копирования), затем из неё — в x тем же конструктором копирования. Вот здесь и неэффективно, и сделать ничего нельзя. Постоянные копирования — проблема в С++.
Далее, использование класса string располагает к такому коду:
...
string s="select * from t where id="+string::number(id);
...
что страшно неэффективно по сравнению с
...
char sql[128];
sprintf(sql,"select * from t where id=%d",id);

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

>Блин, ребята тут на конференции выступали с шаблонным алгоритмом Кули-Тьюки для быстрого фурье-преобразования. Когда число точек — степень 2, он выполняется с той же скоростью, что библиотечный аналог на С. Зато если у вас всего 1000 точек, а не 1024, вокруг библиотечного алгоритма приходится делать кучу припрыгиваний, типа перемасштабирования или добивания 24 точек экстраполяцией. Т.е. либо терять в точности, либо в производительности. А шаблонному алгоритму по барабану — он раскладывает его как 2*2*2*5*5*5 и выполняет за то же время.

Это лажа — ты же сравниваешь два разных алгоритма. Применение шаблонов не может влиять на возможность разложения числа точек на простые множители. Так что это не пример.

>Ладно, давайте дальше смотреть. Ага, неэффективная Джава? Ребята, в очень большом классе задач джава рвет серверные приложения на плюсах на раз-два. Потому, что сборка мусора выполняется ой как редко. А плюсы, несмотря на все свои преимущества по сравнению с С, тем не менее все построены на постоянных перевыделениях памяти. Стоит нам попытаться использовать динамический полиморфизм — и упс! мы начинаем считать ссылки, передача указателей теперь не простое копирование, а инкремент/декремент, и каунтер все время колеблется около нуля, пока наконец это пламя ен погаснет... .NET пока еще не прошел горнила оптимизации, ну, да первый С++ тоже действительно имел траблы с производительностью. Ничего, нагонят через пару лет.

По какому критерию ждава рвёт С++? А по скорости разработки! По надёжности программ (ну не упадёт джава по AV!)

Чем крупнее блоки, из которых собирается программа, тем менее это эффективно. Тем больше работает принцип чайника. Посмотри, например, на www.wasm.ru.
цикл
int *a,*b;
for(int i=0;i<n;i++)
a[i]=-b[i];
на асме оптимизируется в 7-8 раз.

Здравствуйте, Евгений Коробко, Вы писали:

string operator + (const string& s1,const string s2)
{
  string res(...); // private конструктор без инициализации
  res.set_length(s1.length()+s2.length());
  strcpy(res.m_ptr,s1.m_ptr);
  // strcat(res.m_ptr,s2.m_ptr); - неправильно
  strcpy(res.m_ptr+s1.length(),s2.m_ptr);
  return res;
}

ЕК>Можешь предложить более эффективную реализацию?
Да не нужно.
ЕК>Далее,
ЕК>x=a+b;
ЕК>Что тут будет? a и b передадутся по ссылке, тут всё нормально. Внутри оператора сначала в стеке создастся res (конструктор приватный, всё нормально). Заполнится данными (тоже нормально). А вот с возвратом значения — жопа. Сначала res скопируется в анонимную переменную (конструктором копирования), затем из неё — в x тем же конструктором копирования. Вот здесь и неэффективно, и сделать ничего нельзя. Постоянные копирования — проблема в С++.
Я тебя уверяю, что копирование 4х байт (а кроме m_ptr ничего и не копируется) в большинстве случаев значительно дешевле, чем сканирование строки в поисках нуля.

ЕК>Далее, использование класса string располагает к такому коду:
ЕК>...
ЕК>string s="select * from t where id="+string::number(id);
ЕК>...
ЕК>что страшно неэффективно по сравнению с
ЕК>...
ЕК>char sql[128];
ЕК>sprintf(sql,"select * from t where id=%d",id);
Ну кто тебе это сказал? Почему страшно неэффективно-то? перевыделений много? В данном примере это будет чуть-чуть менее хреновый вариант для C, поскольку sprintf нет нужды бегать по строке несколько раз. Если конкатенаций много, то точно так же заранее резервируется место в таргет-строке и все вырождается в очень близкий код на асме.
ЕК>Это верно в смысле надёжности. Для современных программ (которые очень сложны) надёжность зачастую гораздо важнее эффективности.
ЕК>Более высокий уровень языка программирования может привести к увеличению эффективности только из-за того, что человек может не справиться с чудовищным объёмом кода на С или асме. Но это — человеческий фактор и к эффективности языка отношения не имеет.
Про надежность я даже не говорю! Я говорю о том, что общий алгоритм в зависимости от конкретных параметров может свернуться в один из нескольких частных случаев, выбирая самый эффективный (например, решая "на ходу" будем распределять память на стеке или в хипе). А вот прекрасно отлизанный частный случай моментально перестает быть самым эффективным при изменении параметров.
>>Блин, ребята тут на конференции выступали с шаблонным алгоритмом Кули-Тьюки для быстрого фурье-преобразования. Когда число точек — степень 2, он выполняется с той же скоростью, что библиотечный аналог на С. Зато если у вас всего 1000 точек, а не 1024, вокруг библиотечного алгоритма приходится делать кучу припрыгиваний, типа перемасштабирования или добивания 24 точек экстраполяцией. Т.е. либо терять в точности, либо в производительности. А шаблонному алгоритму по барабану — он раскладывает его как 2*2*2*5*5*5 и выполняет за то же время.

ЕК>Это лажа — ты же сравниваешь два разных алгоритма. Применение шаблонов не может влиять на возможность разложения числа точек на простые множители. Так что это не пример.
Это как раз пример. Это ОДИН И ТОТ ЖЕ АЛГОРИТМ. Просто на С написали один его частный случай. Потому, что иначе пришлось бы писать по версии на каждое значение количества точек. А шаблонная версия превращается ровно в тот же код на асме, что и библиотечный, при совместимых параметрах. Только умеет работать
ЕК>По какому критерию ждава рвёт С++? А по скорости разработки! По надёжности программ (ну не упадёт джава по AV!)
Ага. И по производительности тоже рвет. Уверяю. Не везде, но рвет.

ЕК>Чем крупнее блоки, из которых собирается программа, тем менее это эффективно. Тем больше работает принцип чайника. Посмотри, например, на www.wasm.ru.
ЕК>цикл
ЕК>int *a,*b;
ЕК>for(int i=0;i<n;i++)
ЕК> a[i]=-b[i];
ЕК>на асме оптимизируется в 7-8 раз.
Хм. Правда?

void Invert(int *a, int *b, int n)
{
    for(int i=0;i<n;i++)
      a[i]=-b[i];
}

int _tmain(int argc, _TCHAR* argv[])
{
    const int n=5;
    int a[n],b[]={argc, -1, 2, -2, argc};
    Invert(a, b, 5);
  for(int i=0;i<n;i++) // подавляем оптимизацию...
  std::cout << a[i];
  return 0;
}

первые три строки _tmain превращаются при помощи VC++ 8.0 вот во что:

00402790  sub         esp,14h 
    const int n=5;
    int a[n],b[]={argc, -1, 2, -2, argc};
    Invert(a, b, n);
00402793  mov         eax,dword ptr [esp+18h] 
00402797  push        esi  
00402798  neg         eax  
0040279A  push        edi  
0040279B  mov         edi,eax 
0040279D  mov         dword ptr [esp+8],eax 
004027A1  mov         dword ptr [esp+0Ch],1 
004027A9  mov         dword ptr [esp+10h],0FFFFFFFEh 
004027B1  mov         dword ptr [esp+14h],2 
004027B9  mov         dword ptr [esp+18h],edi

Ну, давай — соптимизируй мне это хотя бы в 2 раза. В 7-8 я не прошу.
Так что хватит сказки-то рассказывать. ASM нынче применим только в тех случаях, когда у языка не хватает выразительности объяснить компилеру, что от него надо. Тогда да — сам пошел, руками все...

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Но это — человеческий фактор и к эффективности языка отношения не имеет.

Можно провокационный вопрос — а для чего вобще существуют языки программирования?

ЕК>По какому критерию ждава рвёт С++? А по скорости разработки! По надёжности программ (ну не упадёт джава по AV!)

И по производительности тож бывает.

ЕК>Чем крупнее блоки, из которых собирается программа, тем менее это эффективно. Тем больше работает принцип чайника. Посмотри, например, на www.wasm.ru.
ЕК>цикл
ЕК>int *a,*b;
ЕК>for(int i=0;i<n;i++)
ЕК> a[i]=-b[i];
ЕК>на асме оптимизируется в 7-8 раз.

А толку?

Здравствуйте, Евгений Коробко, Вы писали:

>>Ребята, С++ порвет С на строках на раз-два. Просто потому, что на нем можно написать код, который выльется в простых случаях ровно в тот же асм, что и аналог на С, а в сложных — выберет более оптимальную стратегию благодаря возможности обмениваться дополнительными данными.

ЕК>Глупости. Код (на С++) будет более читабелен. Но менее эффективен. Вот пример:

ЕК>string operator + (const string& s1,const string s2)
ЕК>{
ЕК> string res(...); // private конструктор без инициализации
ЕК> res.set_length(s1.length()+s2.length());
ЕК> strcpy(res.m_ptr,s1.m_ptr);
ЕК>// strcat(res.m_ptr,s2.m_ptr); - неправильно
ЕК> strcpy(res.m_ptr+s1.length(),s2.m_ptr);
ЕК> return res;
ЕК>}

ЕК>Можешь предложить более эффективную реализацию?

Devil in details.
Как устроена строка? Что происходит в дефолтном конструкторе, в конструкторе копирования?
Есть строки с разделяемым (shared) блоком данных; любые копирования сводятся к инкременту счетчика ссылок, а копирование данных происходит только при попытке записи в совместно используемый блок.

ЕК>Далее,
ЕК>x=a+b;
ЕК>Что тут будет? a и b передадутся по ссылке, тут всё нормально. Внутри оператора сначала в стеке создастся res (конструктор приватный, всё нормально). Заполнится данными (тоже нормально). А вот с возвратом значения — жопа. Сначала res скопируется в анонимную переменную (конструктором копирования), затем из неё — в x тем же конструктором копирования. Вот здесь и неэффективно, и сделать ничего нельзя. Постоянные копирования — проблема в С++.

Оптимизация возвращаемого значения. Допускается стандартом, реализована некоторыми компиляторами (в том числе VC).
Для тех, кто этого не делает — есть паттерн программирования move constructor. (см. не Гамма..."Паттерны проектирования", а www.CUJ.com и Александреску). Тот же самый std::auto_ptr...

ЕК>Далее, использование класса string располагает к такому коду:
ЕК>...
ЕК>string s="select * from t where id="+string::number(id);
ЕК>...
ЕК>что страшно неэффективно по сравнению с
ЕК>...
ЕК>char sql[128];
ЕК>sprintf(sql,"select * from t where id=%d",id);

А использование stringstream, а использование строк с форматированием (например, в библиотеке Qt)?

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

Ну да, конечно. Можно ручками все собрать, в этом плане нет ничего проще. Пишешь спецификацию на VHDL, рожаешь принципиальную схему, и на микросхемах ПЛМ все собираешь. Не, на ПЛМ беспонтово — на заказном чипсете.
Летать будет — не то слово! Но и это не предел.
Знаете ли вы, что обычный одноступенчатый RS-триггер можно сделать на 2 транзисторах? А типовая реализация его занимает 4-6 транзисторов (схема на двух 2И-НЕ).
Что конечный автомат на регистре будет эффективнее (меньшее количество элементов, следовательно, большая частота тактирования), если станет работать с кодами Грея, а не последовательно 1-2-3-4-5?
Что если хорошенько потрясти и попрыгать, то Пень можно раза в полтора ужать, хотя его разработка займет еще десяток лет?
Что студенты выли и бились об стены, сдавая курсовик по арифметико-логическим основам ЦВМ, где нужно было простенькую логику забить на действительно минимальной элементной базе и доказать, что минимальнее не бывает.
Что наши коллеги из Англии задавились жабой купить микроконтроллер с сетевушкой и сделали ethernet-устройство на ПЛМ (ладно еще не на рассыпухе). А потом год мучительных отладок и взаимных упреков?

НАХРЕНА ТАКОЙ ФАКТОР?!

>>Блин, ребята тут на конференции выступали с шаблонным алгоритмом Кули-Тьюки для быстрого фурье-преобразования. Когда число точек — степень 2, он выполняется с той же скоростью, что библиотечный аналог на С. Зато если у вас всего 1000 точек, а не 1024, вокруг библиотечного алгоритма приходится делать кучу припрыгиваний, типа перемасштабирования или добивания 24 точек экстраполяцией. Т.е. либо терять в точности, либо в производительности. А шаблонному алгоритму по барабану — он раскладывает его как 2*2*2*5*5*5 и выполняет за то же время.

ЕК>Это лажа — ты же сравниваешь два разных алгоритма. Применение шаблонов не может влиять на возможность разложения числа точек на простые множители. Так что это не пример.

Это не лажа. Стоимость разработки обобщенного алгоритма на Си без шаблонов, и даже стоимость конкретной специализации алгоритма методом copy-paste — не сравнится с разработкой шаблона на С++.

>>Ладно, давайте дальше смотреть. Ага, неэффективная Джава? Ребята, в очень большом классе задач джава рвет серверные приложения на плюсах на раз-два. Потому, что сборка мусора выполняется ой как редко. А плюсы, несмотря на все свои преимущества по сравнению с С, тем не менее все построены на постоянных перевыделениях памяти. Стоит нам попытаться использовать динамический полиморфизм — и упс! мы начинаем считать ссылки, передача указателей теперь не простое копирование, а инкремент/декремент, и каунтер все время колеблется около нуля, пока наконец это пламя ен погаснет... .NET пока еще не прошел горнила оптимизации, ну, да первый С++ тоже действительно имел траблы с производительностью. Ничего, нагонят через пару лет.

ЕК>По какому критерию ждава рвёт С++? А по скорости разработки! По надёжности программ (ну не упадёт джава по AV!)

ЕК>Чем крупнее блоки, из которых собирается программа, тем менее это эффективно. Тем больше работает принцип чайника. Посмотри, например, на www.wasm.ru.
ЕК>цикл
ЕК>int *a,*b;
ЕК>for(int i=0;i<n;i++)
ЕК> a[i]=-b[i];
ЕК>на асме оптимизируется в 7-8 раз.

Да-да, ты еще в С++-компиляторе включи всю отладочную инфу и отруби все оптимизации.

Объясняли бы, что не так. Я понимаю "плюс" — тут всё ясно.
А вот "минусы" имхо аргументировать надо. Вдруг умнее стану?

D>А вот "минусы" имхо аргументировать надо. Вдруг умнее стану?

Да я думал понятно. Вот с этим я не согласен:

Office 97 заметно тормознее офиса XP имхо.

Здравствуйте, Hacker_Delphi, Вы писали:

H_D> — Грустно. А нырнуть внутрь объекта нельзя? Туда, где надо газ
H_D>зажечь?
H_D> — Нельзя. Можно добавить новое свойство или действие. В нашем случае
H_D>- воду вылить. Будет новый объект. Но внутрь влезть нельзя. Объект дается

Точно-точно! Забыли поставить public!

Аналогично. Office 97 без проблем работает на P-200MMX + 32M. Попробуй запусти Office XP!

Здравствуйте, mihailik, Вы писали:

D>>А вот "минусы" имхо аргументировать надо. Вдруг умнее стану?

M>Да я думал понятно. Вот с этим я не согласен:

M>

M>Office 97 заметно тормознее офиса XP имхо.

А-а-а... жаль.
Я-то думал, работу со строками обсудим

Здравствуйте, Sinclair, Вы писали:

S>Ладно, давайте дальше смотреть. Ага, неэффективная Джава? Ребята, в очень большом классе задач джава рвет серверные приложения на плюсах на раз-два. Потому, что сборка мусора выполняется ой как редко. А плюсы, несмотря на все свои преимущества по сравнению с С, тем не менее все построены на постоянных перевыделениях памяти.

C++ дает возможность реализовать любую стратегию выделения и освобождения памяти, в том числе и сборку мусора like Java. Другой вопрос уже — какими трудозатратами это обернется. Есть и еще более оптимальные варианты Например — выделять часть своих объектов в специальном пуле, а когда они стали не нужны — просто убить этот пул вместе со всеми объектами. Порой можно даже деструкторы не звать В ряде сценариев такой сценарий будет вполне пригоден, и где там будет Java по скорости? Упирается все в тот же сакраментальный вопрос — а сколько времени уйдет на отладку? Ну и прямые руки опять же очень нужны... а за прямые руки нужно хорошо платить — проще нанять пару-тройку недоученных студентов и посадить за яву.