Павел Соколов, Ниоткуда. Если вы вызовете delete на void*, вы получите Undefined behavior.
Где вы взяли delete, который принимает void* _Block и _Size, я не совсем понял. Это наверно какая-то служебная функция менеджера памяти? Вас она волновать не должна, в вашем коде delete - это оператор. Конструкция языка.
А так, компилятор знает, какой деструктор вызывать и сколько памяти освобождать, потому что деструктор вызывается на указателе конкретного типа. Поэтому вызывать деструктор на void*, или скастовать Foo* в Bar* и потом удалить - это UB.
m-kicherov, Все еще не понимаю физический смысл ограничений. Почему надо весь дом класть в одну коробку, но дома на разных концах города могут оказаться в одной коробке. Если в один двор придет 10 разных курьеров, то почему обязательно, что бы в один дом пришлел только один?
LuVairo, а может там initial и final совпадают? Кодируется однозначно, но код виснет.
Сделайте просто через string.Replace. Без ручных преобразований между массивами и строчками.
m-kicherov, а соединять списки можно в любом порядке? Или только в порядке увеличения ключей? А то, например, если списки длинами 2000, 3000, 2000, то подряд их никак не объединить, а вот первый с последним - можно.
LuVairo, 1) у вас там выход за границы массива в GetSubarrayBorders, например, если последний символ в тексте совпадет с первым символом шаблона.
2) Постоянные преобразования в ToCharArray и new string - медленные.
3) Еще и рекурсия зачем-то прикручена.
4) Ваш алгоритм поиска подстроки квадратичный, если использовать встроенные алгоритмы, они будут сильно быстрее. Или пишите какой-нибудь алгоритм Кнута-Морриса-Пратта или Бойера-Мура.
Короче, избавьтесь от рекурсии и используйте встроенные функции работы со строками.
LuVairo, Или еще мерзкий тест. Замена "ba" -> "ab". Фактически происходит сортировка вохдного текста из a и b. В этом примере видно, что нельзя заранее сказать, что какая-то часть текста станет постоянной после замены. Поэтому любые алгоритмы, которые как-то хитро собирают ответ по символьно не сработают.
LuVairo, Еще более страшный тест: "abc"->"bcbcbcbcbcbca". текст "aaaaaaaaaaaaaaaaaaabc". Тут, похоже, кубическое количество символов в ответе. Вообще, похоже, можно экспоненциально сложные тесты делать. Поэтому без разницы, через replace вы там делаете или еще как. Скорее всего у вас ошибка в коде и он виснет.
LuVairo,
Пока придумал плохой тест. Замена "abc"->"cccccccc...cab", текст "abcabcabc...abc". Тут квадратичное количество замен (и длина ответа). Введите такой, только с максимально допустимыми длинами (копируя c и abc). Как долго работает ваше решение с replace, какой time limit?
sadfsy, выравнивание - это про начало выделенного куска. А не про конец или длину. Можно вполне себе иметь 4 байта, выравненных на 16 (начальный адрес имеет кучу нулевых бит в конце.
Но даже если вы вылелите память с запасом, работать будет не правильно. Так, для (0, 0) вы возьмёте все 4 числа в матрице, хотя там только 2 слагаемых должно быть.
Т.е вам придется делать запас в каждой строке матрицы.
Ну, и одну матрицу надо транспонировать. А то у вас строка на строку умножается, а надо - строку на столбец.
haqz, не ответят. Вы как очередной изобретатель вечного двигателя. Вам говорят, что нет, никак, вы приходите через неделю, нарисовав на схеме еще один магнит. И опять по новой.
Где вы взяли delete, который принимает void* _Block и _Size, я не совсем понял. Это наверно какая-то служебная функция менеджера памяти? Вас она волновать не должна, в вашем коде delete - это оператор. Конструкция языка.
А так, компилятор знает, какой деструктор вызывать и сколько памяти освобождать, потому что деструктор вызывается на указателе конкретного типа. Поэтому вызывать деструктор на void*, или скастовать Foo* в Bar* и потом удалить - это UB.