{"action":"created","issue":{"url":"https://api.github.com/repos/chrsmith/bwapi/issues/142","labels_url":"https://api.github.com/repos/chrsmith/bwapi/issues/142/labels{/name}","comments_url":"https://api.github.com/repos/chrsmith/bwapi/issues/142/comments","events_url":"https://api.github.com/repos/chrsmith/bwapi/issues/142/events","html_url":"https://github.com/chrsmith/bwapi/issues/142","id":58648663,"number":142,"title":"interfaces and portability","user":{"login":"GoogleCodeExporter","id":9614759,"avatar_url":"https://avatars.githubusercontent.com/u/9614759?v=3","gravatar_id":"","url":"https://api.github.com/users/GoogleCodeExporter","html_url":"https://github.com/GoogleCodeExporter","followers_url":"https://api.github.com/users/GoogleCodeExporter/followers","following_url":"https://api.github.com/users/GoogleCodeExporter/following{/other_user}","gists_url":"https://api.github.com/users/GoogleCodeExporter/gists{/gist_id}","starred_url":"https://api.github.com/users/GoogleCodeExporter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GoogleCodeExporter/subscriptions","organizations_url":"https://api.github.com/users/GoogleCodeExporter/orgs","repos_url":"https://api.github.com/users/GoogleCodeExporter/repos","events_url":"https://api.github.com/users/GoogleCodeExporter/events{/privacy}","received_events_url":"https://api.github.com/users/GoogleCodeExporter/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/chrsmith/bwapi/labels/auto-migrated","name":"auto-migrated","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/bwapi/labels/Usability","name":"Usability","color":"ededed"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":19,"created_at":"2015-02-23T21:10:47Z","updated_at":"2015-02-23T21:10:52Z","closed_at":"2015-02-23T21:10:48Z","body":"```\nforked issue 134, collecting facts:\n\n1.\nfact:\ncurrent interface is the \"abstract interface\". Read more under \"C++ Mature \nApproach: Using an Abstract Interface\" at \nhttp://www.codeproject.com/KB/cpp/howto_export_cpp_classes.aspx . This \ninterface is only portable between C++ compilers. More on that under \"Why \nThis Works With Other Compilers\". \n\nplan:\nremove the abstract interface and let agents compile the receiver code. \nThis option became available since the bridge from issue 134.\nNote: \"receiver\" is coined as \"agent-side wrapper classes around bridge's \nprotocoll\"\n\n2.\nfact:\nMany nonC++ classes beg to use BWAPI. This feature is best implemented on \nthe agent's side. Since the bridge, the are no drawbacks this way.\n\nsuggestion:\nigalvelis has a promising project using swig to port the C++ receiver into \nany target language. Technically this is a better way than using sockets. \nI suggest making a wiki acticle for nonC++ users about portability and \nlink to igalvelis's project page, where they hopefully, soon will be able \nto download an adapter library for their target language.\nOr we could make igalvelis's project part of BWAPIs and publish the \nadapter libraries with our releases.\n```\n\n-----\nOriginal issue reported on code.google.com by `goo...@teabix.com` on 28 Nov 2009 at 12:58"},"comment":{"url":"https://api.github.com/repos/chrsmith/bwapi/issues/comments/75633202","html_url":"https://github.com/chrsmith/bwapi/issues/142#issuecomment-75633202","issue_url":"https://api.github.com/repos/chrsmith/bwapi/issues/142","id":75633202,"user":{"login":"GoogleCodeExporter","id":9614759,"avatar_url":"https://avatars.githubusercontent.com/u/9614759?v=3","gravatar_id":"","url":"https://api.github.com/users/GoogleCodeExporter","html_url":"https://github.com/GoogleCodeExporter","followers_url":"https://api.github.com/users/GoogleCodeExporter/followers","following_url":"https://api.github.com/users/GoogleCodeExporter/following{/other_user}","gists_url":"https://api.github.com/users/GoogleCodeExporter/gists{/gist_id}","starred_url":"https://api.github.com/users/GoogleCodeExporter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GoogleCodeExporter/subscriptions","organizations_url":"https://api.github.com/users/GoogleCodeExporter/orgs","repos_url":"https://api.github.com/users/GoogleCodeExporter/repos","events_url":"https://api.github.com/users/GoogleCodeExporter/events{/privacy}","received_events_url":"https://api.github.com/users/GoogleCodeExporter/received_events","type":"User","site_admin":false},"created_at":"2015-02-23T21:10:52Z","updated_at":"2015-02-23T21:10:52Z","body":"```\nI tried making this as understandable as possible, still plz read carefully\n------------------------------------------------------------------------\n\nI once suggested to make BWAPI2 interface virtual and thus the \nBWAgent.dll loadable from any C++ compiler. By now I realized 3 ugly problems:\n- A huge amount of functions would have to be rewritten, because of (*). \nProbably \nredefining all templated classes which are used as parameters or return values \ne.g. \nstd::set<Unit*> (used in getAllUnits()) redefine as BWAPI::UnitSet. This is a \nslap \nin the face for anyone using BWAPIv2.5 (, a stab in the gut performance-wise, \nand a \nkick in the groin maintenance-wise ;) ).\n- Alternatives would be needed for variable export (**), where all e.g. \nUnitType \ninformation now is exported with the \"extern\" statement. Another slap for \nBWAPIv2.5 \nusers.\n- people developing BWAPI2 would need to understand the do's, dont's of virtual \ninterfaces or COM development to avoid writing (*) or (**) code. This limits \nour C++ \npossibilities. But we wanted to make a C++ portable interface, so why should we \nlimit C++? This is ridiculous!\n\n(*)BWAPI v2.5 provides functions with templated parameters and return values \nlike \nstd::set<something>. Even std::string is a template (template base class). This \nis a \nproblem for pure virtual interfaces which aim for portability, because \ntemplates are \nnot portable.\n\n(**)BWAPI v2.5 provides variables by \"extern\" syntax. E.g. \nUnits::Terran_Command_Center. This is not a portable way of exporting.\n-----------------------------------------------------------------------\n\nthe above, in a nutshell:\n\nBWAPI2 would with time morph to something not even nearly similar (and worse \nthan) \nto BWAPIv2.5. It's not worth it for only C++ portability. Instead there is a \nbetter \nsolution in issue 159\n-----------------------------------------------------------------------\n\nA virtual interface is in fact a COM interface. I created a COM discussion in \nissue \n174\n```\n\n-----\nOriginal comment by `goo...@teabix.com` on 26 Dec 2009 at 2:31\n* Removed labels: **Type-Enhancement**, **Priority-Medium**"}}