Недавно в большом флейме на linux.org.ru, посвященном интервью Страуструпа о C++0x, добрая душа дала ссылку на описание C++0x в Wikipedia: http://en.wikipedia.org/wiki/C%2B%2B0x
Мне понравилось, т.к. дает развернутое впечатление о грядущих возможностях без необходимости самому копаться в различных предложениях к стандарту.
Из того, что меня, как говорится, "торкнуло":
* лябмды:
std::vector<int> someList;
int total = 0;
std::for_each(someList.begin(), someList.end(), <&>(x) {total += x});
честнее что-ли будет. Да и пользительнее. В смысле чудес однако не быват.
Платить как всегда придется скоростью компиляции.
E>Кстати, кто-нибудь знает, не планируется ли в C++0x что-то типа static if из языка D?
А может лучше цезарю — цезарево? В смысле #if со товарищи развить до кондиции?
Может быть, хотя люди предпочитают писать a + b, а не add(a,b). Так же для многих записи 1_mm, 3_cm, 5_kg, 0.5_litre будет гораздо приятнее.
CS>Да и пользительнее. В смысле чудес однако не быват. CS>Платить как всегда придется скоростью компиляции.
К тому времени, когда появятся компиляторы C++0x на тормоза по разбору новых лексем вряд ли можно будет обращать внимание. Тем более, что шаблоны по любому будут добавлять тормозов больше, чем эти лексемы.
E>>Кстати, кто-нибудь знает, не планируется ли в C++0x что-то типа static if из языка D?
CS>А может лучше цезарю — цезарево? В смысле #if со товарищи развить до кондиции?
Добавляют же в язык static_assert. Может и static if бы не помешал для compile-time вычислений без использования шаблонного метапрограммирования.
Кстати: нужно будет после окончания D Conference спросить у Валтера со товарищи, в чем же D будет лучше C++0x
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Никак не могу понять, зачем всё таки что-то выдумывать и наворачивать?! Чего не хватает та?! Ведь есть же C/C++ в том виде в каком он есть! И ВСЁ! НЕ НАДО БОЛЬШЕ НИЧЕГО! куча библиотек, подпрограмм, классов написано за столько лет. Всё отлично работает. И сейчас софт пишется на том C/C++ какой он щаз есть! И пусть всё будет так! Не надо ничего менять и добавлять!
"eao197" <31476@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:2625904@news.rsdn.ru... > Недавно в большом флейме на linux.org.ru, посвященном интервью Страуструпа о C++0x, добрая душа дала ссылку на описание C++0x в Wikipedia: http://en.wikipedia.org/wiki/C%2B%2B0x > Мне понравилось, т.к. дает развернутое впечатление о грядущих возможностях без необходимости самому копаться в различных предложениях к стандарту. > > Из того, что меня, как говорится, "торкнуло": > > * лябмды: >
> std::vector<int> someList;
> int total = 0;
> std::for_each(someList.begin(), someList.end(), <&>(x) {total += x});
>
> > Скорей бы это все реализовали, а то ведь и слюной захлебнуться можно > > Кстати, кто-нибудь знает, не планируется ли в C++0x что-то типа static if из языка D? >
Posted via RSDN NNTP Server 2.1 beta
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Поддержка мультитредовости на удовне языка не менее вкусна, имхо
active
{
// First block.
{
// ...
}
// Second block.for( int j = N ; j > 0 ; j-- )
{
// ...
}
// Third block.
ret = function(parameter) ;
// Other blocks.
// ...
}
All blocks are executed in parallel. After the execution of every block has ended, the program continues with a single thread.
int function( int parameter ) ;
// Calls the function and immediately returns.
IdThreadType<function> IdThread = future function(parameter) ;
// Waits for the function result.int ret = wait IdThread ;
итд
E>Скорей бы это все реализовали, а то ведь и слюной захлебнуться можно
Здравствуйте, minorlogic, Вы писали:
M>Давно пора отрезать а не добавлять ...
Вопрос: а много ли было отрезано в течении жизни c++? Не объявлено deprecated и т.д., а именно выкинуто из стандарта и потом из наиболее популярных компиляторов?
Есть такое предположение, что ничего или почти ничего.
Здравствуйте, ShaggyOwl, Вы писали:
SO>Вопрос: а много ли было отрезано в течении жизни c++? Не объявлено deprecated и т.д., а именно выкинуто из стандарта и потом из наиболее популярных компиляторов? SO>Есть такое предположение, что ничего или почти ничего.
например, такая конструкция:
struct CB {
int f( int);
};
struct CD : CB {
float f ( float );
CB::f;
};
или старая версия области видимости параметра цикла for
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
SO>>Вопрос: а много ли было отрезано в течении жизни c++? Не объявлено deprecated и т.д., а именно выкинуто из стандарта и потом из наиболее популярных компиляторов? SO>>Есть такое предположение, что ничего или почти ничего.
E>например, такая конструкция: E>
E>struct CB {
E> int f( int);
E>};
E>struct CD : CB {
E> float f ( float );
E> CB::f;
E>};
E>или старая версия области видимости параметра цикла for
Еще дефолтный тип возвращаемого значения для функции и тому подобная мелочевка.
Вместе с тем, остается масса вещей, которые делают синтаксис c++ сложным — обратная совместимость. Я к тому, что ожидать превращения c++ (в любой версии стандарта) в конфетку не приходится.
int main( )
{
shared_ptr<double> p_first(new double) ;
if( true )
{
shared_ptr<double> p_copy = p_first ;
*p_copy = 21.2 ;
} // Destruction of 'p_copy' but not of the allocated double.return ; // Destruction of 'p_first' and accordingly of the allocated double.
}
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, eao197, Вы писали:
A>Вот это явно не помешает:
A>
A>int main( )
A>{
A> shared_ptr<double> p_first(new double) ;
A> if( true )
A> {
A> shared_ptr<double> p_copy = p_first ;
A> *p_copy = 21.2 ;
A> } // Destruction of 'p_copy' but not of the allocated double.
A> return ; // Destruction of 'p_first' and accordingly of the allocated double.
A>}
A>
А что такого особенного? boost::shared_ptr и так это делает.
Здравствуйте, Smooky, Вы писали:
S>Никак не могу понять, зачем всё таки что-то выдумывать и наворачивать?! Чего не хватает та?! Ведь есть же C/C++ в том виде в каком он есть! И ВСЁ! НЕ НАДО БОЛЬШЕ НИЧЕГО! куча библиотек, подпрограмм, классов написано за столько лет. Всё отлично работает. И сейчас софт пишется на том C/C++ какой он щаз есть! И пусть всё будет так! Не надо ничего менять и добавлять!
Аргументация как-то слабовата, не находите, коллеги?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Smooky, Вы писали:
S>>Никак не могу понять, зачем всё таки что-то выдумывать и наворачивать?! Чего не хватает та?! Ведь есть же C/C++ в том виде в каком он есть! И ВСЁ! НЕ НАДО БОЛЬШЕ НИЧЕГО! куча библиотек, подпрограмм, классов написано за столько лет. Всё отлично работает. И сейчас софт пишется на том C/C++ какой он щаз есть! И пусть всё будет так! Не надо ничего менять и добавлять!
J>Аргументация как-то слабовата, не находите, коллеги?
Егор, ты правда считаешь этот крик души хорошо аргументированным?
Здравствуйте, igna, Вы писали:
M>>>Давно пора отрезать а не добавлять ...
RO>>Что именно?
I>Наследование. STL, например, можно написать без наследования.
Какое именно наследование в STL тебе не нравится?
I>А из библиотеки — потоки ввода-вывода.
You will always get what you always got
If you always do what you always did
Re[2]: C++0x в Wikipedia
От:
Аноним
Дата:
20.08.07 17:58
Оценка:
Здравствуйте, alzt, Вы писали:
A>Вот это явно не помешает:
Это обычный умный указатель, который уже давно есть в бусте.
Посмотри, там (в бусте) много чего вкусного.
Например boost::weak_ptr тоже очень полезная вещь.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Ka3a4oK, Вы писали:
KK>>Пока в 2009 году выйдет стандарт, пока компиляторы его поддержат...
RO>Это да. 2 года до стандарта, еще 5 лет для совместимости со старыми компиляторами…
RO>P. S. http://www.generic-programming.org/software/ConceptGCC/
7 лет — большой срок. Не будет ли это холостым выстрелом? Уже сейчас много языков поддерживают многие или все фичи C++0x. Я сам, попробовав Nemerle, теперь волком вою на C++. Боюсь, к тому времени С++ из General Purpose языка превратится в узконишевый.
Здравствуйте, jazzer, Вы писали:
J>>Аргументация как-то слабовата, не находите, коллеги? J>Егор, ты правда считаешь этот крик души хорошо аргументированным?
Ну, во всяком случае, он мне понятен
Да и мотивы вполне ясны...
В целом язык С++ когда-нибудь утонет под грузом своей сложности. Но я, правда, думаю, что это будет ещё не сейчас
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
J>Какое именно наследование в STL тебе не нравится?
У Microsoft set унаследован от _Tree, без этого наследования можно обойтись. Правда я не говорю, что оно мне не нравится.
J>Точно. Все — в сад (в смысле, в printf)
Ну да, прежде чем отправить iostreams "в сад" неплохо бы сначала поиметь в стандарте хорошую библиотеку ввода-вывода.
Здравствуйте, Ka3a4oK, Вы писали:
KK>7 лет — большой срок. Не будет ли это холостым выстрелом? Уже сейчас много языков поддерживают многие или все фичи C++0x. Я сам, попробовав Nemerle, теперь волком вою на C++. Боюсь, к тому времени С++ из General Purpose языка превратится в узконишевый.
Какие такие фичи? Надеюсь никаких всеже не будет. Не ужны в нем фичи , которые в других языках есть. Вот приходят и просят переписать на С с других языков, в которых ну очень много фичей, только работает медленно. В АДЕ кстати были встроенные "12_Миль". И где она эта АДА?
По диагонали просмотрел драфт вроде ничего особенного там нет. Инициализация членов, предварительный конструктор, decltype все это нужно было давно вводить.
Здравствуйте, Programador, Вы писали:
P>По диагонали просмотрел драфт вроде ничего особенного там нет. Инициализация членов, предварительный конструктор, decltype все это нужно было давно вводить.
Дык, лучше поздно, чем никогда.
P>Провда переписка настораживает.
Что именно?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
P>>Провда переписка настораживает.
E>Что именно?
Помоему у некотырых идеи превратить С-рунтайм в аналог НЕТ-фраймворк.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>Какое именно наследование в STL тебе не нравится?
I>У Microsoft set унаследован от _Tree, без этого наследования можно обойтись. Правда я не говорю, что оно мне не нравится.
ну так это вопросы к Microsoft, а не к STL.
J>>Точно. Все — в сад (в смысле, в printf)
I>Ну да, прежде чем отправить iostreams "в сад" неплохо бы сначала поиметь в стандарте хорошую библиотеку ввода-вывода.
желательно такую же удобную, как operator<<, который ты определяешь один раз, а он работает везде и не рожает кучу левых промежуточных строчек, как какой-нть метод типа to_string
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, eao197, Вы писали:
E>>Недавно в большом флейме на linux.org.ru, посвященном интервью Страуструпа о C++0x, добрая душа дала ссылку на описание C++0x в Wikipedia: http://en.wikipedia.org/wiki/C%2B%2B0x
CS>Что-то вот тут туфта (извиняюсь) нарисована:
CS>Closure variables need not be references to external variables. For example:
CS>
CS>This removes elements after the running total reaches twenty, including the first element to reach 20.
CS>Что-то мне говорит что myTotal при каждом вызове будет 0. Иначе я совсем не понимаю эту нотацию.
После ":" можно задать список переменных, который будет "привязан" к объекту и каждая переменная может быть инициализирована при создании объекта. Но это, по моему, никак не связано с замыканиями.
Вот если бы можно было как-то так:
typedef int(*Adder)(int);
Adder makeAdder(int y){ return lambda(int x){ return y + x; }}
add3 = makeAdder(3);
int r = add3(5);
//результат 8
Ну и добавить сюда шаблоны, чтобы не привязываться к какому-то определенному типу.
В первом случае (с remove_if), желательно вообще тип не указывать, должен быть такой-же как и у контейнера.
Например так:
Здравствуйте, c-smile, Вы писали:
E>>Недавно в большом флейме на linux.org.ru, посвященном интервью Страуструпа о C++0x, добрая душа дала ссылку на описание C++0x в Wikipedia: http://en.wikipedia.org/wiki/C%2B%2B0x
CS>Что-то вот тут туфта (извиняюсь) нарисована:
CS>Closure variables need not be references to external variables. For example:
CS>
CS>This removes elements after the running total reaches twenty, including the first element to reach 20.
CS>Что-то мне говорит что myTotal при каждом вызове будет 0. Иначе я совсем не понимаю эту нотацию.
Насколько я понимаю, в Wikipedia в двух местах указали разный синтаксис. Конкретно в этом случае между декларацией int x и int myTotal была не запятая, а двоеточие:
я так понял, что двоеточие -- это как раз разделитель формальных параметров, от переменных замыкания. Т.е. myTotal -- это переменная замыкания с начальным значением 0. И от вызова к вызову myTotal сохраняет свое значение.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
. Собственно я не о том, что нужно писать STL без наследования, а о том, что наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования.
. Собственно я не о том, что нужно писать STL без наследования, а о том, что наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования. >
На супермегаезыке "С" тоже много-много чего можно написать. Но ну его нафиг
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
. Собственно я не о том, что нужно писать STL без наследования, а о том, что наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования.
Это что, религия новая такая — ни в коем случае не использовать наследование? типа никогда не использовать невиртуальных деструкторов, goto, макросов и т.д?
Например, CRTP целиком базируется на наследовании — крайне полезная вещь.
Да и вообще я не вижу других способов, кроме наследования, для инжектирования одной строкой кучи всякой всячины в твой класс.
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, eao197, Вы писали:
P>>>Провда переписка настораживает.
E>>Что именно? P>Помоему у некотырых идеи превратить С-рунтайм в аналог НЕТ-фраймворк.
Там в рантайм только потоки, по-моему, добавляться. А что ещё?
Всякие там делегирования конструкторов, rvalue ссылки, статик ассёрты и т.д. это ж всё не рантайм.
Всякие хэш-мапы тоже в библиотеку шаблонов, а не в рантайм.
Ну потоки — это вообще самый джентельменский минимум. Внешними библиотеками они плохо/не реализуются. Т.ч. всё нормально. Не переживай
Даже сокеты уже можно более-менее внешними библиотеками реализовывать. Вот boost.asio немного подрастёт, и будет у нас даже портируемый интерфейс
> S>На супермегаезыке "С" тоже много-много чего можно написать. Но ну его нафиг > > Речь не о том, что можно в принципе. Речь о том, что "много-много чего" без наследования написать не сложнее чем с ним.
Вообще-то плюсы задумывались как ОО язык. А ОО без наследования не бывает. Может, вам просто нужен какой-нибудь другой язык?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>Вообще-то плюсы задумывались как ОО язык. А ОО без наследования не бывает. Может, вам просто нужен какой-нибудь другой язык?
Как мультипарадигменный. Там сразу было как минимум 2 парадигмы И в одной из них нет наследования
PS Это не значит, что я поддерживаю отказ от наследования
>S>Вообще-то плюсы задумывались как ОО язык. А ОО без наследования не бывает. Может, вам просто нужен какой-нибудь другой язык? > Как мультипарадигменный. Там сразу было как минимум 2 парадигмы И в одной из них нет наследования > PS Это не значит, что я поддерживаю отказ от наследования
Про мульпарадигменность Страуструп потом придумал А сначала ему просто была нужна Симула, быстрая как С.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
. Собственно я не о том, > что нужно писать STL без наследования, а о том, что наследование можно > выбросить из языка, и все же такую непростую библиотеку как STL можно > будет написать без какого-либо изменения ее интерфейса. И еще > много-много чего можно написать без наследования.
А зачем?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, igna, Вы писали:
I>Егор похоже полагает, будто STL нельзя написать без наследования.
Домысливать за других -- занятие неблагодарное.
Благодарноезанятие -- понимать всё прямо. Ты высказал мысль, что в С++ излишним является наследование, а я с этим не согласен. А при чём тут возможность написать STL --
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, eao197, Вы писали:
E>Насколько я понимаю, в Wikipedia в двух местах указали разный синтаксис. Конкретно в этом случае между декларацией int x и int myTotal была не запятая, а двоеточие: E>
E>я так понял, что двоеточие -- это как раз разделитель формальных параметров, от переменных замыкания. Т.е. myTotal -- это переменная замыкания с начальным значением 0. И от вызова к вызову myTotal сохраняет свое значение.
Ага, понятно, спасибо.
<>(int x: int myTotal = 0)
Как-то это все грустно. D это менее замороченно делает. В всяком случае в нотации.
В принципе в языках в которых function не first class object (C, С++, D) толково замыкания не сделать.
То что в D сделано это максимум того что мы можем получить без fibers и другой эзотерики. Я так думаю.
Здравствуйте, Erop, Вы писали:
E>Благодарноезанятие -- понимать всё прямо. Ты высказал мысль, что в С++ излишним является наследование, а я с этим не согласен.
. А там о том, что "наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования."
CS>Как-то это все грустно. D это менее замороченно делает. В всяком случае в нотации.
Не знаю, мне показалось, что хрен редьки не слаще. В D есть одна классная штука -- это lazy arguments. Вот она по синтаксису явно симпатичнее, чем C++ лямбды. Но, как мне помнится, у lazy arguments есть какая-то специфическая область применения (ну т.е. не везде ее можно засунуть, например, в lazy-лямбду нельзя аргументы передавать). Поэтому приходится использовать делегаты. А синтаксис делегатов не многим лучше синтаксиса C++ лямбд (имхо, конечно). А если вспомнить, что в D есть отдельно делегаты и отдельно указатели на функции, то зоопарк получается еще тот
К тому же у меня почему-то есть впечатление, что где-то было обсуждение вредности lazy arguments и о том, что хорошо было бы их выбросить и оставить только делегаты.
И еще, если мне мой склероз не изменяет, в D нет возможности объявить переменную делегата, которая бы сохраняла свое значение от вызова к вызову. Ну т.е.:
import tango.io.Stdout;
void each(T)( T[] array, void delegate(T item) dg )
{
foreach( a; array )
dg( a );
}
void main()
{
int[] i = [ 1, 2, 3, 4 ];
i.each( delegate void( int a ) {
int x;
Stdout.formatln( "x={0}, a={1}", x, a );
x = a;
} );
}
будет печатать:
x=0, a=1
x=0, a=2
x=0, a=3
x=0, a=4
Для того, чтобы x сохраняла свое значение ее нужно объявить вне делегата, т.е. как переменную в main(). C++ подход, здесь, имхо, удобнее. Т.к. позволяет с помощью copy-and-paste переносить тело лямбды из одно контекста в другой более просто.
CS>В принципе в языках в которых function не first class object (C, С++, D) толково замыкания не сделать. CS>То что в D сделано это максимум того что мы можем получить без fibers и другой эзотерики. Я так думаю.
Имхо, для замыкания прежде всего нужен толковый сборщик мусора и размещения всех объектов в хипе (за исключением примитивных типов). Это есть в Scala, поэтому в Scala есть толковые замыкания. Даже не смотря на то, что в JVM function так же не first class object (afaik) -- Scala для каждого замыкания объект типа Function[...] генерирует и метод apply() из него дергает.
А вообще -- редиски они, эти D-строители. Скоро год как якобы стабильный релиз 1.0 вышел, а язык как не был готов к промышленному использованию, так и не готов сейчас. Павбывавбы!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 пишет:
> Из того, что меня, как говорится, "торкнуло": > > * лябмды: > > std::vector<int> someList; > int total = 0; > std::for_each(someList.begin(), someList.end(), <&>(x) {total += x});
Моё мнение такое — лямбда конечно хорошо, уже лучше, чем ничего,
но без кложуров (closure) лямбда — это все равно, что рубанок
без ручки — строгать можно, но только очень потихоньку.
>>S>Вообще-то плюсы задумывались как ОО язык. А ОО без наследования не бывает. Может, вам просто нужен какой-нибудь другой язык? >> Как мультипарадигменный. Там сразу было как минимум 2 парадигмы И в одной из них нет наследования >> PS Это не значит, что я поддерживаю отказ от наследования S>Про мульпарадигменность Страуструп потом придумал А сначала ему просто была нужна Симула, быстрая как С.
ну да. И потом он взял и добавил в С классы. И получился двухпарадигменный язык. Сейчас в нем уже 3 парадигмы а введут лямбды, может и под 4 закосит :D
Здравствуйте, MasterZiv, Вы писали:
>> Из того, что меня, как говорится, "торкнуло": >> >> * лябмды: >> >> std::vector<int> someList; >> int total = 0; >> std::for_each(someList.begin(), someList.end(), <&>(x) {total += x});
MZ>Моё мнение такое — лямбда конечно хорошо, уже лучше, чем ничего, MZ>но без кложуров (closure) лямбда — это все равно, что рубанок MZ>без ручки — строгать можно, но только очень потихоньку.
Мнение, безусловно, правильное. Однако, лично у меня есть большие сомнения, что в языках с явно декларируемым временем жизни объектов (т.к. C++ и D) создание замыканий вообще возможно. Так что спасибо хоть за это.
Как показывает практика D даже такие лямбды -- это не просто хорошо, а очень хорошо.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> Не знаю, мне показалось, что хрен редьки не слаще. В D есть одна > классная штука -- это lazy arguments. Вот она по синтаксису явно > симпатичнее, чем C++ лямбды. Но, как мне помнится, у lazy arguments есть
А по-моему для такого языка лучше всего подойдёт то что в яве — анонимные классы.
Или хотя бы возможность определять класс внутри функции.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>eao197 wrote:
>> Не знаю, мне показалось, что хрен редьки не слаще. В D есть одна >> классная штука -- это lazy arguments. Вот она по синтаксису явно >> симпатичнее, чем C++ лямбды. Но, как мне помнится, у lazy arguments есть .>А по-моему для такого языка лучше всего подойдёт то что в яве — анонимные классы. .>Или хотя бы возможность определять класс внутри функции.
AFAIK возможность определять класс внутри функции уже есть.
Здравствуйте, ., Вы писали:
>> Не знаю, мне показалось, что хрен редьки не слаще. В D есть одна >> классная штука -- это lazy arguments. Вот она по синтаксису явно >> симпатичнее, чем C++ лямбды. Но, как мне помнится, у lazy arguments есть .>А по-моему для такого языка лучше всего подойдёт то что в яве — анонимные классы.
Сомневаюсь.
.>Или хотя бы возможность определять класс внутри функции.
Это и сейчас можно. Но с ограничениями -- все что связано с шаблонами не может быть определено внутри функции.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>Аргументация как-то слабовата, не находите, коллеги?
Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?
SO>Вопрос: а много ли было отрезано в течении жизни c++? Не объявлено deprecated и т.д., а именно выкинуто из стандарта и потом из наиболее популярных компиляторов? SO>Есть такое предположение, что ничего или почти ничего.
присваивание this в конструкторе?
pre- и post- функции?
Здравствуйте, nen777w, Вы писали:
S>>Никак не могу понять, зачем всё таки что-то выдумывать и наворачивать?! Чего не хватает та?! N>мне сильно не хватает typeof
Мне, при использовании STL, тоже
В этом смысле авторы стандарта проявили непоследовательность. Раз уж они завели в стандарте STL, то надо было и typeof.
Другое дело, что для себя я выбор сделал. STL по возможности не использую и в результате мне всего хватает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Left2, Вы писали:
L>присваивание this в конструкторе?
А зачем это надо? И что жто значит? Чем new размещения не устраивает, опять же?
L>pre- и post- функции?
А может лучше пусть быстро ипонятно работает?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
. А там о том, что "наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования."
Ну, то есть, ты не предлагал выбрасывать наследование из языка, а просто решил сообщить, что для реализации STL оно некритично?
Тогда это просто умышленный офтоп. Не мог же я тебя в подобном заподозрить.
Кстати, интересно, как ты собираешься выражать на "C++ без наследования" динамический полиморфизм или реализацию интерфейсов?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
M>>Давно пора отрезать а не добавлять ... RO>Что именно?
— "сишные" касты
— виртуальное наследование
Я бы ещё синтаксис сделал максимально более регулярным, чтобы максимально упростить его парсинг и понимание, типа
int[] a; вместо int a[]; — эти пляски с лево-право-ассоциативностью здОрово всё усложняют.
В идеале чтобы синтаксис парсился Yacc/Bizon/ANTLR и иже с ними без особых плясок с бубном.
Естественно что это потребует режима "совместимости со старым кодом" для компилятора.
Всё это ИМХО, конечно — не пинайте сильно.
L>>присваивание this в конструкторе? E>А зачем это надо? И что жто значит? Чем new размещения не устраивает, опять же?
Это было ДО placement new Подробностей не помню — в "Как Я рожал ёжиков" описано.
L>>pre- и post- функции? E>А может лучше пусть быстро ипонятно работает?
Ты меня не понял Я не агитирую за эти фичи. Это пример того, что было выкинуто из С++. Причём, насколько я понимаю, присваивание this в конструкторе было выкинуто из уже существующих компиляторов.
eao197 wrote:
>> > Не знаю, мне показалось, что хрен редьки не слаще. В D есть одна >> > классная штука -- это lazy arguments. Вот она по синтаксису явно >> > симпатичнее, чем C++ лямбды. Но, как мне помнится, у lazy arguments есть > .>А по-моему для такого языка лучше всего подойдёт то что в яве — > анонимные классы. > Сомневаюсь.
По-моему, самое правильное для императивного ООП-языка, и уж тем более для языка с явным менеджментом памяти/ресурсов.
Лямды — для функциональщиков, делегаты — для индусов.
> .>Или хотя бы возможность определять класс внутри функции. > > Это и сейчас можно. Но с ограничениями -- все что связано с шаблонами не > может быть определено внутри функции.
Можно, а толку никакого, пользоваться-то практически невозможно.
Хочется вот так:
std::vector<std::string> v;
struct
{
bool operator()(const std::string &s1, const std::string &s2)
{
return s1 > s2;
}
} pred;
std::sort(v.begin(), v.end(), pred);// error C2919: illegal use of anonymous local type in template instantiation
Здравствуйте, Left2, Вы писали:
L>Я бы ещё синтаксис сделал максимально более регулярным, чтобы максимально упростить его парсинг и понимание, типа L>int[] a; вместо int a[]; — эти пляски с лево-право-ассоциативностью здОрово всё усложняют. L>В идеале чтобы синтаксис парсился Yacc/Bizon/ANTLR и иже с ними без особых плясок с бубном.
Вообще-то ещё со времён K&R в C есть правило: "Декларация идентефикатора выглядит как его использование".
То есть запись "int a[5]", обозначает, что если к a применить оператор [], то получится int...
Хорошее, привычное поведение. Зачем бы его рушить?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Что мешает использовать OpenMP? Получается вполне выразительно.
Здравствуйте, dip_2000, Вы писали:
_>Поддержка мультитредовости на удовне языка не менее вкусна, имхо
_>
_>active
_>{
_> // First block.
_> {
_> // ...
_> }
_> // Second block.
_> for( int j = N ; j > 0 ; j-- )
_> {
_> // ...
_> }
_> // Third block.
_> ret = function(parameter) ;
_> // Other blocks.
_> // ...
_>}
_>All blocks are executed in parallel. After the execution of every block has ended, the program continues with a single thread.
_>
_>
_>int function( int parameter ) ;
_>// Calls the function and immediately returns.
_>IdThreadType<function> IdThread = future function(parameter) ;
_>// Waits for the function result.
_>int ret = wait IdThread ;
_>
_>итд
E>>Скорей бы это все реализовали, а то ведь и слюной захлебнуться можно _>
eao197 пишет:
> Мнение, безусловно, правильное. Однако, лично у меня есть большие > сомнения, что в языках с явно декларируемым временем жизни объектов > (т.к. C++ и D) создание замыканий вообще возможно. Так что спасибо хоть > за это.
Помечтать что ли нельзя ...
Хотя можно же взять и добавить все переменные,
на которые лямбда ссылается, из локального контекста
ее вызова, в виде доп. неявных параметров фунции-реализации.
Ну не весь стек вверх просматривать для поиска нужной переменной,
а только из локального контекста, где определяется лямбда.
Параметры эти передавать по ссылке, если идет модификация,
то по неконстантной (хотя тут уж все равно).
Вроде бы ничего нереализуемого нет.
Здравствуйте, MasterZiv, Вы писали:
MZ>Помечтать что ли нельзя ... MZ>Хотя можно же взять и добавить все переменные, MZ>на которые лямбда ссылается, из локального контекста MZ>ее вызова, в виде доп. неявных параметров фунции-реализации. MZ>Ну не весь стек вверх просматривать для поиска нужной переменной, MZ>а только из локального контекста, где определяется лямбда. MZ>Параметры эти передавать по ссылке, если идет модификация, MZ>то по неконстантной (хотя тут уж все равно). MZ>Вроде бы ничего нереализуемого нет.
Да помоему в Алголе так и было, типов только там не было
> L>Я бы ещё синтаксис сделал максимально более регулярным, чтобы максимально упростить его парсинг и понимание, типа > L>int[] a; вместо int a[]; — эти пляски с лево-право-ассоциативностью здОрово всё усложняют. > L>В идеале чтобы синтаксис парсился Yacc/Bizon/ANTLR и иже с ними без особых плясок с бубном. > > Вообще-то ещё со времён K&R в C есть правило: "Декларация идентефикатора выглядит как его использование". > > То есть запись "int a[5]", обозначает, что если к a применить оператор [], то получится int... > Хорошее, привычное поведение. Зачем бы его рушить?
Это правило давным-давно порушили, правда всего лишь в одном частном случае... Но я из-за этого при знакомстве с С++ долго в ссылки не врубался
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Left2, Вы писали:
M>>>Давно пора отрезать а не добавлять ... RO>>Что именно?
L>- "сишные" касты L>- виртуальное наследовани
А это чем мешает?
Зачем кстати неявное преобразование из void* убрали? чтоб лишний раз тип писать и при этом ошибаться? Или потому что из void* преобразование небезопасное. Но это и так все знают, всеравно что к снотворному писать предупреждение что может вызвать сонливость
Недавно КОТ рульный код показал
template<>
{ void *v
operato T*(){ return static_cast<>(v);}
};
Здравствуйте, Erop, Вы писали:
E>Вообще-то ещё со времён K&R в C есть правило: "Декларация идентефикатора выглядит как его использование".
E>То есть запись "int a[5]", обозначает, что если к a применить оператор [], то получится int... E>Хорошее, привычное поведение. Зачем бы его рушить?
Ну раньше
Allow 'sizeof' to work on members of classes without an explicit object
In standard C++, the sizeof operation can be used on types and objects. But it cannot be used to do the following:
struct SomeType { OtherType member; };
sizeof(SomeType::member); //Does not work.
#include <stdio.h>
struct B {
int b[100];
};
struct A {
B a;
};
#define MEMBER_SIZEOF(Class,Member) \
sizeof(reinterpret_cast<Class*>(0x0)->Class::Member)
int main () {
printf("%d\n",MEMBER_SIZEOF(A,a));
return 0;
}
msvc80,gcc4.1,2,comeau 4.*.*
Это просто такое "кривое" ограничение?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
N>>мне сильно не хватает typeof E>Мне, при использовании STL, тоже E>В этом смысле авторы стандарта проявили непоследовательность. Раз уж они завели в стандарте STL, то надо было и typeof.
Дело не только в STL. Я уже как то поднимал тему. Есть DLL с туевой хучей функций есть хидер к ней с этой же туевой хучей функций. Надо:
загружать DLL динамически.
Без typeof это всё дело выливается в переписывании туевой хучей сигнатур для определения поинтеров на эти функции.
Programador wrote: > Так можно , в качестве шаблонного параметра, внутри <> МС хочет с > внешней линковкой, даже статик из файла не берет
Т.е. это ограничение только msvc? А что в текущем стандарте?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
> Помечтать что ли нельзя ... > Хотя можно же взять и добавить все переменные, > на которые лямбда ссылается, из локального контекста > ее вызова, в виде доп. неявных параметров фунции-реализации. > Ну не весь стек вверх просматривать для поиска нужной переменной, > а только из локального контекста, где определяется лямбда. > Параметры эти передавать по ссылке, если идет модификация, > то по неконстантной (хотя тут уж все равно).
Вот это и есть анонимные классы, как в Java. Использоваться может только то, что определено в классе, а не в контексте.
"Правильные лябмды" — по-моему очень проблематично ложатся в С++. http://rsdn.ru/forum/message/2630322.aspx
Здравствуйте, ., Вы писали:
.>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>Потому что небезопасные куски программы должны бросаться в глаза. А если ты ошибёшься в типе — тебе скажет об этом компилятор, а не программа грохнется где-то у клиента на далеко за океаном. Но если есть желание постоянно стрелять себе в ногу — средствами того же С++ это замечательно делается, ты ж сам пример привёл.
Здравствуйте, elcste, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Аргументация как-то слабовата, не находите, коллеги?
E>Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?
Правильная постановка!
Давай по пунктам? О каком именно сахаре ты говоришь?
P>Что скажет компилятор? Еслиб было просто ptr=v; то все былобы ОК
Скажет что нельзя привести A* к B*. И будет абсолютно прав. И спасибо ему за это большое.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, ., Вы писали:
.>>Programador wrote: >>> Так можно , в качестве шаблонного параметра, внутри <> МС хочет с >>> внешней линковкой, даже статик из файла не берет .>>Т.е. это ограничение только msvc? А что в текущем стандарте? C>Это в Стандарте такое ограничение.
конечно в стандарте, у МС послабление что класс внутри функции может код иметь.
Здравствуйте, Left2, Вы писали:
L>Э... Как бы у меня нет уверенности что освоить этот принцип легче чем подход "слева тип — справа имя переменной". Особенно для людей которые язык только-только осваивают. Ну да не суть, главная цель — чтобы намного проще было парсить С++-ный код. ИМХО, это даст толчок развитию нормальных тулзов для инструментирования кода, intellisense и т.п.
Да ладно. Надо просто не под GPL синтаксический анализатор C++ выложить...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Programador, Вы писали:
.>>>Т.е. это ограничение только msvc? А что в текущем стандарте? C>>Это в Стандарте такое ограничение. P>конечно в стандарте, у МС послабление что класс внутри функции может код иметь.
Это как раз тоже в Стандарте. Просто параметры темплейтов обязаны иметь внешнюю линковку — вот с этим и проблема.
Cyberax wrote:
>> > Так можно , в качестве шаблонного параметра, внутри <> МС хочет с >> > внешней линковкой, даже статик из файла не берет > .>Т.е. это ограничение только msvc? А что в текущем стандарте? > Это в Стандарте такое ограничение.
Ну вот, это бы исправили, а вот те предлагаемые лямбды — тихий ужас, по-моему.
И "_miles" — тоже бред. Даже для того надуманного примера уже невозможно по нормальному сделать "miles per hour".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
>> Это в Стандарте такое ограничение. .>Ну вот, это бы исправили, а вот те предлагаемые лямбды — тихий ужас, по-моему.
Нормально, мне как раз нравится.
.>И "_miles" — тоже бред. Даже для того надуманного примера уже невозможно по нормальному сделать "miles per hour".
Ну почему, перегрузить пробел и слова "per" и "hour". Помнится, Страуструп такое предлагал
Здравствуйте, Left2, Вы писали:
L>>>присваивание this в конструкторе? E>>А зачем это надо? И что жто значит? Чем new размещения не устраивает, опять же? L>Это было ДО placement new Подробностей не помню — в "Как Я рожал ёжиков" описано.
L>>>pre- и post- функции? E>>А может лучше пусть быстро ипонятно работает?
L>Ты меня не понял Я не агитирую за эти фичи. Это пример того, что было выкинуто из С++. Причём, насколько я понимаю, присваивание this в конструкторе было выкинуто из уже существующих компиляторов.
Еще было выкинуто ключевое слово overload. Оно, как присваивание this в конструкторе, было описано в первом издании Языка программирования C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, MasterZiv, Вы писали:
>> Мнение, безусловно, правильное. Однако, лично у меня есть большие >> сомнения, что в языках с явно декларируемым временем жизни объектов >> (т.к. C++ и D) создание замыканий вообще возможно. Так что спасибо хоть >> за это.
MZ>Помечтать что ли нельзя ... MZ>Хотя можно же взять и добавить все переменные, MZ>на которые лямбда ссылается, из локального контекста MZ>ее вызова, в виде доп. неявных параметров фунции-реализации. MZ>Ну не весь стек вверх просматривать для поиска нужной переменной, MZ>а только из локального контекста, где определяется лямбда. MZ>Параметры эти передавать по ссылке, если идет модификация, MZ>то по неконстантной (хотя тут уж все равно). MZ>Вроде бы ничего нереализуемого нет.
Здравствуйте, 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 какого-то года...
Надо ещё межбуквенные расстояния поперегружать, чтобы несколькими перегрузками операторов текст Войны и Мира превращался
в валидную С++ программу.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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 есть
. А там о том, что "наследование можно выбросить из языка, и все же такую непростую библиотеку как STL можно будет написать без какого-либо изменения ее интерфейса. И еще много-много чего можно написать без наследования."
E>Ну, то есть, ты не предлагал выбрасывать наследование из языка, а просто решил сообщить, что для реализации STL оно некритично?
E>Тогда это просто умышленный офтоп. Не мог же я тебя в подобном заподозрить.
E>Кстати, интересно, как ты собираешься выражать на "C++ без наследования" динамический полиморфизм или реализацию интерфейсов?..
Ты не знаешь как это работает и как это реализовать вручную?
Не все в этом мире можно выразить с помощью нулей и единиц...
Cyberax wrote:
>> > Нормально, мне как раз нравится. > .>В таком виде лямда передаёт локальный скоп хрен знает куда. Контроль > очень слабый. Подход явы — гораздо более > .>структурный и аккуратный. > Без GC по-другому нормально сделать не получится. Предполагается, что
Вот мерзкое слово!
> лямбды будут, в основном, для локальных функций использоваться.
Вот лямбды эти проблемы имеют по самые уши. А с анонимными классами — самое то. Можно даже более ограничено, чем в яве.
Там локальные переменные как final доступны (удобно, если есть gc), а в С++ можно убрать и это. Если надо обратится к
переменной — помещай её как член этого класса и в конструкторе передавай локальную (возможно по неконстантной ссылке,
если хочется), сразу чётко видно где куда какие ресурсы идут.
>> > невозможно по нормальному сделать "miles per hour". >> > Ну почему, перегрузить пробел и слова "per" и "hour". Помнится, >> > Страуструп такое предлагал > .>Во-во. Что-то вроде Proposals от 1 April какого-то года... > .>Надо ещё межбуквенные расстояния поперегружать, чтобы несколькими > перегрузками операторов текст Войны и Мира превращался > .>в валидную С++ программу. > Нет, эта фича уже в Perl6 есть
Вот судя по некоторым фичам С++ его догоняет...
А этот бред: assoc_laguerre, assoc_legendre, beta, comp_ellint_1,...
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeniy13, Вы писали:
E>>Кстати, интересно, как ты собираешься выражать на "C++ без наследования" динамический полиморфизм или реализацию интерфейсов?..
E>Ты не знаешь как это работает и как это реализовать вручную?
Э-э-э? Что значит "вручную"? На бумажке, путешествую пальцем по блок-схеме?
Или месье призывает прогать на ассемблере?
Конечно в C++ не очень выразительно сделана реализация парадигмы "этот объект реализует то-то интерфейс", но как-то сделана. Неужели твоё предложение чем-то лучше?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Nazik, Вы писали:
N>Что мешает использовать OpenMP? Получается вполне выразительно.
1. Скажу честно — не знаю что это, хотя по названию можно догадаться
2. Его "дополнительность" — это не часть стандарта.
3. У него ведь и конкуренты есть ? Почему не использовать другие библиотеки ?
Речь о стандарте, а не о библиотеках. Библиотеки хорошо, но если стандарт стоит на месте, на одних библиотеках далеко не уедешь.
Здравствуйте, remark, Вы писали:
R>Это "извращение" было в языке с самого начала, и ты сам его постоянно используешь, когда пишешь литералы типа 1u, 1ll, 1ull, 1.0f и т.д.
Но это же вроде как для совместимости с C?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, nen777w, Вы писали:
N>Дело не только в STL. Я уже как то поднимал тему. Есть DLL с туевой хучей функций есть хидер к ней с этой же туевой хучей функций. Надо: N>загружать DLL динамически. N>Без typeof это всё дело выливается в переписывании туевой хучей сигнатур для определения поинтеров на эти функции.
Здравствуйте, Left2, Вы писали:
L>Ну да не суть, главная цель — чтобы намного проще было парсить С++-ный код. ИМХО, это даст толчок развитию нормальных тулзов для инструментирования кода, intellisense и т.п.
+1 и это относится не только к массивам.
Имхо, хорошим показателем сложности синтаксиса языка, является количество и качество различных тулов для программистов (плагины для рефакторинга, кодогенерации, анализа кода и т.д.). Как мне кажется, у C++ здесь дела обстоят не очень здорово.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Так тут тебе и typeof/decltype не поможет.
Ну он наверное хочет писать typeof( имяФункцииОбъявленноеВХедереDll )
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
O>>Что это за ИЗВРАЩЕНИЕ?! :wow: O>>Как Страуструп мог допустить такое???
R>Это "извращение" было в языке с самого начала, и ты сам его постоянно используешь, когда пишешь литералы типа 1u, 1ll, 1ull, 1.0f и т.д.
А я согласен с предыдущим комментарием. Какая вероятность того, что библиотека SuperPhysics определяет operator "kg"? Какая вероятность того, что библиотека CoolPhysics определяет operator "kg"? А если ты используешь обе?
Это я к тому, что без пространств имен нынче никак, а где они здесь?
Пусть уже будет sp::Force F = sp::kg(0.102) * sp::constants::g().
Roman Odaisky wrote:
> Ну почему же. > static bool myCompare(std::string const& s1, std::string const& s2) > Здесь разве что проблема — не всякий компилятор заинлайнит вызов функции > по указателю.
Самая проблема выделена, это уже не функтор.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Roman Odaisky, Вы писали:
RO>А я согласен с предыдущим комментарием. Какая вероятность того, что библиотека SuperPhysics определяет operator "kg"? Какая вероятность того, что библиотека CoolPhysics определяет operator "kg"? А если ты используешь обе?
Здравствуйте, _Obelisk_, Вы писали:
_O_>Мда... полно всего понапихали. Интересно только, сколько времени уйдет на создание стабильного компилятора с такого языка.
По крайней мере, черновики нового стандарта уже есть, а до его выхода еще 2 года. Уже существует ConceptGCC, и Майкрософтовцы затеяли очередную перестройку внутренностей своего компилятора, которая, они обещают, поможет им легко и быстро прикрутить новые фичи.
1. http://openmp.org
2. OpenMP вполне можно считать индустриальным стандартом в распараллеливании существующих последовательных приложений приложений
3. Опять же, конкуренты конечно есть, но OpenMP поддерживается всеми распространенными компилерами (по крайней мере Microsoft, Intel, GNU), поэтому, вполне можно считать его чем-то очень стандартным.
Здравствуйте, dip_2000, Вы писали:
_>1. Скажу честно — не знаю что это, хотя по названию можно догадаться _>2. Его "дополнительность" — это не часть стандарта. _>3. У него ведь и конкуренты есть ? Почему не использовать другие библиотеки ?
_>Речь о стандарте, а не о библиотеках. Библиотеки хорошо, но если стандарт стоит на месте, на одних библиотеках далеко не уедешь.
RO>А UB-то зачем?
А где оно тут? sizeof вроде бы вычисляет выражение в compile-time'е. RO>[c]template <class X> RO>X& make();
RO>#define MEMBER_SIZEOF1(cl, member) sizeof(make<cl>().cl::member)
если множественное наследование, должно помоч
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, jazzer, Вы писали:
E>>Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?
J>Правильная постановка! J>Давай по пунктам? О каком именно сахаре ты говоришь?
О том, что упоминал OP, — лямбда в core language, литералы пользовательских типов. Но смысл-то не в этом, смысл в том, что я каждый раз изумляюсь, услышав, что скоро C++ окажется в очень узкой нише и т.п. По моим представлениям, он уже давно в этой узкой нише. Не мне Вам говорить о том, какая квалификация необходима для написания качественного кода на C++. И то, что все те, кто может обойтись другими средствами, продолжают есть кактус, иначе как недоразумением я объяснить не могу.
P.S. Не обижайтесь, пожалуйста, на "Вы". Так мне комфортнее говорить с не знакомым лично собеседником. Меня самого обращение на "ты" не задевает.
Здравствуйте, remark, Вы писали:
R>Это "извращение" было в языке с самого начала, и ты сам его постоянно используешь, когда пишешь литералы типа 1u, 1ll, 1ull, 1.0f и т.д.
Чё-то не припомню случая, когда это нужно было. Вообще нафига это нужно, когда есть приведение типов? Но это ещё ладно.
Я как раз почитываю "Дизайн и эволюцию", и там есть такое любопытное предложение для желающих привнести что-то новое в язык: готовы ли вы пожертвовать почку ради своего нововведения?
Так вот, мне интересно, кто пожертвовал свою почку ради этого маловыразительного и заведомо неиспользуемого средства?
Здравствуйте, elcste, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?
J>>Правильная постановка! J>>Давай по пунктам? О каком именно сахаре ты говоришь?
E>О том, что упоминал OP, — лямбда в core language, литералы пользовательских типов. Но смысл-то не в этом, смысл в том, что я каждый раз изумляюсь, услышав, что скоро C++ окажется в очень узкой нише и т.п. По моим представлениям, он уже давно в этой узкой нише. Не мне Вам говорить о том, какая квалификация необходима для написания качественного кода на C++. И то, что все те, кто может обойтись другими средствами, продолжают есть кактус, иначе как недоразумением я объяснить не могу.
Я не думаю, что в _своих_ задачах я могу обойтись другим языком без потерь в той или иной области (производительность, например).
Но при этом по ходу решения моих задач передо мной встают разные мелкие задачи, которые встают и перед любым другим.
И любой сахар, который позволяет всю эту мелочь убрать под капот, я только приветствую.
В любом языке приветствую, в смысле.
Притом, кстати говоря, если сахар качественный, то требования к квалификация программиста снижаются.
Для меня лично очень востребованным является сахар типа встроенных лямбд, шаблонов с переменным набором параметров, форвардинга параметров, наследования конструкторов и прочего, что позволяет писать тот же самый код, только тратя гораздо меньше сил.
Ну и макросистему типа немерлевской было бы очень неплохо прикрутить
E>P.S. Не обижайтесь, пожалуйста, на "Вы". Так мне комфортнее говорить с не знакомым лично собеседником. Меня самого обращение на "ты" не задевает.
Это хорошо, что не задевает. Я постараюсь на "Вы", но, конечно же, привычка может взять свое.
так уж сложилось в тех сообществах ,в которых принято общаться на "ты", что обращение на "Вы" означает ссору.
Здравствуйте, Roman Odaisky, Вы писали:
RO>По крайней мере, черновики нового стандарта уже есть, а до его выхода еще 2 года. Уже существует ConceptGCC, и Майкрософтовцы затеяли очередную перестройку внутренностей своего компилятора, которая, они обещают, поможет им легко и быстро прикрутить новые фичи.
Не верю, что нормальный компилятор с поддержкой всех фич из стандарта появится быстро. Слишком уж много всего. Разрешение имен и семантический анализ становятся довольно сложными при наличии всех перечисленных фич. Да и реализация intelliSense-а, name completion-а и т.п. значительно усложняется. А ведь еще совместимость с унаследованным кодом нужна...
Здравствуйте, ., Вы писали:
>> Ну почему же. >> static bool myCompare(std::string const& s1, std::string const& s2) >> Здесь разве что проблема — не всякий компилятор заинлайнит вызов функции >> по указателю. .>Самая проблема выделена, это уже не функтор.
Ну и что? Главное, что это — локально объявленная функция.
Здравствуйте, Nazik, Вы писали:
N>1. http://openmp.org N>2. OpenMP вполне можно считать индустриальным стандартом в распараллеливании существующих последовательных приложений приложений N>3. Опять же, конкуренты конечно есть, но OpenMP поддерживается всеми распространенными компилерами (по крайней мере Microsoft, Intel, GNU), поэтому, вполне можно считать его чем-то очень стандартным.
Так писали уже, что с новым синтаксисом OpenMP и многие другие расширения будут легко и красиво прикручиваться к языку. Это может выглядеть так:
// было#pragma omp parallel for
for(int i = 0; i < n; ++i)
{
dst[i] = f(src[i]);
}
// сталоfor [[omp::parallel]] (int i = 0; i < n; ++i) // можно сделать макрос
{
dst[i] = f(src[i]);
}
Джоэл тут при том, что политика его компании — набирать самых лучших сотрудников, пусть они и стоят на порядок дороже. Характерная цитата:
Bottom Line it For Me.
The monthly rent for our offices, when fully occupied, will run about $700 per employee. <…> I suspect that $700 per person is on the high side for software developers throughout the world, but if it means we can hire from the 99.9 percentile instead of the 99 percentile, it'll be worth it.
Кто-то спрашивал примерно год назад, что же такое экстраординарное выпускает Fog Creek, что им требуются такие сотрудники. Я не сразу понял, что ответ — ничего. На самом деле Джоэл представляется мне прагматичным человеком, который просто понял раньше других, что качество растет быстрее зарплаты.
В противоположность этому подходу, Егор где-то выше в этой ветке, обсуждая целесообразность использования Boost, противопоставлял профессиональных разработчиков бестолковым студентам, причем мне показалось, что предпочтение в его компании отдается отнюдь не первым. Естественно, если проект пишут за еду индусы™, то им нужно запретить не только Boost.
Хорошим разработчикам не нужно запрещать STL, или рефакторинг, или шаблоны, или исключения — они сами знают, когда и что принесет пользу. Вопрос не в этом, и он даже не связан с C++: на Java, Ruby, C#, Python, Nemerle и т. п. тоже можно писать плохой код, что бы ни говорил Влад. Вопрос в том, оправдано ли (нет, конечно) нанимать разработчиков, которым приходится что-либо запрещать, и до уровня которых должны будут опускаться все остальные.
E>Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?
Эй, а зачем вам syntactic sugar существующего С++? Почему бы не писать на асме? А что, все можно реализовать, уже есть библиотеки, все прекрасно работает (ну и прочий бред, который вы там несли). Даже лучше, давайте писать в hex-е. Зачем нам, "суровым сибирским парням", все эти глупости с классами, операторами, да и этим долбанным непонятным и ненужным полиморфизмом, а? Все ведь и так можно написать, вроде?
Но, уважаемый, к счастью помимо абстрактной "возжности" решить задачу, хочется ее решить качественно (к тому же максимально расширяемо при минимальных затратах), удобно и просто.
Re[2]: Казалось бы, причем тут Джоэл?
От:
Аноним
Дата:
26.08.07 20:59
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:
RO>Джоэл тут при том, что политика его компании — набирать самых лучших сотрудников, пусть они и стоят на порядок дороже.
То что они дороже еще не значит что они лучше
STL. Boost, С# и вся братия делалась что бы как раз удешевить работу программистов и снизить требования к их квалификации, однако пока что это слабо удается
Здравствуйте, Roman Odaisky, Вы писали:
RO>В противоположность этому подходу, Егор где-то выше в этой ветке, обсуждая целесообразность использования Boost, противопоставлял профессиональных разработчиков бестолковым студентам, причем мне показалось, что предпочтение в его компании отдается отнюдь не первым.
Ты понял неверно! В нашу компанию ещё и фиг устроишься
RO>Естественно, если проект пишут за еду индусы™, то им нужно запретить не только Boost.
Не знаю, не пробовал
RO>Хорошим разработчикам не нужно запрещать STL, или рефакторинг, или шаблоны, или исключения — они сами знают, когда и что принесет пользу.
Для этого они должны хнать очень широкий контекст. Кроме того, представлять себе коллективные эффекты от использования той или иной технологии...
С одной стороны, разве везед уже пишут прямой и прекрасный код? Зачем усугублять? ИМХО при коллективной разработке на C++ инстукция просто необходима
А с другой стороны, разве для программирования так уж часто нужны свои шаблоны, например? Если таки они нужны, то ИМХО и не страшно, что их использованию предшествует небольшая бюрократическая процедура обоснования нужды и получения разрешения. Это намного дешевле последующей поддержки/переноса кода написанного из эстетических соображений людей, которые пишут LISP-системы на кофеварках за выходные и для развлечениея
RO>...Вопрос в том, оправдано ли (нет, конечно) нанимать разработчиков, которым приходится что-либо запрещать, и до уровня которых должны будут опускаться все остальные.
Ответ в том, что коллективная работа, особенно работа звёзд, требует согласованности усилий...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Awaken, Вы писали:
A>неужто Google?
АФАИК в Google STL любят...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, c-smile, Вы писали:
E>К тому времени, когда появятся компиляторы C++0x на тормоза по разбору новых лексем вряд ли можно будет обращать внимание. Тем более, что шаблоны по любому будут добавлять тормозов больше, чем эти лексемы.
g++ уже поддерживает часть фич новой спецификации. И будет поддерживать всё очень быстро после принятия спеки.
J>Аргументация как-то слабовата, не находите, коллеги?
Конечно слабовата. С другой стороны, что-то в ней есть. Вместо того, чтобы идти по пути упрощения языка, он идет по пути усложнения, например, зачем-то ввели новые литералы — от примера с miles у меня волосы дубом встали.
Лямбда выражения хороши, когда синтаксис их интуитивно прост и понятен. В приведенном примере — нет, не понятен.
А саму статью в Педии я не читал