Quote:Так и не понял, где в твоём коде "разбиение классов по файлам". File1 - это всё, что ли? Ну да ладно.
Не, File1 - это самая первая проба, для теста сделал простейщий класс и выводил его в Unit1.cpp. все получилось! (извини что не написал, но выше я же юнит2 указывал
)
И я пошел дальше, стал выделять в другой файл очень мощный класс - класс патронов. (unit2.cpp\ unit2.h)
почти получилось - но встал вопрос с вектором объектов этого самого класса.
При желании, наверное, можно избежать использования вектора объектов Ammo_First в каком нибудь из файлов, но не всю же жизнь избегать) Избегать не нужно, нужно знать!
Объявляю вектор в Unit1.срр в строках 128 129, в Unit2.cpp в самом начале, (вектор используется только в методе Boom_ammo)
P.S. Если отдельно создавать *h и *cpp в С++ builder, то как их связать потом? Именно в среде билдера - по стандарту когда жмешь на срр, внизу есть вкладка срр\h где можно быстро переходить туда сюда (вот с File1 так не получилось, а с Unit2 норм)
Но это не очень важно, так, ерунда.
(04.07.2012 19:44)Efrit Wrote: [ -> ]5) Все символы, относящие к названию типа, нужно писать слитно. В строке vector <Enemy> у тебя Enemy является частью типа, поэтому пробел ставить не надо. Это же касается и звёздочек в объявлениях указателей.
Как-раз звёздочки - часть имени переменной. Например,
int *i, *j.
(04.07.2012 19:44)Efrit Wrote: [ -> ]3) Почему не стоит обходить вектор через int-переменную, скромно умолчу. Но на всякий случай посоветую почитать про итераторы. Через них всё идёт намного быстрее.
А мне это интересно, весьма удивительная ситуация.
(04.07.2012 19:44)Efrit Wrote: [ -> ]4) Вместо "голых" указателей лучше использовать shared_ptr<> и создавать всё в стеке, избегая кучи вообще. Хотя тебе ещё далековато до такой техники.
Если всё будет созаваться в стеке, то зачем вдруг shared_ptr? Объясни, что за техника. Хотя всё в стеке создавать в любом случае невозможно.
Quote:Как-раз звёздочки - часть имени переменной. Например, int *i, *j.
Не, я говорил про то, что Пакка вообще звёздочку как отдельный символ оформляет. Её нужно либо к названию типа цеплять, либо к названию переменной - но уж никак не отдельно.
Quote:А мне это интересно, весьма удивительная ситуация.
Дык быстрее же, чем обращение по номеру. Итераторы и были специально созданы для того, чтобы быстро перебирать элементы. Плюс, если Пакка захочет поменять вектор на лист - то ему код переписывать не придётся.
Quote:Если всё будет создаваться в стеке, то зачем вдруг shared_ptr? Объясни, что за техника. Хотя всё в стеке создавать в любом случае невозможно.
Я имел в виду, что в стеке будут создаваться сами shared_ptr
А так они создадутся в стеке, то при выходе из текущего блока будут вызваны их деструкторы - а заодно с ними, и деструкторы "хранимых" ими объектов. Сами-то объекты, разумеется, будут создаваться в куче - но время их жизни будет совпадать со "стековой".
А объекты из кучи, которые должны существовать и после выхода из текущего блока, нужны редко. Мне, кроме графических виджетов, больше ничего на ум не приходит... Но у тех в конструкторе хотя бы всегда есть указатель на виджет-родитель, что гарантирует их уничтожение при уничтожении родителя. А если такой связи нет - то получается утечка памяти.
(27.08.2012 20:30)Efrit Wrote: [ -> ]Quote:А мне это интересно, весьма удивительная ситуация.
Дык быстрее же, чем обращение по номеру. Итераторы и были специально созданы для того, чтобы быстро перебирать элементы. Плюс, если Пакка захочет поменять вектор на лист - то ему код переписывать не придётся.
Почему же? По идее, если там начинка - массив, то по номеру - прямое обращение к памяти, а итератор - вызов функции. Надо будет посмотреть.
А можно я тут скромно возражу по поводу *? Это извечная тема холиваров и лично мне удобнее использовать синтаксис int * p поскольку в нём есть мнемоническая подсказка: p имеет тип int*, а *p имеет тип int.
Кстати, насчёт того, что итераторы быстрее: если в плане работы программы, то оптимизатор всё равно всё причешет что станет одинаково, а вот с синтаксической точки зрения, писать это реально быстрее.
Здрасте)
Такой вопрос: как заставить программу на с++ выполнять сторонний код?
В частности хочу написать движок игры на scheme, а сама игра(оформление, менюшки и т.д.) будет на с++.
Для примера пускай это будет морской бой: scheme вычисляет куда попал выстрел, хранит какой из кораблей затоплен какой наоборот, знает все координаты и так далее. А с++ все это красиво выводит.
Как вариант придумал такую схему: scheme все вычисления выводит в файл (постоянное его перезаписывая) а с++ берет данные оттуда, после этого снова отправляет запрос на новые вычисления.
Но это решает только половину проблемы, и то через костыль, т.к. когда я прошу открыться прогу на scheme (из с++) всплывает консолька на пару секунд после чего закрывается и все готово!
Какие есть предложения?
Через DLL - самый очевидный вариант. Пишешь на scheme все нужные функции, компилируешь их в DLL, а потом эти функции вызываешь в своей C-шной программе.
Провел я несколько часов в гугле и пришел к выводу, что шансы сделать DLL на лиспообразном языке стремится к 0 =(
я думал о использовании потоков ввода-вывода. но как бы это сделать - хз
Меня кое где направили копать
здесь
Но я так и не понял смысла этого)
Никаких примеров, скачать нечего, только беглый голый концепт "как это работает"
Может более шарящие люди могут найти в этом ценность) но мне это ничего не дало ((
Побочные сам находил)
Спасибо, постараюсь перевести статью) но общий смысл ясен.
Это правда не совсем то, что хотелось бы, мне это видится как гугл переводчик с русского на английский.
Простые фразы переводит на ура, а в сложных предложениях косячит.
Вот и здесь думаю что прогу на 70+ строк не скомпилит в Сишный код...
А калькуляторы и прочие умножай-списки получатся.
(02.05.2013 17:59)packa Wrote: [ -> ]Это правда не совсем то, что хотелось бы, мне это видится как гугл переводчик с русского на английский.
...
Вот и здесь думаю что прогу на 70+ строк не скомпилит в Сишный код...
не понял о чём ты.
Сразу говорю, если скажу сейчас фигню, простите)
Но статью я понял так, что благодаря тем 3 программам, можно "переводить" код из скима, в Си примерно по следующей схеме:
Code:
(define n 5)
(cond
[(= n 5) (error "error")]
Code:
int n=5;
switch (5) {
case 5: cout << "error";
}
На базовых конструкциях работает на ура!
Но стоит сделать какую нить хитрозакрученную прогу, как "переводчик" выдаст полную фигню.
Может я и ошибаюсь, слишком уж у меня поверхностные знания в этом вопросе...
нет, схемный код отдельно, сишный отдельно. к сишной проге подключают интерпретатор схемы и через него общаются вызывают функции на схеме.