License Delivery maintenance is expected to occur on Saturday, November 30, between 8 AM and 11 AM CET. This may cause a short 3-hours outage in which license-related tasks: license key upload, download, update, SSA validation, access to the license pool and Graphisoft ID authentication may not function properly. We apologize for any inconvenience.
Archicad C++ API
About Archicad add-on development using the C++ API.

Archicad API in .NET???

leceta
Expert
Just a question from a noob: Would it make sense an Archicad API in .NET?? would this make easier to develop connection plugins in other platforms like Grasshopper?

Would it make sense to wrap ArchiCAD C++ library to other languages?

Cheers
aitor
25 REPLIES 25
Anonymous
Not applicable
Ralph wrote:
C++/CLI should really be thought of as a different languag
Thanks for the clarification. I wasn't aware of such a difference between C++ and C++/CLI. I thought is just a library which helps to glue both languages, not the language itself.
Ralph wrote:
MS 'embrace, extend, extinguish'approach to software.
I love conspiration theories . It's probably what every big player used to do... Appel, Goole or is still doing Even Graphisoft dose some limitations based on their business model. However, I think that things are changing towards bigger openness of different technologies.

dfintha wrote:
it would highly impact its performance, which would be a great cost.
If there will be performance drop that's for sure is not worth.

Howevere I'm wondering how Rhino works then? As far as I know the core is running on OpenNurbs library wich is pure C++ library. Howevere there defintly have .NET capabilities in terms of API. They support C#, Python, VB and C/C++. In terms of GUI, they have all WPF capabilities which help to build more dynamic UI Also it's both for WIN and MAC.
I personaly didn't have any preformacne issues also stability of program is very good (I don't count overuse of Grasshopper but it started as 3rd party developemnt ).
leceta
Expert
ARCHICAD is not built in a .NET environment, as it would highly impact its performance, which would be a great cost.
why not consider a solution that not being the best on performance could broaden usability? One could say that this is the philosophy behind a (successful) product like Grasshopper, which not being top of the notch in terms of speed (for example, default type checking and casting of GH components penalize performance in favor of perceived simplicity on use. Still, this default behavior can be tweaked by a more experienced user using scripting tools offered by the system, improving the default performance)

As kzaremba noted, Rhino despite being written in C++ has developed .net alternatives for the "develousers", probably because "A common proverb in the software industry states that you can easily shoot yourself in the foot with programming, but you can take your whole leg off with C++. Scripters rarely have to deal with anymore more severe than a paper-cut"

I consider interesting for the topic talked here this thead from rhino3d forum about their software architecture. https://discourse.mcneel.com/t/rhino-software-architecture/33170

"Whereas most companies provide plugin support for 3rd party developers, McNeel has taken a rather exotic approach which elimates several big problems. The technical term for this approach is “eating your own dogfood” and it essentially boils down to McNeel programmers using the same tools as 3rd party programmers. Rather than adding code to Rhino itself, McNeel programmers prefer writing a plugin instead. For one, if they screw up the collateral damage is usually fairly minor. It also means that the SDK (Software Development Kit, that which is used to build plugins) is rigorously tested internally and there is no need to maintain and support a separate product."
leceta
Expert
a complaint by the guys from https://provingground.io/ about writing plugins for Archicad (2018-08-03):

[...]However, ArchiCAD development is problematic for us. 1. Graphisoft APIs and SDKs require annual costs to access . This is in stark contrast to the the developer-friendly approaches taken by McNeel and Autodesk where APIs, SDKs, and reference materials are abundant and free. 2. From what we see, Graphisoft does not provide modern APIs or scripting language support that fit in our current development stack.

source: https://www.facebook.com/pground.io/posts/2068917699848615

to the marketing department: why so many people still things that developing for archicad cost money?: https://archicad-talk.graphisoft.com/viewtopic.php?f=23&t=62121
leceta
Expert
...With Python one could also use Archicad to design 'fabrication aware'
surface with form finding tools like http://www.shapeop.org/ for further develop the Building on a fully integrated environment with already available modelling/documenting/publishing&coordination tools. Grasshopper? Even needed!
Ralph Wessel
Mentor
leceta wrote:
As kzaremba noted, Rhino despite being written in C++ has developed .net alternatives for the "develousers", probably because "A common proverb in the software industry states that you can easily shoot yourself in the foot with programming, but you can take your whole leg off with C++. Scripters rarely have to deal with anymore more severe than a paper-cut"
That's a misquote of something said by the designer of C++, Bjarne Stroustrup, way back in 1986. His actual statement was:
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off
Because this quote has been widely misquoted and/or misunderstood, Stroustrup has a more detailed explanation on his FAQ page:
Yes, I said something like that (in 1986 or so). What people tend to miss, is that what I said there about C++ is to a varying extent true for all powerful languages. As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. One problem with very supporting and protective environments is that the hard problems may be discovered too late or be too hard to remedy once discovered. Also, a rare problem is harder to find than a frequent one because you don't suspect it.
You can dig yourself into a very deep pit with any language. What many seem to miss is that different programming languages exist for a reason – there is no such thing as a universally applicable language.

It would be great to have Python in ARCHICAD because there is a need for light-weight, easily accessible scripting in that context. It would be good to see it replace GDL in objects too. But there is equally a place for C++, which is by far the most popular language for application, games, 3D and systems development. Architectural design and modelling places very heavy demands on machine resources and presents very complex programming problems. This is exactly why languages like C++ exist.

But also keep in mind that there is no need to explore the full depth or complexity that C++ offers (if that's possible). It is as easy to write readable functional code in C++ as most other software languages, and more so as the language evolves. C++17 is a world away from its origins. You get in trouble when you try to implement complex solutions for simple problems, and C++ can give you that in spades (if you look for it).

Regarding the API, ARCHICAD has a much longer history than others (back to 1982). Some of the harder parts of the API find their roots in that era. C++ is well suited to bridging that gap, but is also capable of gradually migrating it forward into something much simpler and cleaner. I find that most who complain about "no proper API" etc simply mean, "this isn't the familiar Microsoft .NET development environment I've always worked in". But that's an essential reality for many programmers – you need different tools for different jobs. Trying to shoe-horn them all into one tool isn't going to go well.
Ralph Wessel BArch
Software Engineer Speckle Systems
leceta
Expert
it would highly impact its performance, which would be a great cost.
If there will be performance drop that's for sure is not worth.
Grasshopper is very poor on performance side. I mean, graphical programming "vanilla GH". Its not difficult to improve his performance using some lines of c# or ironpython code. But this was a decision by its designer. I wouldnt care and slower performant alternative API to c++ (i say alternative, not substitute), if this decision open the door for greater usability, broader audience, GDL integration with current API (AFAIK current c++ API has not implemented geometry generation ala GDL, has it?), etc...