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 =(

я думал о использовании потоков ввода-вывода. но как бы это сделать - хз

Меня кое где направили копать здесь
Но я так и не понял смысла этого)
Никаких примеров, скачать нечего, только беглый голый концепт "как это работает"
Может более шарящие люди могут найти в этом ценность) но мне это ничего не дало ((

вот что нарыл. человек рассматривает твою проблему http://pubby8.wordpress.com/2012/03/22/scheme-with-c/
побочные ссылки в тему:
http://stackoverflow.com/questions/26107...reter-in-c
http://wiki.call-cc.org/man/4/Embedding

Побочные сам находил)

Спасибо, постараюсь перевести статью) но общий смысл ясен.
Это правда не совсем то, что хотелось бы, мне это видится как гугл переводчик с русского на английский.
Простые фразы переводит на ура, а в сложных предложениях косячит.

Вот и здесь думаю что прогу на 70+ строк не скомпилит в Сишный код...
А калькуляторы и прочие умножай-списки получатся.

(02.05.2013 17:59)packa Wrote:  Это правда не совсем то, что хотелось бы, мне это видится как гугл переводчик с русского на английский.
...
Вот и здесь думаю что прогу на 70+ строк не скомпилит в Сишный код...

не понял о чём ты.

Сразу говорю, если скажу сейчас фигню, простите)

Но статью я понял так, что благодаря тем 3 программам, можно "переводить" код из скима, в Си примерно по следующей схеме:
На базовых конструкциях работает на ура!

Но стоит сделать какую нить хитрозакрученную прогу, как "переводчик" выдаст полную фигню.

Может я и ошибаюсь, слишком уж у меня поверхностные знания в этом вопросе...

нет, схемный код отдельно, сишный отдельно. к сишной проге подключают интерпретатор схемы и через него общаются вызывают функции на схеме.