• Честный подход к управлению людьми, или Почему я никогда не делаю контрофферы
    +2
    Очень легко называть «тестом на публичность» то, что делать не предполагается. «Я могу провести тест на публичность в любой момент, просто не хочу» ©
  • Концептуальная сортировка в С++20
    0
    Ну, известно, что на вход фильтра подается объект типа T произвольной вложенности, а на выходе bool.
  • Концептуальная сортировка в С++20
    0
    Тогда станет чуть полегче. Но все равно гарантировать корректную работу для всех типов шаблон не может, просто потому, что он не является самостоятельной сущностью, а вычисляется при подстановке.
  • Концептуальная сортировка в С++20
    0
    Ну а дженерики-то какие дадут преимущества?

    В том, что будет ошибка "не реализован интерфейс IFoo", а не "не найден метод fooasgjknasgh1htg781gh73" Преимущество очевидно тогда, когда у вас темплейт вызывает другие темплейт-функции, и падает где-то в глубине нижних уровней из-за какого-то непонятного несоответствия.

  • Концептуальная сортировка в С++20
    0
    Юзер не может это знать, он видит сигнатуру.

    Ну ок, допустим. Я не согласен, но допустим. Какая нам разница? Любой объект любого типа можно подставить вместо T? Можно. Что еще нужно?


    Хорошо, конкретизирую: на этапе статического анализа.

    Никакой статический анализ не скажет, что метода fooasgjknasgh1htg781gh73 не существует ни у одного объекта в проекте, и этот темплейт обречен провалиться.


    template <typename T>
    T add(T a, T b){
      return a.fooasgjknasgh1htg781gh73(b);
    }
  • Концептуальная сортировка в С++20
    0
    Верно, ибо это гарантируется дизайном языка.

    При чем тут дизайн языка? В любом языке зная тип T можно создать массив T[]. Тут не используется ни одного метода или свойства Object.


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

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

  • Концептуальная сортировка в С++20
    +2
    А мне ине не нужно знать.

    В двух словах:
    • Если не компилируется код с дженериком — проблема в моем коде.
    • Если не компилируется код с темплейтом — проблема может быть где угодно.
  • Концептуальная сортировка в С++20
    +2

    Ладно, перефразирую: чтобы понять, как будет работать дженерик с типом Т достаточно посмотреть на сигнатуру метода. Если же ошибка в темплейте, единственный способ посмотреть — залезть в него и посмотреть, как он используется внутри. Это совершенно разная сложность.


    Шарп/раст — не важно. Можно тип T никак не использовать, функционал "object" тут никак не задействован:


    public T[] CreateArray<T>(int size) => new T[size];

    в интерфейсе я вижу:


    public T[] CreateArray<T>(int size) => new T[size];

    interface IArrayCreator 
    {
       public T[] CreateArray<T>(int size);
    }

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

  • Концептуальная сортировка в С++20
    0
    Но это упрощенный пример. Если довести до предела, то пользователь вводит в input корретный C++ код фильтрации сущностей, который транслируется в запрос в БД. Может это несколько надуманный пример, но он не сильно отличается от того, что я на реальном проекте видел.
  • Концептуальная сортировка в С++20
    0
    Возможно. Хотя я и не представляю, как именно, и ни разу не видел на практике. Просветите?
  • Концептуальная сортировка в С++20
    0

    Тяжело читать плюсы. Насколько я понял, мы от пользователя получаем только параметры запроса, который выполняем. Я имел ввиду скорее генерацию самого запроса с нуля. У нас на проекте, например, была фильтрация, которая могла иметь произвольную вложенность. Всевозможные фильтры, объединяемые через И-ИЛИ. Весь фильтр целиком по сути имел свойства (де)сериализации из/в пользовательский ввод и умение выполняться в БД. Примера из этой системы не покажу, но например я класс, который генерирует объекты сравнения. Например, пишем так:


    var zComparer = ZComparer<Test>.New(t => t.A).Add(t => t.B).Add(t => t.C).Add(t => t.D);
    var comparer = zComparer.ToComparer();

    На выходе имеем объект типа IComparer с методом compare, который реализован как


    public int CompareTo(Test x, test y) 
    {
       var compA = x.A.CompareTo(y.A);
       if (compA != 0)
          return compA;
       var compb = x.B.CompareTo(y.B);
       if (compB != 0)
          return compB;   
       var compC = x.C.CompareTo(y.C);
       if (compC != 0)
          return compC;
       var compD = x.D.CompareTo(y.D);
       if (compD != 0)
          return compD; 
       return 0;
    }

    Можно ли тут сгенерировать нужный тип на этапе компиляции? Безусловно. Но только потому, что ZComparer<Test>.New(t => t.A).Add(t => t.B).Add(t => t.C).Add(t => t.D); мы знаем на этапе компиляции. Если же у нас немного больше динамики


    var zComparer = ZComparer<Test>.New();
    if (userInputA)
       zComparer= zComparer.Add(t => t.A);
    if (userInputB)
       zComparer= zComparer.Add(t => t.B);
    var comparer = zComparer.ToComparer();

    То сгенерировать нужный фильтр мы можем только в рантайме.


    Чуть подробнее в исходниках и в тестах.
    Код старый, так что возражения по оформлению и неоптимальности не принимаются, сам уже знаю :)

  • Концептуальная сортировка в С++20
    +1
    Давайте так: дженерик без условий where на типах будет работать с ЛЮБЫМИ типами, всегда.

    Могут ли такие гарантии быть у темплейтов?
  • Концептуальная сортировка в С++20
    0
    Ответил ниже (про лямбду)
  • Концептуальная сортировка в С++20
    0
    Можно пример?
  • Концептуальная сортировка в С++20
    +3
    Основное преимущество дженерика — он вещь в себе. Если вы написали дженерик и он компилируется — то скорее всего он написан правильно. Поэтому он будет корректно работать с любыми типами, которые подходят под ограничения (если они есть).

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

    Разные инструменты решают разные задачи, но в чем-то у них есть область пересечения. Дженерики позволяют решить задачу для произвольного типа Т, темплейты же позволяют писать факториалы времени выполнения, но никто не гарантирует того, что для любого возможного T реализация будет верна. Более того, это в общем случае неверно, ведь вместо типа может быть подставлено и число, и что угодно.
  • Концептуальная сортировка в С++20
    0
    Это не моя цитата.
  • Концептуальная сортировка в С++20
    0

    Имеется ввиду, что он деконструируется на некоторые известные части. Типичный пример, построить лямбду x=>x.Name == "Alex" && x.Gender = Gender.M на основании пользовательского текстового ввода.

  • Концептуальная сортировка в С++20
    0
    Печально, когда ничего не требуется генерить в рантайме. То есть почти всегда.

    В моем случае почему-то это почти всегда. Типичный пример — построение запроса, основанного на пользовательском вводе.

    Это больше про рефлекшн вообще

    Рефлекшн без информации о дженериках ничего не смог бы сделать. Например я бы не смог реализовать такой метод:
    internal static class AsyncRequestProcessorResolver
    {
    	private static readonly MethodInfo ExecuteAsync = typeof(IAsyncRequestProcessor).GetRuntimeMethod("ExecuteAsync", new[] {typeof(IRemoteRequest) });
    	private static readonly MethodInfo GetResultAsync = typeof(IAsyncRequestProcessor).GetRuntimeMethod("GetResultAsync", new[] { typeof(IRemoteRequest) });
    
    	public static MethodInfo GetRequestMethod(MethodInfo interfaceMethod)
    	{
    		return interfaceMethod.ReturnType.GenericTypeArguments.Length == 0 ? ExecuteAsync : GetResultAsync.MakeGenericMethod(interfaceMethod.ReturnType.GenericTypeArguments);
    	} 
    }

    Если бы у меня собственно не было MakeGenericMethod и interfaceMethod.ReturnType.GenericTypeArguments
  • Концептуальная сортировка в С++20
    0

    Ну, в расте райнтаймовой поддержки на данный момент нет, т.к. раст все же обычно имеет зависимости на уровне исходников.


    А вот в том же шарпе да, есть полная поддержка со стороны среды. И например List<int> и List<string> там разные типы, и попытка засунуть одно в другое приведет к ошибке времени выполнения, даже если на этапе компиляции там все было ок.

  • Концептуальная сортировка в С++20
    0
    Ну да. Например, генерация имплементации интерфейса, который прилетает по сети. Ну и другие случаи, например см. статью
  • Можно ли использовать С++ вместо Си для небольших проектов в микроконтроллерах
    0
    Что думают в царстве микроконтроллеров о том, что к вам придёт JavaScript

    ачем мне быстрый навороченный микро, который стоит 7 баксов, но с возможностью Джава

    ой
  • Можно ли использовать С++ вместо Си для небольших проектов в микроконтроллерах
    0
    Про некрасивый и неудобный не согласен, но т.к. это всего лишь мнение, комментировать не буду :)

    Насчет стандарта — да, не стандарт, но попробовать можно, по крайней мере на обучающей статье. Хотя в хардкорный проект со многими нулями совать пока рановато, с этим никто и не спорит.
  • Концептуальная сортировка в С++20
    +3
    Хотя бы в том, что дженерик всегда работает со своими типами корректно. Если вдруг вы подставили недопустимый тип Т, например вот так:
    use std::error::Error;
    
    fn print_error<T: Error>(value: T) {
        unimplemented!();
    }
    
    fn main() {
        print_error(10_i32);
    }
    

    То у вас будет понятное сообщение об ошибке:
    Compiling playground v0.0.1 (file:///playground)
    error[E0277]: the trait bound `i32: std::error::Error` is not satisfied
    --> src/main.rs:8:5
    |
    8 | print_error(10_i32);
    | ^^^^^^^^^^^ the trait `std::error::Error` is not implemented for `i32`
    |
    = note: required by `print_error`

    А не мешанина из кишков темплейта.

    Не говоря про возможность собирать дженерик из типов динамически в рантайме.

    Про «лучшесть» или «хужесть» дженериков в целом судить не берусь, но лично мне ими пользоваться удобнее.
  • Неслучайная случайность, или Атака на ГПСЧ в .NET
    +1
    У меня например в однострочник реализовано:
    private static readonly ThreadLocal<Random> Random = 
       new ThreadLocal<Random>(
          () => new Random(Environment.TickCount ^ Thread.CurrentThread.ManagedThreadId)
       );

    Просто и удобно
  • Миром всё ещё управляет язык С
    0
    Прошу прощения, перечитал еще раз. Да, много чего завязано на std, но вообще в планах это починить: internals.rust-lang.org/t/refactoring-std-for-ultimate-portability/4301. Подключаем отдельные крейты и готово.

    Microsoft распилил дотнет на кучу мелких пакетов, сотни, возможно тысячи, сделать то же в расте ничего особо не мешает, если будет желание.
  • Миром всё ещё управляет язык С
    +1
    Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.

    По-моему ничем не отличается от переизобретения в каждой компании своего си-подобного языка при помощи макросов. Точнее, отличается, но в лучшую сторону
    Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.

    Кто вас так жестоко обманул?
  • Миром всё ещё управляет язык С
    0
    Да особо рассказывать нечего. Поставил IDE, начал смотреть примеры, книжки, статьи. Не сказать, что что-то непонятно: опыт F# у меня, например, уже был, как и лиспов всяких. Но как-то не зашло. Хотя я как раз хотел проникнуться всей мощью IO монад и прочих методов гамбургера. Мб попробую еще раз позже. Сейчас приоритет — научиться писать на расте :)
  • Миром всё ещё управляет язык С
    +5
    Засунуть в одну копилку R, Hashell, Delphi и скриптовые языки это сильно :)

    Хаскель отпугивает намного сильнее, моё мнение. По крайней мере его я освоить так и не мог, а с растом спокойно подружился — достаточно прочитать растбук. Из сложных концепций можно разве что лайфтаймы назвать, но стоит понять, что это просто декларативный способ указания отношений «Х живет дольше У» и все становится очевидно.
  • Миром всё ещё управляет язык С
    +3
    Си ему не заменить.

    Какие-нибудь аргументы будут? Ну кроме «на нем столько всего написано». Как показывает опыт какого-нибудь COBOL'а, это не карт-бланш.
  • Сравнение производительности C и C++ на примере сжатия Хаффмана
    +1

    Как раз думал написать на расте и сравнить. Но для этого предпочел бы sample-1 из задачи чтобы приложили к исходникам, для пущей убедительности.

  • Возможности JavaScript, о существовании которых я не знал
    0
    Моя первая программа на паскале выглядела так (извиняюсь за форматирование, я раньше о таком не знал):
    program p1;
    var a,b,k,l,d,e:integer;
    c:boolean;
    label l1;
    begin
    write('Type a, please ');
    readln(a);
    a:=(abs(a));
    write('Type b, please ');
    readln(b);
    If b>0 then
           begin
    k:=0;
    l:=0;
    repeat
    d:= (a mod 10);
    e:= (b mod 10);
    c:=(d=e);
    If C then
    begin
    k:=(d+k);
    l:=(e+l);
    a:=(a div 10);
    b:=(b div 10);
    end
    else
    begin
    writeln('Не входит');
    goto l1;
    end;
    until b=0;
    Writeln('Входит');
    l1:
           end
    else writeln('Вы офигели!! Отрицательных цифр в записе числа не бывает!')
    end.


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

    Есть один известный дядька, он даже целый термин для этого goto придумал.
  • Парсим мемы в питоне: как обойти серверную блокировку
    0
    Перевод отличный, статья неплохая, но вброс про Windows вообще как-то чужеродно видится… Есть разработчики и под эту платформу, и на этой платформе.
  • Отзыв на трудоустройство в компанию Soshace
    +1
    Ничего:
    image
    Chome Version 63.0.3239.132 (Official Build) (64-bit)
  • Исправлять ли unexpected behavior в C# 7 или оставить как есть, усложнив синтаксис языка для компенсации?
    0
    I'm confused. I don't see any pattern matching in the code sample you just posted.
  • Исправлять ли unexpected behavior в C# 7 или оставить как есть, усложнив синтаксис языка для компенсации?
    0

    Вам уже ответили, что {} m это частный случай общего паттерна, который как раз дает оператор матча на не нулл бесплатно. И да, в языке ДОЛЖЕН быть оператор матчинга во всех случаях, даже если это выглядит как "еще один способ декларации переменной". Я тоже был одно время против неё, но LDM привели убедительные доводы, почему так должно быть. Просто игнорируя то, что вам говорят и продолжая твердить одно и то же вы ничего не добьетесь.

  • Исправлять ли unexpected behavior в C# 7 или оставить как есть, усложнив синтаксис языка для компенсации?
    0
    По-моему вы просто не понимаете смысла этой фичи, и поэтому вам не нравится то, что она в принципе в язык «проникла».

    Стоит подумать, почему так получилось. Обычно рассуждения в стиле «они все идиоты, сделали такую хрень» означают то, что проблема на другой стороне.
  • Дайджест новостей из мира PostgreSQL
    0
    А можно подобрку холиварных статей вроде вот этой? Ну просто я с постгресом не работал, и при выборе нового проекта хотел бы иметь обоснованное мнение, почему постгрес, а не оракл/mssql/whatever, не считая вопроса стоимости лицензии.
  • Исправлять ли unexpected behavior в C# 7 или оставить как есть, усложнив синтаксис языка для компенсации?
    0
    Ну да, то, что null является элементов любого типа это проблема… Сразу появляются подобные костыли, но это уже привычный костыль, можно скажать, родной для шарпа.
  • Исправлять ли unexpected behavior в C# 7 или оставить как есть, усложнив синтаксис языка для компенсации?
    0

    Не забывайте включать markdown (я тоже забываю :) ).


    Никаких особых неконсистентностей нет, a is Type b все так же матчит только ненулл. То что a is var b матчит нулл запомнить проще, чем весь тот предлагаемый ад. Плюс у нас есть a is {} b, который матчит не нулл точно так же, если лень писать полтора символа идентификатора.

  • Исправлять ли unexpected behavior в C# 7 или оставить как есть, усложнив синтаксис языка для компенсации?
    0
    if (GetModel() is {} m) WriteLine($"It is model {m}");
    else WriteLine("It is null");

    Тоже костылек?