Приведение типов

Хммм, значит strlen(), функция, вычисляющая размер строки, внезапно возвращает специальный тип, созданный для представления размера?

strlen возвращает ровно то, что она возвращает

man strlen

     #include <string.h>

     size_t
     strlen(const char *s);

И для индексирования внутри строки стандарт предлагает использовать специальный тип, который предназначен для индексации?

Не думаю, что стандарт затрагивает этот вопрос.

size_t - это unsigned interger, так написано в стандарте. все.

Автоматическая векторизация затем и придумана, чтоб о ней не думать. Компилятор может подумать, если дурак-программист не использовал size_t там где не надо.

Мне плевать на автоматическую векторизацию в тех местах, где она не применяется.

strlen возвращает ровно то, что она возвращает

Видимо без таблички «сарказм» вообще никак. Ладно, последняя попытка: size_t - это специальный тип данных, предназначенный для хранения размеров блоков памяти, индексов внутри массивов и смещений. Именно для этого он и используется в библиотеке. Для подсчёта сумм, итерации внутри цикла (если он не связан с работой с памятью), size_t не предназначен и использовать его не рекомендуется. Так понятно?

size_t - это специальный тип данных

стандарт говорит, что это unsigned integer

Для подсчёта сумм, итерации внутри цикла (если он не связан с работой с памятью), size_t не предназначен и использовать его не рекомендуется. Так понятно?

Кем не рекомендуется? Тобой? Понятно. Сегодня же отправлю письмо с правками в комиссию по стандартизации. Так им и напишу:

khrundel не рекомендует использовать size_t для подсчета сумм и для итерация внутри цикла (если он не связан с работой с памятью)

стандарт говорит, что это unsigned integer

4.2. Стандарт определяет его иначе.

std [skip] неймспейсы

И зачем оно нужно?

Дальше можно не комментировать.

И вообще предпочитаю строгую типизацию

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

with ada.text_io;
with ada.numerics.generic_elementary_functions;

procedure main is

  i0 : float := 4.0;
  --i1 : float := 4;
  --i2 : integer := 4;


  package math is new ada.numerics.generic_elementary_functions(float);

begin

  ada.text_io.put_line(math.sqrt(i0)'img);
  --ada.text_io.put_line(math.sqrt(i1)'img);
  --ada.text_io.put_line(math.sqrt(i2)'img);

end main;

кста, может ты ещё и гото не пользуешь, малыш?

И вообще предпочитаю строгую типизацию.

Вывод типов и строгость типизации - ортогональные вещи.

Для строгой типизации есть хаскель.

В котором вывод типов ещё более мощный (мы ведь об auto говорим).

4.2 на твое 4.2

Я тебе привел точную цитату из стандарта на предыдущей странице треда, где черным по белому pdf'у написано

an unsigned integer type

Только там это опциональная фича.

А во-вторых, и где там нет меток?

Они там как раз есть. И таких меток нету в c/c++.

только важных с моей точки зрения отличиях.
с моей точки зрения

Юлите дальше.

А на практике шаблоны в основном используются в stl и в boost.

А вот в Qt почти нет шаблонов и ничего.

an unsigned integer type - это не тип unsigned integer. Английская языка такая.

#include <stdio.h>

#define loop while(1)
#define break goto

int main(int argc, const char * argv[]) {

    loop {
        puts("Entered the outer loop");
    
        loop {
            puts("Entered the inner loop");
    
            // This would break only the inner loop
            //break;
    
            // This breaks the outer loop
            break outer;
        } inner:

        puts("This point will never be reached");
    } outer:

    puts("Exited the outer loop");

    return 0;
}

Entered the outer loop
Entered the inner loop
Exited the outer loop

PS. каптча SOLD MAMMY. Расизмом попахивает. Один из переводов mammy

няня-негритянка (до отмены рабства в Южных штатах США)

PPS. сделал скрин, чтобы шантажировать гугл

А я и не говорил, что там написано _unsigned int_. Я говорил, что там написано unsigned integer. Что-то перевести? Может слово integer не понятно?

И что? А вот в стандарте C++ написано, что он ещё и достаточно большой, чтоб вместить размер любого объекта. Что, впрочем, не удивительно, было бы странно, если бы size_t не смог вместить размер объекта.

Ну вот. Хороший же тип. А еще его удобно использовать в качестве хранилища для указателя.

Костыль.

Только там это опциональная фича.

Как будто в плюсах (да и в расте при большом желании) можно RAII не использовать.

Не распарсил. В C++ у нас деструктор генерируется компилятором, даже если мы его сами не указываем.

Ну и что? Как это относится к тому коду, который «исправили»?

Ты спросил:

Зачем здесь size_t?

Затем, что этот тип представляет беззнаковое целое.

Или ты спрашивал в философском смысле? Быть или не быть? :) В своем коде пиши как хочешь, а этот парень пусть пишет как он хочет.

Он не пишет, он учит других в коде, представляющем собой, условно, некую математику в вакууме использовать size_t со словами что так и надо.

И в C есть ООП, и в C++ есть ООП

Или в обоих нет, смотря что считать ООП

В C++ у нас деструктор генерируется компилятором, даже если мы его сами не указываем.

И? Помещать туда код закрытия ресурса или освобождения памяти всё равно нужно руками. При желании можно этого не делать (как и не использовать смарт поинтеры).

Помещать туда код закрытия ресурса или освобождения памяти всё равно нужно руками.

Не обязательно:

struct S {
    std::vector<MyClass> d;

    // компилятор сам сгенерирует деструктор, который вызовет деструктор d
}

Это ты так шутишь или как?

Нет. А что не так?

Очередной бессмысленный спор, по всей видимости. Ну и я сразу скажу, что да, у «деструкторов» есть ряд преимуществ перед «RAII» в духе джавы/шарпа, например, в плане вложенных ресурсов. Но в твоём примере ты полагаешься на уже написанный деструктор вектора. Будь там указатель на массив в куче и никакой «магии» не было бы.

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

Кто-то из нас потерял нить разговора. Я писал, что raii, и в частности деструкторы, не являются обязательной частью ООП.

Лол, а оптимизации кто за тебя включать будет?

Дедушка, авто и шаблоны — ортогональные вещи.

Спасибо за пример. Я действительно немного отстал от жизни. Хотя подобные концепции мне не нравятся.

Для строгой типизации есть хаскель.

Ну, не знаю. Раньше был Си++. Надеюсь, он не превратится в питон.

std [skip] неймспейсы

И зачем оно нужно?

Дальше можно не комментировать.

Я как бы и не просил тебя комментировать, но если уж взялся, то говори по делу. А то получается, что ты отказываешься делать то, о чём тебя никто и не просит. Проще было бы промолчать.

Вывод типов и строгость типизации - ортогональные вещи.

Для меня строгость типизации - это когда программист явно указывает типы. Да, шаблоны нарушают это правило, но в конкретном шаблонном классе/функции я всё-таки сам указываю типы. А если за меня это делает компилятор, то это уже полное г. Впрочем, это моё имхо, и я его никому не навязываю.

А во-вторых, и где там нет меток?

Они там как раз есть. И таких меток нету в c/c++.

Таких - это после break/continue? Да, нет, потому что есть goto:

while(1)
{
  printf("Entered the outer loop\n");
  while(1)
  {
    printf("Entered the inner loop\n");
    goto outer;
  }
}
outer: printf("Exited from all loops\n");

А указание меток после break/continue с одновременным запретом оператора goto - профанация и костыль: гото - это типа плохо, поэтому мы его оставим, но назовём более благозвучно. Но метки от этого не перестают быть метками.

только важных с моей точки зрения отличиях.

с моей точки зрения

Юлите дальше.

Ещё раз повторюсь: я говорил об этом с самого начала, и привёл соответствующую цитату из своего первого поста. Естественно, всё, что я говорю, является _моей точкой зрения_, если явно не указано иное. Впрочем, если вам проще думать, что я сливаюсь, ради бога, с меня не убудет, лишь бы вы были рады.

Лол, а оптимизации кто за тебя включать будет?

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

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

Какие преимущества у убъявления i внутри каждого цикла по отдельности по сравнению с объявлением её в одном месте до всех циклов?

Люди всегда делают эту ошибку

  int i;
  for (i = 0; i < 10; i++) {
    puts("a");

    for (i = 0; i < 10; i++) {
      puts("b");
    }
  }

Не способен человек запомнить используется i или свободна. Зато у компилятора это элементарная оптимизация.

Не способен человек запомнить используется i или свободна.

Я таких ошибок никогда не делал, даже когда учился. По-моему несложно запомнить, что происходит в 2 (ну пусть даже в 3) вложенных циклах на 7 строчках (ну пусть даже на 2 экранах). Но если кто-то такие ошибки делает, то для него действительно имеет смысл максимально локализовать счётчики и др. переменные.

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

Ну а для меня «aureliano15 » - это нечто нехорошее.

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

http://en.cppreference.com/w/cpp/numeric/math/sqrt

советую бороться с фобиями ведь читать приходится не только свой код.

С этим согласен.

с фобиями

А вот с этим - нет. Это не фобии, а принципиальная позиция. Тип variant существовал задолго до принятия последних стандартов си++. Я не говорю, что это плохо. Для некоторых программ это очень хорошо. Но не для тех, на которые в основном ориентирован си++. Да, я понимаю, что auto и variant - разные вещи. Переменная auto, однажды став int'ом, уже никогда не превратится в double, а variant - запросто. Но то, что программист в собственном коде не конролирует типы создаваемых им же переменных - великое зло. Я всегда считал и считаю (и не только я), что одним из серьёзных преимуществ си++ перед си помимо классов и пр., является как раз повышенная строгость. Например, такой код:

int main()
{
  short n;
  void* m=0xFFFFFFFFFFFF;
  n=m;
  return n;
}

при компиляции в режиме с++ выдаст 2 ошибки, а в си - только 2 предупреждения, которые легко можно не заметить или даже подавить.

Но конструкции типа auto не только сводят это преимущество на нет, но и ещё больше усугубляют проблему.

Да, я понимаю, что auto и variant - разные вещи. Переменная auto, однажды став int'ом, уже никогда не превратится в double, а variant - запросто.

А вот такой код тоже смущает?

struct SomeInterface { ... };

struct A : SomeInterface { ... };
struct B : SomeInterface { ... };

SomeInterface* i = foo();

Но конструкции типа auto не только сводят это преимущество на нет, но и ещё больше усугубляют проблему.

Просто не надо писать такой код.

Впрочем, если вам проще думать, что я сливаюсь, ради бога

Я не мыслю школьными понятиями.

А вот такой код тоже смущает?

Полиморфизм - это немного другое. Безусловно, он создаёт массу проблем, особенно при отладке. Но и предоставляет множество плюшек. Именно поэтому в одних проектах принципиально не используют классы и вообще кресты, а в других - только их и используют. И в общем случае нельзя сказать, даёт такой подход больше плюсов или минусов. Скорость разработки и модификации, безусловно, повышается. Размер исходного кода уменьшается. Но зато отладка усложняется. В случае же с auto отладка усложняется, читабельность снижается, а плюшки если и есть, то их минимум. Впрочем, это дело вкуса. Что такое минимум и что такое достаточное количество плюшек - вопрос субъективный.

Просто не надо писать такой код.

С этим трудно не согласиться. :-)

По-моему, это не C++ код. И не С-шный тоже. В C++ надо явно передать целочисленное значение конструктору double, т.е.

sqrt(double(num))

А в C вообще не надо маяться фигнёй и писать

sqrt(num)