Павел Соколов, Компилятор видит, что класс someclass. Он знает его размер (в большинстве случаев). Его он и передает в качестве _Size. В _Block он передает void*, чтобы можно было удалять любой класс.
Если вы не пишите свой аллокатор, вам все это не надо. Помните только, что если вы не используете умные указатели, то вам надо всегда удалять указатель. При этом тип у указателя должен быть такой же как в момент создания (или тип в момент удаления от которого унаследован фактический тип и там есть виртуальный деструктор).
Павел Соколов, Ниоткуда. Если вы вызовете 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, не ответят. Вы как очередной изобретатель вечного двигателя. Вам говорят, что нет, никак, вы приходите через неделю, нарисовав на схеме еще один магнит. И опять по новой.
