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

.>Programador wrote:
>> Так можно , в качестве шаблонного параметра, внутри <> МС хочет с
>> внешней линковкой, даже статик из файла не берет
.>Т.е. это ограничение только msvc? А что в текущем стандарте?
Это в Стандарте такое ограничение.

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

P>Ну раньше
P>

P>double MyFun(),x=MyFun();
P>

Это где было нельзя?

P>

P>Myclass(x);
P>

P>нельзя было

Ну а это обозначает, что (х) имеет тип Myclass

P>Зачем кстати неявное преобразование из void* убрали? чтоб лишний раз тип писать и при этом ошибаться? Или потому что из void* преобразование небезопасное. Но это и так все знают, всеравно что к снотворному писать предупреждение что может вызвать сонливость

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

E>То есть запись "int a[5]", обозначает, что если к a применить оператор [], то получится int...
E>Хорошее, привычное поведение. Зачем бы его рушить?

Э... Как бы у меня нет уверенности что освоить этот принцип легче чем подход "слева тип — справа имя переменной". Особенно для людей которые язык только-только осваивают. Ну да не суть, главная цель — чтобы намного проще было парсить С++-ный код. ИМХО, это даст толчок развитию нормальных тулзов для инструментирования кода, intellisense и т.п.

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

L>Потому что небезопасные куски программы должны бросаться в глаза. А если ты ошибёшься в типе — тебе скажет об этом компилятор, а не программа грохнется где-то у клиента на далеко за океаном. Но если есть желание постоянно стрелять себе в ногу — средствами того же С++ это замечательно делается, ты ж сам пример привёл.

struct A {};
void f()
{ A* ptr;
  void *v;
   ..........
  ptr=(A*)v;
}

struct A {};
struct B:A { virtual void vf(){}};
void f()
{ B* ptr;
  void *v;
   ..........
  ptr=(A*)v;
}

Что скажет компилятор? Еслиб было просто ptr=v; то все былобы ОК

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

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

J>>Аргументация как-то слабовата, не находите, коллеги?

E>Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?

Правильная постановка!
Давай по пунктам? О каком именно сахаре ты говоришь?

You will always get what you always got
  If you always do  what you always did

P>Что скажет компилятор? Еслиб было просто ptr=v; то все былобы ОК
Скажет что нельзя привести A* к B*. И будет абсолютно прав. И спасибо ему за это большое.

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

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

.>>Programador wrote:
>>> Так можно , в качестве шаблонного параметра, внутри <> МС хочет с
>>> внешней линковкой, даже статик из файла не берет
.>>Т.е. это ограничение только msvc? А что в текущем стандарте?
C>Это в Стандарте такое ограничение.
конечно в стандарте, у МС послабление что класс внутри функции может код иметь.

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

E>Это где было нельзя?

P>>

P>>Myclass(x);
P>>

P>>нельзя было

E>Ну а это обозначает, что (х) имеет тип Myclass
может и раньше означало но я не натыкался на эти грабли

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

L>Э... Как бы у меня нет уверенности что освоить этот принцип легче чем подход "слева тип — справа имя переменной". Особенно для людей которые язык только-только осваивают. Ну да не суть, главная цель — чтобы намного проще было парсить С++-ный код. ИМХО, это даст толчок развитию нормальных тулзов для инструментирования кода, intellisense и т.п.

Да ладно. Надо просто не под GPL синтаксический анализатор C++ выложить...

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

.>>>Т.е. это ограничение только msvc? А что в текущем стандарте?
C>>Это в Стандарте такое ограничение.
P>конечно в стандарте, у МС послабление что класс внутри функции может код иметь.
Это как раз тоже в Стандарте. Просто параметры темплейтов обязаны иметь внешнюю линковку — вот с этим и проблема.

Cyberax wrote:

>> > Так можно , в качестве шаблонного параметра, внутри <> МС хочет с
>> > внешней линковкой, даже статик из файла не берет
> .>Т.е. это ограничение только msvc? А что в текущем стандарте?
> Это в Стандарте такое ограничение.
Ну вот, это бы исправили, а вот те предлагаемые лямбды — тихий ужас, по-моему.
И "_miles" — тоже бред. Даже для того надуманного примера уже невозможно по нормальному сделать "miles per hour".

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

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

.>И "_miles" — тоже бред. Даже для того надуманного примера уже невозможно по нормальному сделать "miles per hour".
Ну почему, перегрузить пробел и слова "per" и "hour". Помнится, Страуструп такое предлагал

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

L>>>присваивание this в конструкторе?
E>>А зачем это надо? И что жто значит? Чем new размещения не устраивает, опять же?
L>Это было ДО placement new Подробностей не помню — в "Как Я рожал ёжиков" описано.

L>>>pre- и post- функции?
E>>А может лучше пусть быстро ипонятно работает?

L>Ты меня не понял Я не агитирую за эти фичи. Это пример того, что было выкинуто из С++. Причём, насколько я понимаю, присваивание this в конструкторе было выкинуто из уже существующих компиляторов.

Еще было выкинуто ключевое слово overload. Оно, как присваивание this в конструкторе, было описано в первом издании Языка программирования C++.

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

>> Мнение, безусловно, правильное. Однако, лично у меня есть большие
>> сомнения, что в языках с явно декларируемым временем жизни объектов
>> (т.к. C++ и D) создание замыканий вообще возможно. Так что спасибо хоть
>> за это.

MZ>Помечтать что ли нельзя ...
MZ>Хотя можно же взять и добавить все переменные,
MZ>на которые лямбда ссылается, из локального контекста
MZ>ее вызова, в виде доп. неявных параметров фунции-реализации.
MZ>Ну не весь стек вверх просматривать для поиска нужной переменной,
MZ>а только из локального контекста, где определяется лямбда.
MZ>Параметры эти передавать по ссылке, если идет модификация,
MZ>то по неконстантной (хотя тут уж все равно).
MZ>Вроде бы ничего нереализуемого нет.

Как быть вот здесь:

function< void (int) >
make_closure( const char * file_name )
  {
    std::ofstream file( file_name );
    return <>(int x: &file){ file << i; }
  }

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

P>>Что скажет компилятор? Еслиб было просто ptr=v; то все былобы ОК
L>Скажет что нельзя привести A* к B*. И будет абсолютно прав. И спасибо ему за это большое.
актуально что туда поклал, а не то к чему привожу. Если я хочу получить Б значит там Б и я напишу укакзаптель типа Б. Может конечно быть такой хитрый код когда я кладу так (void *)(A*)b_ptr, но тогда нет смысла приводить к void*. 99% приведение к void * это новая память скажем битмап переменного размера. Тоесть чисто практически, не помню что приходилось приводить void* не к тому что написано слева

Cyberax wrote:

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

> .>И "_miles" — тоже бред. Даже для того надуманного примера уже
> невозможно по нормальному сделать "miles per hour".
> Ну почему, перегрузить пробел и слова "per" и "hour". Помнится,
> Страуструп такое предлагал
Во-во. Что-то вроде Proposals от 1 April какого-то года...
Надо ещё межбуквенные расстояния поперегружать, чтобы несколькими перегрузками операторов текст Войны и Мира превращался
в валидную С++ программу.

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

E>Недавно в большом флейме на linux.org.ru, посвященном интервью Страуструпа о C++0x, добрая душа дала ссылку на описание C++0x в Wikipedia: http://en.wikipedia.org/wiki/C%2B%2B0x
E>Мне понравилось, т.к. дает развернутое впечатление о грядущих возможностях без необходимости самому копаться в различных предложениях к стандарту.

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

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

>> Нормально, мне как раз нравится.
.>В таком виде лямда передаёт локальный скоп хрен знает куда. Контроль очень слабый. Подход явы — гораздо более
.>структурный и аккуратный.
Без GC по-другому нормально сделать не получится. Предполагается, что лямбды будут, в основном, для локальных функций использоваться.

>> .>И "_miles" — тоже бред. Даже для того надуманного примера уже
>> невозможно по нормальному сделать "miles per hour".
>> Ну почему, перегрузить пробел и слова "per" и "hour". Помнится,
>> Страуструп такое предлагал
.>Во-во. Что-то вроде Proposals от 1 April какого-то года...
.>Надо ещё межбуквенные расстояния поперегружать, чтобы несколькими перегрузками операторов текст Войны и Мира превращался
.>в валидную С++ программу.
Нет, эта фича уже в Perl6 есть

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

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

I>>Ты был несогласен с постом здесь

Автор: igna
Дата: 21.08.07

. А там о том, что "наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования."

E>Ну, то есть, ты не предлагал выбрасывать наследование из языка, а просто решил сообщить, что для реализации STL оно некритично?

E>Тогда это просто умышленный офтоп. Не мог же я тебя в подобном заподозрить.

E>Кстати, интересно, как ты собираешься выражать на "C++ без наследования" динамический полиморфизм или реализацию интерфейсов?..

Ты не знаешь как это работает и как это реализовать вручную?