Помоему это запрещено здесь, лучше дождусь нужной кармы и тогда напишу, у меня даже есть интересные решения на шаблонах входящие в категорию ненормального программирования :)
В отличие от C# на С++ я могу написать свой такой StringBuilder с нужными мне наворотами, и с проверками и без проверок. Если на С# такое реализовать, то это тоже будет обычный С++ :)
Эх, у меня есть прекрасные функции для эффективной работы со строками на С++, но к сожалению не хватает кармы для статьи :(
С++ еще хорош тем, что позволяет писать как высокоуровневый код, так и низкоровневый (вплоть до ассемблера), чем не могут похвастаться другие. А иногда низкоуровневая оптимизация ой как нужна, особенно в играх.
Вы сомневаетесь в скорости? Вот небольшой пример, очень часто нужно слаживать строки, точнее к одной строке прилеплять кучу других, друг за другом, так вот обычно реализуется таким образом:
s1 = s2 + s3;
s1 = s1 + s4;
s1 = s1 + s5;
Так вот при каждом плюсе создается новый объект для которого выделяется память потом туда все копируется, при этом происходит куча проверок. Такой код справедлив и для С++ вместе со всеми издержками.
В С++ такое легко ускоряется, достаточно на стеке выделить нужное количество памяти и потом туда простыми strcpy или strcat скопировать, а если подумать, то достаточно будет и memcpy, представляешь какая тут производительность? Да, да, тут проблема с переполнением, но тогда достаточно сделать небольшую проверку и все будет ок, но чаще всего такое не нужно, так как заранее знаешь сколько памяти нужно
Да ну, есть куча либ которые прекрасно работают со строками и без использования шаблонов, я и сам в свое время написал такую для себя. И поверь строки на С++ намного быстрее работают чем «immutable» в других языках, я уже не говорю об низко уровневой обработке, которая дает просто фантастическую производительность, хотя тут не всякий сможет.
Смешной ты, хотя тебе всего лишь 19 лет и опыта почти нет (я на 17 лет старше). Но ничего со временем поймешь. А проект, кстати, от такого решения только выиграл и будет еще долго рабовать своих пользователей ;)
Ну зачем же так? Все я прекрасно знаю. Вы просто забываете что любой интерпретатор кода, а следовательно его jit компилятор должны делать различные проверки на ошибки, напрмер выход за пределы массива, такие проверки в большинстве случаев лишнии, но они хорошо тормозят исполнение кода. Тут конечноделаются различные ухищрения по минимазации отаких проверок, но все равно это медленно.
Мне кажется вы слишком усложнили себе жизнь, этот подход мало чем отличается от обычного через typedef.
Если же идти вашим методом, то могли бы имя функции передовать в конструктор и там уже вызывать GetProcAddress().
В с++ хедер парсится заново, и парсится, и парсится, и…
<blockquote/>
Ну кто вам такое сказал? Если было бы так, то получили бы кучу ошибок переопределения, я же выше написал про #ifndef и #define и это стандартное решение для С++
Имелось ввиду включение заголовочного файла в разных единицах трансляции.
Извените, но в любой языке есть такие включения, иначе откуда брать объявления функций?
Проведем мысленный эксперимент, допустим в С++ есть ограничения на параметры шаблона, a-la C#, либо концепты a-la С++ 0x, как это повлияет на машинный код? На сообщения об ошибках повлияет однозначно.
Машинный код будет однозначно наймного быстрее любого байткода, про ошибки не могу ничего сказать, тут все зависит от опыта
«Каждый заголовочный файл, анализируется столько раз, сколько раз он включается директивой include»
Чтобы такого не было используются #ifndef #define, и тогда нет никакого повторного анализа, это фича самого языка, и тут ничего не поделаешь. На VC++ вообще существует специальный #pragma once
Насчет выдаваемых ошибок согласен с вами, очень часто непонятно на что ругается компилятор, тут уже все завист от опыта.
Критики С++ явно забывают, что это компилируемый язык непосредственно в машинный код, отсюда и возникают многие недостатки, и здесь возможен только контроль во время компиляции, тут ничего не поделашь за скорость выполнения нужно платить.
Ладно, мы с вами на разных языках говорим, точнее о разных подходах, ваш метод не годится в моем случае, так как более трудоемкий и не решает проблем с остановками так как функция Deserialize() возвращает объект целиком готовый и как потом восстановить чтение в вашем случае не понятно. Лучше попробуйте реализовать то что но своим способом, вот тогда и поймете.
Смотри в твоем случае нужна перехватывать все методы которые вызывают проблемы, что по сути довольно медленно, плюс к этому нужно их еще знать. Далее, если остановить поток, то когда? Где это можно определить? Да и как потом продолжить? Другими словами логика разбросана и в целом ее сложно уловить, да и не решает это моих проблем.
В моем случае все в одном месте (правда код не удачный, но это поправимо), да и анализировать проще чистый xml и быстрее, так как задержек никаких нет.
И прочем тут ожидание чтения? Ваш метод тоже зависит от этого.
Эх, у меня есть прекрасные функции для эффективной работы со строками на С++, но к сожалению не хватает кармы для статьи :(
s1 = s2 + s3;
s1 = s1 + s4;
s1 = s1 + s5;
Так вот при каждом плюсе создается новый объект для которого выделяется память потом туда все копируется, при этом происходит куча проверок. Такой код справедлив и для С++ вместе со всеми издержками.
В С++ такое легко ускоряется, достаточно на стеке выделить нужное количество памяти и потом туда простыми strcpy или strcat скопировать, а если подумать, то достаточно будет и memcpy, представляешь какая тут производительность? Да, да, тут проблема с переполнением, но тогда достаточно сделать небольшую проверку и все будет ок, но чаще всего такое не нужно, так как заранее знаешь сколько памяти нужно
Если же идти вашим методом, то могли бы имя функции передовать в конструктор и там уже вызывать GetProcAddress().
Извените, но в любой языке есть такие включения, иначе откуда брать объявления функций?
Машинный код будет однозначно наймного быстрее любого байткода, про ошибки не могу ничего сказать, тут все зависит от опыта
«Каждый заголовочный файл, анализируется столько раз, сколько раз он включается директивой include»
Чтобы такого не было используются #ifndef #define, и тогда нет никакого повторного анализа, это фича самого языка, и тут ничего не поделаешь. На VC++ вообще существует специальный #pragma once
Насчет выдаваемых ошибок согласен с вами, очень часто непонятно на что ругается компилятор, тут уже все завист от опыта.
Критики С++ явно забывают, что это компилируемый язык непосредственно в машинный код, отсюда и возникают многие недостатки, и здесь возможен только контроль во время компиляции, тут ничего не поделашь за скорость выполнения нужно платить.
В моем случае все в одном месте (правда код не удачный, но это поправимо), да и анализировать проще чистый xml и быстрее, так как задержек никаких нет.
И прочем тут ожидание чтения? Ваш метод тоже зависит от этого.