[c++]0x

для каждого масштабного проекта на Си/Си++ «стандартная библиотека» пишется своя

4.2 наглое

абстракции безбожно текут, и в каждом проекте дыры приходится затыкать по-своему

это ошибки проектирования, не более того

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

да ты чо! «бедняшка» неосилятор, хоть не позорился бэ

Пример задачи в студию.

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

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

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

Среди примеров, думаю, будет только Qt - в нем свою стандартную библиотеку написали только потому, что предполагался запуск на мобильных телефонах, для которых вместе со средствами разработки почему-то не поставляют стандартную библиотеку (как, например, Symbian).

Где там утечки? Ну и у STL несколько реализаций.

А для чего она?

Пример такого горя?

Предложите хотя бы близкий аналог. D не предлагать - он более мертв, чем жив.

А где можно своровать?

Человек не пишет на плюсах, но его продолжают кормить. ЛОР в своём репертуаре :}

> Пример такого горя?

На C++ не пишу, но подумай сам, что будет, если захватить лямбдой переменную ссылающуюся на динамически выделенную память(кто, а главное когда, должен будет эту память освободить?). Во всех языках с замыканиями, что я знаю, есть GC. В C++ же придётся решать такие вещи в ручную.

> Во всех языках с замыканиями, что я знаю, есть GC. В C++ же придётся решать такие вещи в ручную.

в с++ есть shared_ptr

>в нас момент

в наст момент это сделано так

у меня

Звучит несколько субъективно, не находите? Вы говорите что С++ нужен, потому что вы его уже используете - не находите причинно-следственных нестыковок?

ООП там просится

Посмотрите на реализацию Gtk+ - там ООП, основанное на чистом С. Разница между ним и кодом на С++ в том, что к нему замечательно строить интерфейсы (поэтому биндинги к Gtk есть под любой сколько нибудь популярный язык), плюс читабельность, наглядность, итд.

> Звучит несколько субъективно, не находите?

Не нахожу. Я его использую потому что мне это удобно + никто не умеет писать новые задачи в моей области (ну из тех кого я знаю) с такой скоростью как я. Если бы кто нить появился пишущий на том же уровне скажем на фортране я б к нему прибежал и попросил показать, но таких нету;-)

Посмотрите на реализацию Gtk+ - там ООП, основанное на чистом С

Ище раз - мне нужны шаблоны. В С есть шаблоны? При импорте в питон для меня существенно что все методы и данные инкапсулированы в одном классе. В С-стайл мне придется совершать кучу ненужных движений -> скорость разработки упадет.

>Посмотрите на реализацию Gtk+ - там ООП, основанное на чистом С.

Вы на этом ООП писали? Читабельности и наглядности там и близко нет.

На C++ не пишу, но подумай сам, что будет, если захватить лямбдой переменную ссылающуюся на динамически выделенную память(кто, а главное когда, должен будет эту память освободить?).

man подсчет ссылок. man boost::shared_ptr. Кстати, в C++0x он есть в стандартной библиотеке.

C++ это и есть Си с классами и шаблонами.

это ошибочное мнение

к C++ не применим сишный стиль программирования.

и это ошибка

> в с++ есть shared_ptr

Я прекрасно знаю о существовании умных указателей. Вот только их наличие не гарантирует, что их будут применять. Думаю спорить об этом не имеет смысла, т.к. через 2-3 года(или сколько там будет нужно, чтобы C++0x влился в массы) мы увидим результаты по кол-ву тредов в Development.

Посмотрите на реализацию Gtk+ - там ООП, основанное на чистом С. Разница между ним и кодом на С++ в том, что к нему замечательно строить интерфейсы (поэтому биндинги к Gtk есть под любой сколько нибудь популярный язык), плюс читабельность, наглядность, итд.

Толсто. Код GObject содержит кучу лишних телодвижений, которые в C++ никогда не пришлось бы делать.

PS. Единственный удобный биндинг для компилируемого языка для Gtk+, который я юзал - как ни странно, Gtk# (ибо обычный Gtk+ плох из-за реализации ООП на языке, не поддерживающем ООП, а gtkmm довольно крив).

> Посмотрите на реализацию Gtk+

реализация Gtk+ программистам по ночам в качестве кошмаров снится - набор хаков и костылей, хорошо приправленный километровыми названиями функций

> что будет, если захватить лямбдой переменную ссылающуюся на динамически выделенную память

Лямбды тут ни при чём. Просто это ещё один способ наступить на старые добрые грабли. Например, можно неявно для себя сохранить указатель в каком-нибудь объекте.

Лямбды, вернее замыкания, подразумевают захват состояния из своего окружения. Без GC полноценно это реализовать сложновато.

Попробуйте сделать на плюсах cons, car, cdr замыканиями, как это было показано в SICP, я посмотрю. :)

Ок, допустим shared_ptr.

Является ли замыкание в c++0x объектом первого рода? Когда будет инкрементировано число ссылок на разделяемый объект, при создании замыкания или при его вызове? Когда оно будет декрементировано?

Инкрементировано будет при создании замыкания. Декрементировано - при его удалении.

А как там это сделано? Не вижу, что мешает сделать shared_ptr-ами.

gcc жувал такое давно

int b=1;
const int a=b;
int c[a];

Представь себе, сегодня и на ассемблере пишут повсеместно.

Так это в стандарте есть или gcc по ошибке жует и скоро пофиксят?

Примерно так

CL-USER> (defun my-cons (head tail)
           (lambda (head-t)
             (let ((my-head head)
                   (my-tail tail))
               (if head-t my-head my-tail))))
                   
MY-CONS
CL-USER> (defun my-car (my-cons-obj)
           (funcall my-cons-obj t))
MY-CAR
CL-USER> (defun my-cdr (my-cons-obj)
           (funcall my-cons-obj nil))
                        
MY-CDR
CL-USER> (defvar *sample* (my-cons 1 (my-cons 2 (my-cons 3 (my-cons 4 (my-cons 5 nil))))))
*SAMPLE*
CL-USER> (my-car *sample*)
1
CL-USER> (my-cdr *sample*)
#<CLOSURE (LAMBDA (HEAD-T)) {61EDC6ED}>
CL-USER> (my-car (my-cdr *sample*))
2
CL-USER> 

(defun my-cons (head tail)
   (lambda (head-t)
     (let ((my-head head)
          (my-tail tail))
        (if head-t my-head my-tail))))

Задача лиспоориентирована, и на ней лисп уделает всех. На плюсах подобное нереализуемо по-человечески из-за статической типизации. Далее в примере, дабы не загромождать код лишними шаблонами и извращениями с типизацией, используется boost::any.

#include <boost/any.hpp>
#include <functional>
#include <iostream>
using namespace std;
using namespace boost;
function<any (bool)> cons(any head, any tail)
{
	return [head, tail](bool head_t) -> any
	{
		return head_t ? head : tail;
	};
}
any car(any lamb)
{
	return any_cast<function<any (bool)> >(lamb)(true);
}
any cdr(any lamb)
{
	return any_cast<function<any (bool)> >(lamb)(false);
}
int main()
{
	auto cons_var = cons(1, cons(2, cons(3, cons(4, cons(5, nullptr)))));
	cout << any_cast<int>(car(cons_var)) << '\n';
	cout << any_cast<int>(car(cdr(cons_var))) << '\n';
}

Полистал стандарт, не нашел про изменяющиеся массивы. Кстати, вышеприведенный код не компилится на MSVS, вечером попробую еще clang'ом скомпилить.

Visual studio за такую конструкцию обложит всеми мыслемыми и немыслемыми *ями