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

C>>На МакОСи, например, не пишут почти на С++. У них есть Objective-C, которого как оказывается тоже на многое хватает.

E>Ага-ага. И что, офис или БД какая там на Objective-C?
iWork. Почти все родные cocoa-приложения на ObjC.

E>Или ядро OS может на Objective-C?
Как и в других ОС ядро на С.

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


S>>Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.
CC>Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.

Все дело именно в таких вот мелочах.

Кстати, а С++ уже научился nullable типам?

int? a = null; // nullable
a = 1;
bool? b = false; // nullable

...

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

CC>Ну наконец то спокойный ответ с полезной ссылкой без фанатских причитаний.
Теперь осталось дождаться от Вас хоть одного ответа без "фанатских причитайний".

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

C>>Так и есть — в С++ зоопарк глючных, несовместимых реализаций строк. А в исходниках каша из std::wstring, CWSTRPTR (spelling), CString, QString, wchar и десятков аллиасов.
CC> Это скорее проблемы человеческой неорганизованности нежели языка.

Ну конечно. Это не проблемы языка. У языка вообще проблем нет. Проблемы есть у программистов, которые пишут на этом языке.

Здравствуйте, Игoрь, Вы писали:

И>Например, если идет относительно активная работа с текстом, включая его изменения, то почему я должен на каждый чих создавать копию строки? Опять эффективность, но уже в другую сторону.

Откройте для себя System.Text.StringBuilder.

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

C>Откройте для себя System.Text.StringBuilder.
Первое. Читай внимательно, я в курсе.
Второе. Если хочешь, чтобы тебе отвечали не в стиле — "сам дурак", научись нормально разговаривать.

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

S>>>Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.
CC>>Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.

C>Все дело именно в таких вот мелочах.
C>Кстати, а С++ уже научился nullable типам?

Твои посты поражают логикой и внятностью.
Каким боком это вдруг к обсуждаемой теме?

C>Кстати, а С++ уже научился nullable типам?

int* n = null;

Нашел чем гордиться

Здравствуйте, Игoрь, Вы писали:

И>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:
const это фигня на постном масле.
Ибо изменяемость/не изменяемость должны быть неотъемлемым свойством типа, а не модификатором.
Тогда сразу открывается возможность для кучи доказательства кучи свойств кода и как следствие более агрессивных оптимизаций. Про такую "мелочь" как увеличение надежности и предсказуемости кода для разработчика я вообще молчу.

И>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.
Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.

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

C>Кстати, а С++ уже научился nullable типам?
Нет, А нафига?
Но в принципе можно поизвращаться и научить
Class nullable

Здравствуйте, Игoрь, Вы писали:


C>>Откройте для себя System.Text.StringBuilder.
И>Первое. Читай внимательно, я в курсе.
Если Вы в курсе, тогда к чему было писать про некие "проблемы при работе с большим количеством текста"? Флейма ради?
И>Второе. Если хочешь, чтобы тебе отвечали не в стиле — "сам дурак", научись нормально разговаривать.
Иначе на тупые попытки троллинга я уже не реагирую. Если не рубить с плеча, то будет продолжаться поток глупостей.

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

S>>>>Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.
CC>>>Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.

C>>Все дело именно в таких вот мелочах.
C>>Кстати, а С++ уже научился nullable типам?

CC>Твои посты поражают логикой и внятностью.
Какие проблемы с моей логикой?
CC>Каким боком это вдруг к обсуждаемой теме?
Тема называется "За что я не люблю С++". Не заметили?

Так что можете ответить про nullable типы?

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

C>>Кстати, а С++ уже научился nullable типам?
_>Нет, А нафига?
Потому, что удобно и временами банально необходимо.
_>Но в принципе можно поизвращаться и научить
_>Class nullable
Не сомнваюсь, что можно поизвращаться. С++ идеальный язык для того, чтоб извращаться.

Здравствуйте, Игoрь, Вы писали:

C>>Кстати, а С++ уже научился nullable типам?

И>

И>int* n = null;
И>

И>Нашел чем гордиться

Это не nullable тип.

Перепишите на С++ и сами поймете

int? a = 1;
int c = 10;
int b = (a ?? c) / 100;

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

CC>>Твои посты поражают логикой и внятностью.
C>Какие проблемы с моей логикой?
CC>>Каким боком это вдруг к обсуждаемой теме?
C>Тема называется "За что я не люблю С++". Не заметили?
Ну так писал бы коммент к начальному сообщению.
В этой подветке обсуждали строки.

C>Так что можете ответить про nullable типы?
Хочешь еще одну волну бесполезного флейма поднять чтоб замять тему со строками?
В этой ветке — только про строки.

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

C>Здравствуйте, Игoрь, Вы писали:

C>>>Кстати, а С++ уже научился nullable типам?

И>>

И>>int* n = null;
И>>

И>>Нашел чем гордиться

C>Это не nullable тип.

C>Перепишите на С++ и сами поймете
C>

C>int? a = 1;
C>int c = 10;
C>int b = (a ?? c) / 100;
C>

Вообщето похоже

    int* p = NULL;
    int a = 1;
    int c = 10;
    p = &a;
    int b = ( p == NULL ? c : *p) / 100;

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

J>Там в полный рост зоопарк компиляторов.
J>Это можно записать в недостатки С++ как платформы, но не С++ как языка.
Далеко не только.
Там тонны костылей для извлечения метаинформации.
Куча костылей для того чтобы сделать какой нибудь трюк.
Короче почти все решения из серии через зад автогеном.

J>Имхо, это совершенно некритично, и никто не мешает к этому чистому контракту привернуть пару невиртуальных функций — это никак на чистоте контракта не скажется, так как то, что было чисто виртуальным, им и останется.
Не согласен.
В принципе можно иметь реализацию по умолчанию но возможность перекрытия должна быть в обязательном порядке.
Иначе могут быть проблемы связанные с тем что конкретную реализацию таки не устраивает реализация по умолчанию.
Именно по этому вообще любое наследование реализации зло.
Одним из приемлемых вариантов было бы что-то вроде этого:

interface Iface1
{
...
}
interface Iface2
{
...
}

mixin Iface1Impl
  implements Iface1
{
...
}

mixin Iface2Impl
  implements Iface2
  required Iface1
{
...
}

class SomeClass
  implements Iface1
  implements Iface2
  aggregate Iface1Impl
  aggregate Iface2Impl
{
...
}

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

J>+1. Но это спор не о языках, а о библиотеках.
Скажи это 0xC0000005

J>+1. Макросы Немерле было бы очень здорово поиметь в плюсах. Много проблем бы сразу ушло.
Макросы немерла имеют своих тараканов. А именно они совершенно не формализованы и осень сильно подвязаны на конкретную реализацию конкретного компилятора.
Но этот недостаток можно устранить.
Правда серьезной переработкой языка и компилятора.
Но не до конца. .NET собака такая под ногами со своей кривостью путается.

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

_>

_>    int* p = NULL;
_>    int a = 1;
_>    int c = 10;
_>    p = &a;
_>    int b = ( p == NULL ? c : *p) / 100;
_>

Можно чуть короче, явно не делать проверку на NULL:

int* p = NULL;
int a = 1, c = 10;

int b = (p? *p : c) / 100;

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

C>Если Вы в курсе, тогда к чему было писать про некие "проблемы при работе с большим количеством текста"? Флейма ради?
Ничуть. StringBuilder практически ничего не предоставляет для нормальной работы. К примеру, в String классе есть много полезных методов для работы со строками, например Trim. Как мне его заюзать для StringBuilder без лишнего копирования? Я не говорю уже о том, что для того, чтобы хоть как-то работать со StringBuilder я должен оперировать сразу двумя классами — String и StringBuilder.
И>>Второе. Если хочешь, чтобы тебе отвечали не в стиле — "сам дурак", научись нормально разговаривать.
C>Иначе на тупые попытки троллинга я уже не реагирую. Если не рубить с плеча, то будет продолжаться поток глупостей.
Только троллишь тут в основном ты.

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


WH>const это фигня на постном масле.
WH>Ибо изменяемость/не изменяемость должны быть неотъемлемым свойством типа, а не модификатором.
WH>Тогда сразу открывается возможность для кучи доказательства кучи свойств кода и как следствие более агрессивных оптимизаций. Про такую "мелочь" как увеличение надежности и предсказуемости кода для разработчика я вообще молчу.
Мы сейчас говорим о конкретных языках или "вообще"? Если говорить "вообще", то я могу согласиться, что в С++ константность — это сбоку бантик, который легко снимается конст-кастом. И это все дело можно было бы сделать намного лучше, делая сейчас и не думая об обратной совместимости. С этим я как бы и не спорю. Но только при чем здесь C++ и C#?

WH>Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.
И с этим я не спорю, и то, что они могли сделать нормально — согласен, но сейчас есть то, что есть. А то что есть не особо лучше того, что есть в С++.