Текущий Стандарт С++ и перспективы его развития

Цитата Flex Ferrum @ 30.09.08, 19:33

Цитата FireZilla @ 30.09.08, 18:53

Из-за остутвия finally приходится использовать смарты, которые добавляют к программе лишних 100-200 КБ кода, даже если в принципе нет особой нужды в подсчете ссылок и т.п.

Нет, это . Трижды. Активно программируя на шарпе (где используется этот самый try-finally) и на С++ (где его нет), лучше все же в С++. Типичная конструкция в шарпе:

            OleDbDataReader r = null;
            try
            {
                OleDbCommand cmd = new OleDbCommand(check_sql, m_Connection);
 
                AddParameterInt(cmd, (int)ai.ID);
                r = cmd.ExecuteReader();
                if (r.Read())
                    UpdateIniniator(ai);
                else
                    InsertInitiator(ai);
            }
            finally
            {
                if (r != null)
                    r.Close();
            }

И так везде, где требуется контроль освобождения ресурсов при выходе из блока/функции. Или (о! небеса!) - использование для тех же целей using:

using (OleDbDataReader r1 = null)
{
   // ...
   using (OleDbDataReader r2 = null)
   {
      // ...
   }
}

Хорошо, если переменных - одна-две. А если их три-пять?
Так что, за finally агитировать не надо.

Цитата FireZilla @ 30.09.08, 18:53

А теперь про то что не попало в стандарт и слава богу - свойства. Имея дело с делфи я пришел к выводу что подобная практика фактически бесполезна. Свойства легко реализуются через сетеры и гетеры (т.е функции) которые к томуже могут быть автоматичики сгенерированны ИДЕ.

Спорный тезис.

Добавлено 30.09.08, 19:35

Цитата FireZilla @ 30.09.08, 19:28

IMHO Типы вроде int8_fast и т.д. не испрявят ситуацию когда я всеравно могу написать long и на разных процессорах это будет либо 16 либо 32 либо 64 бита. Или нам всем дружно взятся и перерефакторить миллионы строк кода.

И что? Ситуаций, когда нужны типы фиксированной длины - не так много. Точнее, они ограничиваются только наличием требований бинарной совместимости (серелизация/десерелизация данных). Все! В остальных случаях совершенно побарабану - сколько именно места занимает int или long.

Мда, все это хорошо если ты программируеш единственный инструмент - Микропроцессор архитектуры Intel.
Нашему же вниманию предлагается международный стандарт на язык программирования для любого типа процессоров и контроллеров.

И вообще у меня сложилось впечатление что комитет стандартизирует не язык программирования, а собсвенно компилятор фирмы Intel. Язык как то начинает быть похожим на ассемблер intel. По всей видимости борьба с коррупцией набриает обороты, броремся так что даже американцы стали берать взятки

А касательно finally я скажу просто, если у меня всего одна переменная, зачем тогда мне прибавлять к программе хеадер с 5 000 строк кода

А про то что по барабану какой длинны тип данных, это ты загнул. Можно подумать инеграция кода написанного на разных языках, сетьвая передача данных, обмен данными с БД и вообще допустим проверка установки 3-го бита в 1 некоторой переменной просто улитучились из нашей жизни.

Цитата FireZilla @ 01.10.08, 10:45

Мда, все это хорошо если ты программируеш единственный инструмент - Микропроцессор архитектуры Intel.
Нашему же вниманию предлагается международный стандарт на язык программирования для любого типа процессоров и контроллеров.

Как бы так сказать, за свою практику я программировал не только Intel, и не только под Windows. А потому возможные проблемы с разным размером типов на разных архитектурах хорошо себе представляю.

Цитата FireZilla @ 01.10.08, 10:45

И вообще у меня сложилось впечатление что комитет стандартизирует не язык программирования, а собсвенно компилятор фирмы Intel. Язык как то начинает быть похожим на ассемблер intel. По всей видимости борьба с коррупцией набриает обороты, броремся так что даже американцы стали берать взятки

Ну что за глупости.
Конечно, типы гарантированной фиксированной длины были бы не лишними. В том же сетевом программировании это бы очень пригодилось. Но для этого нужны новые типы, а такие типы, как short, int, long специализировать нельзя. И это как раз касается программирования "для любого типа процессоров и контроллеров".

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

Господа, а вот по поводу auto вопрос, может кто знает, такой код будет работать?

template< typename T >
class A {
public:
    template< typename Ind >
    auto operator[]( Ind i )
    {
         return data[i];
    }
private:
    T data;
};

Сообщение отредактировано: D_KEY - 01.10.08, 11:24

Цитата FireZilla @ 01.10.08, 10:45

А касательно finally я скажу просто, если у меня всего одна переменная, зачем тогда мне прибавлять к программе хеадер с 5 000 строк кода

Ну, если у тебя всего одна переменная - то проконтролировать ее время жизни и без finally можно.

Цитата D_KEY @ 01.10.08, 11:19

Господа, а вот по поводу auto вопрос, может кто знает, такой код будет работать?

Думаю, да... Почему бы и нет? Ведь на момент инстанцирования компилятор будет знать тип шаблонного аргумента .

Цитата archimed7592 @ 01.10.08, 14:16

Цитата D_KEY @ 01.10.08, 11:19

Господа, а вот по поводу auto вопрос, может кто знает, такой код будет работать?

Думаю, да... Почему бы и нет? Ведь на момент инстанцирования компилятор будет знать тип шаблонного аргумента .

Да я тоже так "думаю", а вот найти инфу по этому вопросу не могу. Хотя и ищу из рук вон плохо

Цитата archimed7592 @ 01.10.08, 08:34

Кстати, managed C++ - совмещено? Совмещено... Просто плохо и неудобно совмещено

Совмещено? Как же, ага. Я как-то попробовал в managed-коде (на MC++) попользоваться шаблонами. Получил по рукам от компилятора, и (в итоге) забросил это дело. Вот так вот оно совмещено было.

А скажите на милось, кто драфт читал, в файловые потоки ввели что-нибудь, позволяющие прицепить поток к уже открытому файлу? Бо уже достало писать что-то вроде

  HANDLE   file1;
  filebuf  inFile1;
  int      handle1;
 
  file1=CreateFile(pat.second.c_str(), GENERIC_READ, FILE_SHARE_READ, NULL,
                   OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL);
  if(file1==INVALID_HANDLE_VALUE)
  {
   DWORD errCode=GetLastError();
 
   errors.push_back(std::make_pair(errCode, pat.second));
   return;
  }
  inFile1.open(handle1=_open_osfhandle(reinterpret_cast<int>(file1), _O_RDONLY),
               std::ios::binary | std::ios::in);
  if(!inFile1.is_open())
  {
   DWORD errCode=GetLastError();
 
   if(handle1==-1) CloseHandle(file1);
    else _close(handle1);
   errors.push_back(std::make_pair(errCode, pat.second));
   return;
  }
  inFile1.pubsetbuf(&buffer1[0], buffer1.capacity());
 
  /* ... */
  if(std::equal(std::istreambuf_iterator<char>(&inFile1), std::istreambuf_iterator<char>(),
                std::istreambuf_iterator<char>(&inFile2))) break;
  /* ... */
 
  inFile1.close();
  _close(handle1);

и то спасибо MSу и STLPort-у.

Qraizer, а можешь сказать - в каких случаях вообще такое может понадобиться? Мне как-то всегда хватало ifstream/ofstream...

Цитата D_KEY @ 02.10.08, 08:47

Да я тоже так "думаю", а вот найти инфу по этому вопросу не могу. Хотя и ищу из рук вон плохо

Цитата 8.3.5/12

A late-specified return type is most useful for a type that would be more complicated to specify before the
declarator-id:
template <class T, class U> auto add(T t, U u) -> decltype(t + u);
rather than
template <class T, class U> decltype((*(T*)0) + (*(U*)0)) add(T t, U u);

Цитата Flex Ferrum @ 02.10.08, 08:50

Получил по рукам от компилятора, и (в итоге) забросил это дело. Вот так вот оно совмещено было.

Всё там отлично пользуется. Другой вопрос, что эти шаблоны не видны из managed кода других сборок(из того же C#) - вот это, да, кривизна совмещения, но, как я уже отметил

Цитата archimed7592 @ 01.10.08, 08:34

по понятным причинам - целью было добится какой-нибудь совместимости, а ценою чего эта совместимость достанется никого, видимо, не волновало

Цитата Qraizer @ 02.10.08, 09:01

позволяющие прицепить поток к уже открытому файлу?

Что ты подразумеваешь под прицеплением потока к уже открытому файлу? (сорри, код я "слегка" не понял)

Цитата archimed7592 @ 02.10.08, 09:11

Всё там отлично пользуется. Другой вопрос, что эти шаблоны не видны из managed кода других сборок

Я имел ввиду Managed C++. А ты, видимо, говоришь про C++/CLI.

Добавлено 02.10.08, 09:19

Цитата archimed7592 @ 02.10.08, 09:11

Что ты подразумеваешь под прицеплением потока к уже открытому файлу? (сорри, код я "слегка" не понял)

Ну в том смысле, что есть системных хендл открытого файла, и с ним надо ассоциировать STL-ныпоток.

Цитата Flex Ferrum @ 02.10.08, 09:14

Я имел ввиду Managed C++. А ты, видимо, говоришь про C++/CLI.

Ммм... мне казалось, что это одно и то же... Разве нет?
По крайней мере в студии у меня только один вариант создания .NET/C++ проекта .

Цитата Flex Ferrum @ 02.10.08, 09:14

Ну в том смысле, что есть системных хендл открытого файла, и с ним надо ассоциировать STL-ныпоток.

Дык, нехрен симстемными хэндлами вообще оперировать - тогда и цеплять ничего никуда не понадобится .

Сообщение отредактировано: archimed7592 - 02.10.08, 09:25

Цитата archimed7592 @ 02.10.08, 09:24

Ммм... мне казалось, что это одно и то же... Разве нет?

Нет. Managed C++ - это первая инкарнация, которая была в 2003-ей студии. C++/CLI - это "с учетом недоработок и недоделок", а по сути - совсем другая реализация.

Цитата Flex Ferrum @ 02.10.08, 09:26

Нет. Managed C++ - это первая инкарнация, которая была в 2003-ей студии. C++/CLI - это "с учетом недоработок и недоделок", а по сути - совсем другая реализация.

Ааа... А я всегда думал, что это два разных названия одного и того же. Не, первую инкарнацию я видел, но юзать побоялся .
Суть моего высказывания не меняется - замени manager C++ на C++/CLI .
BTW, на С++/CLI чуть ли не стандарт есть(или готовится), если я не ошибаюсь.

Цитата archimed7592 @ 02.10.08, 09:24

Дык, нехрен симстемными хэндлами вообще оперировать - тогда и цеплять ничего никуда не понадобится

А приходится иногда. В приведённом примере, впрочем, это неактуально. Поток тут хорош был тем, что STLPort для бинарно открытого файла заюзывает memory-mapped, плюс бинарное сравнение файлов элементарным алгоритмом std::equal. Ну а файл открывался виндой всего лишь ради ключика FILE_FLAG_SEQUENTIAL_SCAN. Но вот понадобиться мне кастомный security descriptor присобачить, на пример в сервисе... Всё, STL побоку по-любому.

Сообщение отредактировано: Qraizer - 02.10.08, 12:27