PDA

View Full Version : C++ SDK - When?



Katachi
05-10-2007, 03:09 PM
Hello,

I bought v8 with a free upgrade to v9 because I was told there may be a C++ SDK coming in the v9 cycle. Thatīs the only reason why I have bought a LW license actually because I thought there may be a market for my plugin which is currently c4d only.

Now there is already 9.2 and thereīs still no C++ SDK in sight. So my question is, will there be a C++ SDK in the v9 cycle or not? I have loads of stuff to port to LW but I canīt wait for ages.

Donīt wanna meet trouble halfways but if I donīt even see a chance to get a C++ SDK Iīll be selling my lisense and must look out for another application offering support for sensibly porting my stuff, which would be a shame because I think LW is a great application.

And no I donīt wanna use old-aged wrappers nor do I have time to write my own. I would simply like to know if there will be support for a C++ SDK in the near future (next upgrade the latest) or not.

If this is not to be talked about publically I would love to get an according email with information about this.

Thank you
Best
Katachi

Jabba
05-10-2007, 03:45 PM
This forum is not (unfortunately) the right place to get answers from NT (to be honest, I'm not sure if it's even read by NT - I mean whole, not just randomly some interesting threads).
If you want official reply for your question, try to email NT directly. I'm affraid that here you'll hear just other users.

PS: IF you'll finaly recieve a reply, don't forget to share with us ;) At least I'm very courious about this topic.

RedBull
05-10-2007, 04:11 PM
Hello,

I bought v8 with a free upgrade to v9 because I was told there may be a C++ SDK coming in the v9 cycle. Thatīs the only reason why I have bought a LW license actually because I thought there may be a market for my plugin which is currently c4d only.


C++ SDK has never been mentioned on any public forum, and has never been mentioned officially by any members of NT as being planned in the future or on the 8.x or 9.x. development period..

Whoever 'told you' that there maybe one, this is who you should take it up with, otherwise the SDK is written and supported via C. And if you didn't take a look at the C/SDK or want to increase your sales, it may be up to you to either make a C++ wrapper or use C instead. I wouldn't hold my breath for a new C++ SDK.

There are others third parties such as Lightwolf, who started there own C++ Wrapper of the SDK, perhaps you could offer to help on that project.

jameswillmott
05-10-2007, 05:05 PM
What's the big deal about needing a C++ sdk? I've written plugins with C++ without needing a wrapper, it's not a big deal.

Lightwolf
05-10-2007, 05:10 PM
There are others third parties such as Lightwolf, who started there own C++ Wrapper of the SDK, perhaps you could offer to help on that project.
You're welcome to join in. Just mail me at michael.wolf(at)infinimap.com for details on how to join in.

Cheers,
Mike

Jabba
05-12-2007, 04:04 AM
Lightwolf> I didn't know that! Your da man!

Lightwolf
05-12-2007, 05:02 AM
Lightwolf> I didn't know that! Your da man!
Lol... Well, I'm extending the offer to anybody who has C++ skills and would like to join in.
I'm just keeping it closed now because I don't see it fit for a general release, but it will be open source.

Cheers,
Mike

P.S. I've attached a section of the Doxygen documented class hierarchy which shows the plugin classes currently covered. However, adding new ones is fairly quick to do.

Anti-Distinctly
05-12-2007, 07:58 AM
Hi guys, I don't wish to hijack this thread, but could someone give me an explanation of what exactly a wrapper allows yout to do? Its probably a really daft question.
Personally, I really dont like coding in C. Without object orientation I feel like I'm just making a mess.

Lightwolf
05-12-2007, 09:32 AM
Hi guys, I don't wish to hijack this thread, but could someone give me an explanation of what exactly a wrapper allows yout to do? Its probably a really daft question.
Personally, I really dont like coding in C. Without object orientation I feel like I'm just making a mess.
Basically (talking about my wrapper, lwpp) - bring back the object orientation that is somehow in the LW SDK anyhow but implement it in a way that is native to the programming language used: C++ in this case.
So, all the globals and the plugins are classes. You can extend and combine them (i.e. a XPanelShaderHandler is a ShaderHandler using an XPanel UI). It also allows me to extend the globals with some extra functionality (note in the class diagram that lwpp:ImageUtil is also a lwpp::PopUpCallBack, used to display a list of image file formats as a pop-up in an XPanel).
Also, since the classes contain skeleteon code (usually virtual functions that can be, but don't _have_ to be replaced by the user) there is less code to write to get a plugin going.

Mind you, there is still plenty of stuff I'd like to add... but I only add things that I directly need at the moment.

Cheers,
Mike

Anti-Distinctly
05-12-2007, 09:56 AM
Sounds good. Is it available to download in its current state of functionality?

Lightwolf
05-12-2007, 10:01 AM
Sounds good. Is it available to download in its current state of functionality?
Not publicly.
However, mail me ( michael.wolf(at)infinimap(dot)com ) and set up an account on our forum: http://forums.infinimap.com .
I'll then upgrade your account to get to the closed lwpp section.

I'm just not offering it for public download because I don't see it as being fit for a wide release. Having said that, any help in changing that is highly appreciated :D

Cheers,
Mike

Katachi
05-14-2007, 05:31 AM
Hi,

thank you first of all for the answers. I will try to contact NewTek directly via email (kind of strange not even 1 Newtek guy is browsing this forum..)

@Lightwolf: This is good news. Iīll be contacting you in the next few days. Thank you! very appreciated.

@jameswillmot: what do you mean? Do you mean you used the C SDK in your C++ plugins, so only working with the subset? That wouldnīt allow you to really work in OOP would it?

Lightwolf
05-14-2007, 05:37 AM
@jameswillmot: what do you mean? Do you mean you used the C SDK in your C++ plugins, so only working with the subset? That wouldnīt allow you to really work in OOP would it?
Well, it still allows you to work in an OO way... but you'd not use the OO reletaed features of C++ as far as the SDK is concerned.
I mean, after all, OO is a way of thinking, not a language feature. The language just makes it easier ;)

Cheers,
Mike

Sensei
05-15-2007, 10:01 AM
@jameswillmot: what do you mean? Do you mean you used the C SDK in your C++ plugins, so only working with the subset?

Of course, the all LightWave's professional 3rd party developers work this way.. Write plug-ins in C++.. It would be nightmare writing 1 milion line of code with ANSI C..

Lightwolf
05-15-2007, 10:12 AM
It would be nightmare writing 1 milion line of code with ANSI C..
Like newtek or luxology, right? ;)

Cheers,
Mike

Sensei
05-15-2007, 12:26 PM
Like newtek or luxology, right? ;)


Do you think so they're all internally plain C??

Deep Purple
05-15-2007, 01:22 PM
Do you think so they're all internally plain C??

Three years ago that was right,
but not any more ;-)

Lux is most probably still writing plain C,
that is speculation though.

- DavidF

Lightwolf
05-15-2007, 01:44 PM
Three years ago that was right,
but not any more ;-)

Relieve to hear that.... I hope it will one day shine through to the top of the app as well...

Cheers,
Mike

Sensei
05-15-2007, 01:57 PM
Lux is most probably still writing plain C,
that is speculation though.

That's sick. lol :)

Anti-Distinctly
05-27-2007, 03:08 AM
But seriously. I need object orientation to program. I simply suck at it way too much and just get confused coding linearly in C :|

Lightwolf
05-27-2007, 03:15 AM
But seriously. I need object orientation to program. I simply suck at it way too much and just get confused coding linearly in C :|
Well, you can use OO in C as well... the language is just not suited for it ;)

Also, having an OO based wrapper for the SDK and using OO in your own code are two different things... and there are people out there who write linear code in C++ as well ;)

Cheers,
Mike

Ember
05-29-2007, 01:09 AM
First of all, let me add my vote for a C++ SDK. So far I haven't learned the LW SDK since it is just C (tried once, got way too frustrated to Cs antique way of doing things). I'm interested on that C++ wrapper but unfortunately I'm currently way too busy to actually add anything to it. :thumbsdow

One can program in an OO way in C yes, but there are things which would be REALLY hard to do in any sensible way in C. For example inheritance. That's a major advantage for OOP based languages. C++ also has a lot of stuff making it easier for a programmer to keep all the straws in his hands like templates (yes, can be done in C, just clunkier and more error prone), const keyword (hell, no such thing in C! One has to use #define), dynamic binding with inheritance (a huge bonus, needs to be done with function pointer mess in C), usable containers in STL (std::string, all dynamic containers like std::vector, std::map etc), Boost in the next official release of C++ and already one can use it (smart pointers and a lot of other stuff) and so on...

C also has basically no error checking on type conversions and with void pointers this is even a bigger problem. C++ doesn't have any checking either with C -style casts but then again it provides a bunch of casting functions based on templates which do the checking (dynamic_cast, static_cast, reinterpret_cast etc).

I personally loathe C and tolerate C++. C is one step closer to assembly than C++. In some cases this is an advantage but when doing high level software - or as in this case plugins - it's not that.

Wow, talk about a raving lunatic... Better to stop here especially since this post is going somewhat offtopic. :D

Lightwolf
05-29-2007, 01:38 AM
I'm interested on that C++ wrapper but unfortunately I'm currently way too busy to actually add anything to it. :thumbsdow

That's allright. Only one other person but me actually added to it by now. So, if you're interested, sign up and send me a PM.

Cheers,
Mike

ShawnStovall
06-03-2007, 01:39 PM
I actually found a C to C++ converter that you could use for the examples:
http://www.scriptol.org/ctocpp.php

I haven't figured out how to use it yet though, haven't learned much Python...

Lightwolf
06-06-2007, 02:24 AM
From a recent thread on the Luxology boards :)
The C++ compiler compiles C as well.
There is also a thread where Stuart mentions reasions for why the prefer C (which I don't share).

Cheers,
Mike

Sensei
06-06-2007, 02:59 AM
There is also a thread where Stuart mentions reasions for why the prefer C (which I don't share).


Ohh.. What he said? :) I am curious..

"I am too old to change"? :D

LOL

Lightwolf
06-06-2007, 03:01 AM
Ohh.. What he said? :) I am curious..

"I am too old to change"? :D

I don't exactly recall it, but a quick search on their forum (for Ferguson and C++) should reveal it.

Cheers,
Mike

Sensei
06-06-2007, 03:53 AM
I suppose so you were talking about this...
http://forums.luxology.com/discussion/topic.aspx?id=4223&show=ferguson&page=1


All programming languages are pretty much the same. Any language you choose will let you write fast code or slow code, procedural code or object-oriented code, readable code or unintelligible gibberish. Some may provide more features and helpful shortcuts than others, but in all cases you are relying on your own skills and sweat to make the real work happen.

The best langauge for learning programming is the one that suits the project you want to create. If you want to create web services, Java or Perl are probably better choices than C or C++. Java can run directly in a browser, and there are vast Perl libraries for server-based scripting. If you want to build some simple GUI interfaces, however, you might want to learn with Visual Basic. You'll get something that works more easily so you'll be less frustrated and have fun, and the concepts you learn there will be applicable to other languages if you decide you want to do something different.

For general 3D graphics work you have a number of choices. The trend for academic 3D work is to use Java, so there is an increasing amount of code samples available in that language. The reason for this is that Java is a relatively modern language and is highly portable. You could also write in C or C++. That code will generally run faster, but it will be harder to get something working and you'll be more committed to a particular platform or system. If you are concerned about portability it's probably also a good idea to stick with OpenGL rather than something like Direct3D.

Our SDK will come with C and C++ headers. The C API is not for the faint of heart, so it'll probably be best to stick with C++. The C++ API, for which you get the complete source, is really just a wrapper around the C API. This should allow code jocks to create wrappers for other language families.

We don't use C++ in our core code for the simple reason that we don't need it. We can do everything we need more easily with C, and large-scale C++ projects are considerably harder to manage. As a so-called modern object-oriented language, C++ is deficient in many ways:

1) Intrinsic types are not objects. I can't perform a "+4" method on a number object and have it do the right thing for floats and ints. This is the single biggest drawback of trying to bolt OO jet-engines onto the C Yugo.

2) Data types are statically defined. No anonymous messages or metaclasses. What are we, Puritans?

3) Construtors and destructors. The Horror. The Horror.

4) Public/private/friend. When I first read about this I thought they were joking. One of the key principles of OO programming is data-hiding. How can you hide your data if the language won't support opaque objects?

5) Try to keep a straight face while talking about a "virtual static member."

I could go on and on, but then we'd never get 201 done...

dballesg
06-06-2007, 03:54 AM
I don't exactly recall it, but a quick search on their forum (for Ferguson and C++) should reveal it.

Cheers,
Mike


I found them.

Similar reasons he gave years ago to not have NURBS implemented on LW instead Cardinal curves! :)

I reserve my opinion about his opinions! :)

Best regards,
David

Jarno
06-06-2007, 04:16 AM
We don't use C++ in our core code for the simple reason that we don't need it. We can do everything we need more easily with C, and large-scale C++ projects are considerably harder to manage. As a so-called modern object-oriented language, C++ is deficient in many ways:

...wow. Just...wow...

---JvdL---

dballesg
06-06-2007, 04:28 AM
...wow. Just...wow...

---JvdL---

I will never express it on a better way! :)

Lightwolf
06-06-2007, 01:04 PM
Just curious, since you're giving them a hard time in this thread :)
I'm not really giving them a hard time, they made their choice (even though I do believe it isn't the best one).

I assume a lot of people here use both, and probably stick with C++ now for a variety if reasons.
I've got a few: My code quality improved by leaps and bounds (and still does, which is reassuring), less bugs (since the compiler catches more and my code tends to be more modular and reused more as a result of that) plus I find it to be easier to writer smarter - and thus faster - code.
Then again, that is my experience, and I'm sure my style of programming in C would be different now as well - but it would also hurt a lot to step back ;)

Cheers,
Mike

dballesg
06-06-2007, 02:22 PM
I know nothing about programming, but I know about speed and obviously their renderer is very efficient, both in regards to speed, quality and memory use - compared to LightWave's apparently rewritten raytracer. Except that I can't fault LightWave's render quality :) So if C fits them well, what's so wrong about using it? The quality of their product certainly is top class - at least the renderer, which is what I know best in their app.

So why are you guys busting their balls, when clearly they are technologically ahead?

Just curious, since you're giving them a hard time in this thread :)

In my case because it is the same guy that said that HE never will implement NURBS curves in LW due they can not do a perfect circle? :)

LWCad circles look very perfect to me! :)

I do not want to hijack the thread, but I doubt they are technologically ahead, their product it is a modeler, and a renderer solution. It is MY opinion.

Please try to bone and animate a character in Modo! :devil:

Looks to me, this guy opinion are really biased about what he consider the "best" way to do anything.

Best regards,
David

DarkLight
06-07-2007, 04:20 AM
I assume a lot of people here use both, and probably stick with C++ now for a variety if reasons.


A lot of the work i do i'm still using C as a lot of the programming i do is on embedded computer systems and there's not an option for C++ on most of them.

Given the choice though i would use C++ if i could.

Anti-Distinctly
06-07-2007, 02:48 PM
neverko, Modo's render speed is not necessarily inherent to its C base, it's just more likely that they have better algorithms to do things or something like that(?). I done some programming trying to implement something I read in a paper, and there are so many places you can or have to branch away from exactly the way the paper suggests you do things. For example, though NT and Lux both implemented Final Gather, but I doubt the code is identical. i.e. there are always different ways of doing things, some faster than others. Oh, and their area lights I'm sure are better too ;)
I do however, find it kind of backward that they would not 'advance' to C++. heck, I'm not too fond of using C++ as I like C#. Now thats an easy language :D

alexionne
06-09-2007, 06:41 AM
I've just wrote my first LW plugin. And did it in "C++". There is really big difference between C and C++, and it's not just OO. You get really lot of stuff with C++ compiler even without OO. So, why I said "C++"? Simply, I haven't used any OOP - I don't need it :) I think I understand why they don't need it either, and why they try not to use it. And I actually agree to almost all of Lux's arguments against C++ :)

Anyway, LW forever!

Lightwolf
06-09-2007, 07:25 AM
I think I understand why they don't need it either, and why they try not to use it.
Which is strange. I don't think the modo architecture is that far away from the LW SDK... and the LW SDK can be mapped to C++ classes easily which does make writing plugins a lot less of a painful process (both in terms of typing as well as in terms of debugging).
So in a way, the LW SDK is C+ written in C... ;)

Cheers,
Mike

ShawnStovall
06-09-2007, 08:05 AM
But for us who don't know how to translate it, it's a pain.:grumpy:

Sensei
06-09-2007, 08:11 AM
But for us who don't know how to translate it, it's a pain.:grumpy:

That would mean that you don't know how to program in general.. ;)

Example wrapper for LWTimeInfo:


#include "Debug.h"
#include "LWCTimeInfo.h"

LWCTimeInfo::LWCTimeInfo() : LWCGlobalFunc()
{
ENTER( "LWCTimeInfo::LWCTimeInfo()" );
LEAVE( "LWCTimeInfo::LWCTimeInfo()" );
}

LWCTimeInfo::LWCTimeInfo(
GlobalFunc *globalfunc ) : LWCGlobalFunc( globalfunc )
{
ENTER( "LWCTimeInfo::LWCTimeInfo()" );
LEAVE( "LWCTimeInfo::LWCTimeInfo()" );
}

LWCTimeInfo::~LWCTimeInfo()
{
ENTER( "LWCTimeInfo::~LWCTimeInfo()" );
LEAVE( "LWCTimeInfo::~LWCTimeInfo()" );
}

LWTimeInfo *LWCTimeInfo::GetTimeInfo( void ) const
{
ENTER( "LWCTimeInfo::GetTimeInfo()" );

LWTimeInfo *timeinfo = (LWTimeInfo *) Global( LWTIMEINFO_GLOBAL );

LEAVE( "LWCTimeInfo::GetTimeInfo()" );
return( timeinfo );
}

LWTime LWCTimeInfo::GetTime( void ) const
{
ENTER( "LWCTimeInfo::GetTime()" );

LWTime time = (LWTime) 0.0;

LWTimeInfo *timeinfo;
timeinfo = GetTimeInfo();
if( timeinfo != NULL )
{
time = timeinfo->time;
}

LEAVE( "LWCTimeInfo::GetTime()" );
return( time );
}

LWFrame LWCTimeInfo::GetFrame( void ) const
{
ENTER( "LWCTimeInfo::GetFrame()" );

LWFrame frame = (LWFrame) 0.0;

LWTimeInfo *timeinfo;
timeinfo = GetTimeInfo();
if( timeinfo != NULL )
{
frame = timeinfo->frame;
}

LEAVE( "LWCTimeInfo::GetFrame()" );
return( frame );
}


Usage:



LWCTimeInfo timeinfo( globalfunc );
printf( "Current frame %g\n", timeinfo.GetFrame() );

Lightwolf
06-09-2007, 08:21 AM
Another option would be:

class TimeInfo : protected GlobalBase<LWTimeInfo>
{
public:
LWTime Time(void)
{
if (globPtr) return globPtr->time;
else return 0;
}

LWFrame Frame(void)
{
if (globPtr) return globPtr->frame;
else return 0;
}
};
Usage is pretty much the same... and I guess the functions could be const as well.

Cheers,
Mike

jay3d
06-09-2007, 09:25 AM
Hi guys!

I see some great programmers and SDK hackers here :thumbsup:

so if you allow me to take that chance and ask about some explanation and demystifying of the LayoutTool Class, because the documentation in the SDK regarding that never updated since 7.0!?:screwy:

so please some of you guys explain to me some further information about how to use that class efficiently and about that XPanel thing and what the difference between View type XPanel and the other one and how it works through LayoutTool :help:

i know those are many requests but you're the best ones to ask :thumbsup:

Thank you very much!! :bday:

Sensei
06-09-2007, 09:45 AM
Layout Tool class is broken and they never had user-interface even though docs say something different..

jay3d
06-09-2007, 09:56 AM
Layout Tool class is broken and they never had user-interface even though docs say something different..

yeah, but many tools use that like bone tools and IK booster, Visor, sliders, spline control ... etc.

i found some sample on a japanese site but i wonder how it works, i though some compiling mismatching, it called lassotool, find it in the attachement plz,

what i want to know is that really broken or some incompatibility with 9.2 SDK

Sensei
06-09-2007, 10:00 AM
As far as I can see, it has empty panel() call-back..



/*
* ToolPanel
*/

XCALL_(static LWXPanelID)
ToolPanel( LWInstance inst )
{
ToolData *data = (ToolData *) inst;
return NULL;
}

Sensei
06-09-2007, 10:05 AM
Where did you see panel in IK Booster Tool?

Visor is CustomObjHandler.. with additional tool just for adjusting plane, but still without LayoutTool panel AFAIK..

If Custom object is used for panel and special redrawing, that's not the same as Layout tool panel..

Sensei
06-09-2007, 10:12 AM
Another option would be:

That's REALLY interesting option, but you should show also GlobalBase implementation.. Without it especially to those not familiar with LW and C++, this code is not useful..

jay3d
06-09-2007, 10:18 AM
ah!, now i see :D

Thanks!

another thing that is it possible to call or modify/notify the CustomObject of changes through LayoutTool?

Sensei
06-09-2007, 10:34 AM
Communication Ring global is for this, but in your own plugin global variable and InstUpdate global will work too..

dballesg
06-09-2007, 12:19 PM
That's REALLY interesting option, but you should show also GlobalBase implementation.. Without it especially to those not familiar with LW and C++, this code is not useful..

Hi everyone! :)

A few hours without internet and you post like mad here! :)

Sensei, the code that LightWolf showed it is from its C++ wrapper, and he said before that anyone that email or pm him can get access to it, always need help him to finish it.

Jay3D I think you will find useful to pm mike too and if both of you can help with the wrapper you're welcome! :)

Best regards,
David

Sensei
06-09-2007, 12:29 PM
A few hours without internet and you post like mad here! :)

I am just feeling time between fixing VirtualRender and re-rendering.. ;) Now, all my computers are rendering 32000x24000 image..



Sensei, the code that LightWolf showed it is from its C++ wrapper, and he said before that anyone that email or pm him can get access to it, always need help him to finish it.


Yes, I know.. We talked together today on Skype, but I didn't want my message to look like out of context for others.. ;)

Lightwolf
06-09-2007, 04:16 PM
That's REALLY interesting option, but you should show also GlobalBase implementation.. Without it especially to those not familiar with LW and C++, this code is not useful..
It wasn't meanrt to be... just meant to show a concept. But anyhow, here are the basics:
globals.h


#define IMPLEMENT_GLOBAL(x, y) \
template<> x * GlobalBase< x >::globPtr = 0; \
template<> long GlobalBase< x >::usage_count = 0; \
template<> char * GlobalBase< x >::m_globalName = y;

//! LightWrap++ related classes and functions
namespace lwpp
{
//! Superglobal storage for GlobalFunc
/*!
* This is shared by all plugins within the DLL, and should be initialized as soon as possible
*/
extern GlobalFunc *SuperGlobal;
//! Set Superglobal
void SetSuperGlobal(GlobalFunc *g);

//! Template class base for any kind of global that will be AQUIREd/RELEASEd,
template<class G>
class GlobalBase
{
protected:
static char *m_globalName; //!< Name of the global, should probably be static too
static long usage_count; //!< Usage count for the global
static G *globPtr; //!< Pointer to the global functions
public:
//! Constructor, acquire the global and increase the usage counter
GlobalBase()
{
if ((globPtr = reinterpret_cast<G *> (SuperGlobal(m_globalName, GFUSE_ACQUIRE))) != 0)
{
usage_count++;
}
else
{
throw MissingGlobal(name);
}
}
//! Destructor, RELEASE the global if usage counter drops to 0
virtual ~GlobalBase()
{
usage_count--;
if (usage_count <= 0)
{
SuperGlobal(m_globalName, GFUSE_RELEASE); // release global
}
}
virtual bool available()
{
return (globPtr != 0);
}
G* operator->() {return globPtr;}

virtual G *getGlobal() {return globPtr;}
};

and global.cpp (just a snippet)


#include "global.h"
namespace lwpp
{
//! Initialize and store superglobal GlobalFunc
GlobalFunc *SuperGlobal = 0;

void SetSuperGlobal(GlobalFunc *g)
{
SuperGlobal = g;
}
IMPLEMENT_GLOBAL(LWTimeInfo, LWPP_TIMEINFO_GLOBAL)

Lightwolf
06-09-2007, 04:16 PM
That's REALLY interesting option, but you should show also GlobalBase implementation.. Without it especially to those not familiar with LW and C++, this code is not useful..
It wasn't meanrt to be... just meant to show a concept. But anyhow, here are the basics:
globals.h


#define IMPLEMENT_GLOBAL(x, y) \
template<> x * GlobalBase< x >::globPtr = 0; \
template<> long GlobalBase< x >::usage_count = 0; \
template<> char * GlobalBase< x >::m_globalName = y;

//! LightWrap++ related classes and functions
namespace lwpp
{
//! Superglobal storage for GlobalFunc
/*!
* This is shared by all plugins within the DLL, and should be initialized as soon as possible
*/
extern GlobalFunc *SuperGlobal;
//! Set Superglobal
void SetSuperGlobal(GlobalFunc *g);

//! Template class base for any kind of global that will be AQUIREd/RELEASEd,
template<class G>
class GlobalBase
{
protected:
static char *m_globalName; //!< Name of the global, should probably be static too
static long usage_count; //!< Usage count for the global
static G *globPtr; //!< Pointer to the global functions
public:
//! Constructor, acquire the global and increase the usage counter
GlobalBase()
{
if ((globPtr = reinterpret_cast<G *> (SuperGlobal(m_globalName, GFUSE_ACQUIRE))) != 0)
{
usage_count++;
}
else
{
throw MissingGlobal(name);
}
}
//! Destructor, RELEASE the global if usage counter drops to 0
virtual ~GlobalBase()
{
usage_count--;
if (usage_count <= 0)
{
SuperGlobal(m_globalName, GFUSE_RELEASE); // release global
}
}
virtual bool available()
{
return (globPtr != 0);
}
G* operator->() {return globPtr;}

virtual G *getGlobal() {return globPtr;}
};

and global.cpp (just a snippet)


#include "global.h"
namespace lwpp
{
//! Initialize and store superglobal GlobalFunc
GlobalFunc *SuperGlobal = 0;

void SetSuperGlobal(GlobalFunc *g)
{
SuperGlobal = g;
}
IMPLEMENT_GLOBAL(LWTimeInfo, LWPP_TIMEINFO_GLOBAL)

Lightwolf
06-09-2007, 04:18 PM
That's REALLY interesting option, but you should show also GlobalBase implementation.. Without it especially to those not familiar with LW and C++, this code is not useful..
It wasn't meant to be... just meant to show a concept. But anyhow, here are the basics:
globals.h


#define IMPLEMENT_GLOBAL(x, y) \
template<> x * GlobalBase< x >::globPtr = 0; \
template<> long GlobalBase< x >::usage_count = 0; \
template<> char * GlobalBase< x >::m_globalName = y;

//! LightWrap++ related classes and functions
namespace lwpp
{
//! Superglobal storage for GlobalFunc
/*!
* This is shared by all plugins within the DLL, and should be initialized as soon as possible
*/
extern GlobalFunc *SuperGlobal;
//! Set Superglobal
void SetSuperGlobal(GlobalFunc *g);

//! Template class base for any kind of global that will be AQUIREd/RELEASEd,
template<class G>
class GlobalBase
{
protected:
static char *m_globalName; //!< Name of the global, should probably be static too
static long usage_count; //!< Usage count for the global
static G *globPtr; //!< Pointer to the global functions
public:
//! Constructor, acquire the global and increase the usage counter
GlobalBase()
{
if ((globPtr = reinterpret_cast<G *> (SuperGlobal(m_globalName, GFUSE_ACQUIRE))) != 0)
{
usage_count++;
}
else
{
throw MissingGlobal(name);
}
}
//! Destructor, RELEASE the global if usage counter drops to 0
virtual ~GlobalBase()
{
usage_count--;
if (usage_count <= 0)
{
SuperGlobal(m_globalName, GFUSE_RELEASE); // release global
}
}
virtual bool available()
{
return (globPtr != 0);
}
G* operator->() {return globPtr;}

virtual G *getGlobal() {return globPtr;}
};
and global.cpp (just a snippet)


#include "global.h"
namespace lwpp
{
//! Initialize and store superglobal GlobalFunc
GlobalFunc *SuperGlobal = 0;

void SetSuperGlobal(GlobalFunc *g)
{
SuperGlobal = g;
}
IMPLEMENT_GLOBAL(LWTimeInfo, LWPP_TIMEINFO_GLOBAL)
}

Matt
06-10-2007, 06:04 AM
Read this interview with David Ikeda here:

David Ikeda: programming behind the 3D curtains
http://www.pingmag.jp/


Then, I started working for them in May 2005, and I program with C++. LightWave used to be strictly C-based and now we are slowly migrating to C++.

dballesg
06-10-2007, 06:23 AM
HI Matt,

Thanks for the link. I think Kurtis must show it on the next Newsletter! :)

Best regards,
David

ShawnStovall
06-10-2007, 01:19 PM
WOW!! Only ten programmers?!?!

Sensei
06-10-2007, 01:39 PM
WOW!! Only ten programmers?!?!

In programming sometimes the less the better.. ;)
When there is many people the most of time they're talking about how to do something, without actually doing.. And waste time on writing docs and comments what they do, so others will understand their work..

Lightwolf
06-10-2007, 04:07 PM
And waste time on writing docs and comments what they do, so others will understand their work..
Absolutely a waste of time... just imagine, if a new team is forced to work with the old code, they'd actually understand it by looking at the docs and comments. I mean, that would be daft, right? ;)

Cheers,
Mike

Sensei
06-11-2007, 12:06 AM
Hehe.. But if nobody read that part ever, or in the next 5 years? Then you simply wasted time commenting and documenting.. :P

Lightwolf
06-11-2007, 12:30 AM
Hehe.. But if nobody read that part ever, or in the next 5 years? Then you simply wasted time commenting and documenting.. :P
Of course, especially since all code you write will be bug free, and there is nothing that will need to be changed in that part of the code ever. I also expect every programmer to exactly remembers why he wrote every line of code he wrote up to ten years ago (and new dev team members to understand it just as well).

The good thing is, not documenting your code is usually a good reason for a re-write as well... it can be so much quicker to do ;)

Cheers,
Mike

Anti-Distinctly
06-11-2007, 01:23 AM
Hell, I can't recall what the code that I wrote a few weeks ago does. If I didn't comment my code, I'd end up in a world of pain, not to mention anyone else who tried to decypher it.

Sensei
06-11-2007, 01:44 AM
Hell, I can't recall what the code that I wrote a few weeks ago does. If I didn't comment my code, I'd end up in a world of pain, not to mention anyone else who tried to decypher it.

Split up code to small parts. If function, method or class is not self explanatory, split it again more.. ;)
Don't use short names, they're confusing and impossible to remember even though you have less to type.. But in longer period of time, they make code unreadable..

If you see my code, you would know what exactly is doing class or method just by name..
f.e. from VirtualRender:
void CVRCompositeRequester::GetOutputFormatExtension( char *extension, size_t size );
it's settings window that's opened after pressing VirtualRender Composite generic tool, and it fills supplied buffer by file extension of currently choosed by user output file format..


void CVRCompositeRequester::GetOutputFormatExtension(
char *extension,
size_t size )
{
ENTER( "CVRCompositeRequester::GetOutputFormatExtension()" );

if( ( extension != NULL ) && ( size > 0 ) )
{
memset( (void *) extension, 0, size );

int output_format = GetOutputFormat();
if( output_format == 0 )
{
strncpy( extension, "raw", size );
}
else if( output_format >= 1 )
{
m_ImageUtil.GetSaverExtension( output_format - 1, extension, size );
}
}

LEAVE( "CVRCompositeRequester::GetOutputFormatExtension()" );
}

Then what are doing method used in this example? You know already.. But here they're:


void TACImageUtil::GetSaverExtension(
int saver_index,
char *buffer,
size_t size )
{
ENTER( "TACImageUtil::GetSaverExtension()" );

if( ( buffer != NULL ) && ( size > 0 ) )
{
memset( (void *) buffer, 0, size );

const char *name;
name = SaverName( saver_index );
if( name != NULL )
{
int length = (int) strlen( name );
if( name[ length - 1 ] == ')' )
{
for( int i = length - 2; i >= 0; i-- )
{
if( name[ i ] == '(' )
{
if( name[ i + 1 ] == '.' )
{
int len = ( length - 1 ) - ( i + 2 );
for( int j = 0; j < len; j++ )
{
buffer[ j ] = name[ j + i + 2 ];
}
}
break;
}
}
}
}
}

LEAVE( "TACImageUtil::GetSaverExtension()" );
}



int CVRCompositeRequester::GetOutputFormat( void ) const
{
ENTER( "CVRCompositeRequester::GetOutputFormat()" );

int output_format = m_Output_Format;

LEAVE( "CVRCompositeRequester::GetOutputFormat()" );
return( output_format );
}

jay3d
06-11-2007, 03:05 AM
Hi,

Sorry for breaking through :D ,

but anyone notice that wonderful language http://www.digitalmars.com/d

i wonder if we can code the core algorithms with that in a separate source compiled as .obj or .lib and link it with the plugin main file, so we can call those functions in other language from out main plugin source file :)

any ideas?

dballesg
06-11-2007, 03:51 AM
Hi,

I vote for not complicate things more! :)

Aside I didn't found the have a x64 bits, UB or Mac versions, so if you want your plugin compiled for those platforms I think you will be out of luck and with a bunch of users complaining why you do not have your plugin for those platforms! :)

Best regards,
David

jay3d
06-11-2007, 04:15 AM
Hi,

I vote for not complicate things more! :)

Aside I didn't found the have a x64 bits, UB or Mac versions, so if you want your plugin compiled for those platforms I think you will be out of luck and with a bunch of users complaining why you do not have your plugin for those platforms! :)

Best regards,
David

as for the complications it seems from the comparisons that this language tries to simplify things more ... :)

and for the support of other platforms , there's an implementation here : http://dgcc.sourceforge.net/ that supports 64 bit targets

and here : http://gdcwin.sourceforge.net/ for Window$

and here : http://gdcmac.sourceforge.net/ for Mac OS X

:thumbsup:

dballesg
06-11-2007, 05:29 AM
Hi Jay3D :)

Then I suppose you only need to do a wrapper in D around the .h and .c files of the SDK! :)

But it is a HUGE task! :)

Look to LightWolf wrapper, even when now I am trying to put my humble help on it, it is far to be finished! :)

Lightwolf
06-11-2007, 08:45 AM
Hi,

Sorry for breaking through :D ,

but anyone notice that wonderful language http://www.digitalmars.com/d

I actually had a quick look at it and quite liked it when I first saw it (a few months ago).... IT does have a nice, simple clean and concise design. However, I really miss multiple inheritance, which I actually use a lot in C++.


i wonder if we can code the core algorithms with that in a separate source compiled as .obj or .lib and link it with the plugin main file, so we can call those functions in other language from out main plugin source file :)

That would be a plugin to a plugin, and could probably be written as a DLL/shared library.

Cheers,
Mike

Lightwolf
06-11-2007, 08:48 AM
and for the support of other platforms , there's an implementation here :
Unfortunately, these are all front-ends for GCC (not the best choice on windows) - which also means you won't get any native code optimization as you do with C++.

Give it a few years and it might start to get interesting, right know I see it more as an academic project (albeit an interesting one).

Cheers,
Mike

Lightwolf
06-11-2007, 08:49 AM
Look to LightWolf wrapper, even when now I am trying to put my humble help on it, it is far to be finished! :)
Oh yeah... well, I only tend to add the bits I need, but any help is appreciated.
Then again it is a wrapper and not just an interface. But what would be the point of using D if you're still stuck with a C based API that hasn't been wrapped to D?

Cheers,
Mike

Matt
06-11-2007, 11:59 AM
My wonderful code writing skills! I HAVE to comment, otherwise I forget how/why I did stuff, plus I was giving these scripts away, so hopefully someone else might find them useful.

Clearly this is probably going too far, but I think a few comments help out other people working on your code in a BIG way, it is a GOOD idea in my opinion!



// Grab user selection, if nothing is selected it will use the 'everything is selected' rule
selmode( USER );


// Work out the rotate angle based on the number of copies the user requested

radial_angle = number( 360 / copies );



// Start undo grouping so we only use one undo for the whole cloning process
undogroupbegin() ;



// Loop until we reach the number of copies requested

for(LOOP = 1;LOOP < copies;++LOOP)
{
// Copy selected object
copy();

// Rotate the selected object based on the angle, axis and axis centre
rotate( radial_angle, selected_axis, radial_centre );

// Paste the copied object in the position before it was rotated
paste();
}



// Turn off undo grouping

undogroupend() ;

Ember
06-11-2007, 02:58 PM
Just few comments on things mentioned on this thread:

Commenting
In my honest opinion no code can ever be self-explanatory enough that comments wouldn't be helpful. Never. Anyone who has ever programmed in Java and has read the JDK Javadocs should get a good revelation of how any re-usable code should be commented. Any code which isn't trivial (meaning longer than ten lines) should be somewhat commented. Agreed, I don't follow this rule all the time myself either, but it IS a very good habit.

Multiple inheritance
There is a reason why many languages haven't brought support for multiple inheritance into them (actually can't really think of any other than C++ right now). 99.9% of times if you need to use multiple inheritance you've done the architectural design wrong. When using multiple inheritance you need to be very very careful. For example how should the language/compiler behave when there is a diamond shaped inheritance tree? In C++ multiple inheritance should be used only for interface classes without any functionality, in other languages there is usually a special Interface class type.

And for those who don't know what is a diamond shaped inheritance tree I added an attachment of a very dirty class diagram (made quickly in Inkscape, don't have a proper UML drawing software on this computer).

-----------------------------

There are so many things lacking in C++ code I see due to people using C way of doing things. Like usage of #define, printf() and so on. #define should never be used (with the exception of #ifndef #define #endif -"trick"), printf is lacking many things provided by cout/cerr etc. List could go on.

I read that post by Stuart when it was originally posted and was actually astounded. Virtually all of the things he mentioned in his post were wrong. For example the mention about not able to do a +4 operation for an object - has he ever heard about operator-keyword?

And about Modo renderer being faster than Lightwave and if it is due to them using C instead of C++: the answer is no. C++ code is just as fast as C if you don't use some of C++ bonus things like dynamic binding which needs virtual tables and those cause some overhead (tests have shown a performance loss from 2% to 5% in some extreme cases with a lot of function calls). And in my opinion a 2% performance loss is very much acceptable if one gets cleaner, more modular code with less bugs by using it.

ps. I'm still interested about that C++ wrapper but I've got way too much work to start playing around with it currently so I'll be delaying the application for the wrapper for a while :)

pps. Another rant. This is getting serious... :help:

Lightwolf
06-11-2007, 04:05 PM
Multiple inheritance
There is a reason why many languages haven't brought support for multiple inheritance into them (actually can't really think of any other than C++ right now). 99.9% of times if you need to use multiple inheritance you've done the architectural design wrong. When using multiple inheritance you need to be very very careful. For example how should the language/compiler behave when there is a diamond shaped inheritance tree? In C++ multiple inheritance should be used only for interface classes without any functionality, in other languages there is usually a special Interface class type.

We could argue this point for ages I suppose. I just find it to be very, very convenient indeed to have it in C++. An example would be a Node with an XPanel Interface that at the same time uses the ComRing (or is a ComRing Communicator in this case).



class myPlugin : public lwpp::Node, lwpp::XPanelInterface, lwpp::ComRingCommunicator
{
};

Sure, there are other ways to handle it, but I found multiple inheritance to be a good solution when needed.
Diamind shaped? Look up virtual base classes... They can be a problem if not handled properly, no doubt, and should be used rarely (I've had to use them once or twice).

The funny thing is, I've been hacking away in C++ for three years yet... and I'm not even close to having achieved the level that I could... which is good, ample space to improve and so far the language has only limited me in one case. (Exceptions are the big thing I need to give more attention too, I've covered just about everything else).


There are so many things lacking in C++ code I see due to people using C way of doing things. Like usage of #define, printf() and so on. #define should never be used (with the exception of #ifndef #define #endif -"trick"), printf is lacking many things provided by cout/cerr etc. List could go on.

I basically agree... but not with the samples you provide.
Try cross platform code without #defines, or try to localize cout code (something I'll probably have to do soon, and I'll go back to sprintfs() I think)...
It is good to have a choice, but you must use it wisely (not that I always do, mind you, I blunder just as much as anybody else).


I read that post by Stuart when it was originally posted and was actually astounded. Virtually all of the things he mentioned in his post were wrong. For example the mention about not able to do a +4 operation for an object - has he ever heard about operator-keyword?

He mentioned implicit types. You can't override operator+() for an int for example, since int is not a real object.


ps. I'm still interested about that C++ wrapper but I've got way too much work to start playing around with it currently so I'll be delaying the application for the wrapper for a while :)

I do agree on the other points. And please do join in the development whenever you like to.
Especially if you like discussing things (and follow that up with code :D )

Cheers,
Mike

dballesg
06-11-2007, 04:39 PM
An example would be a Node with an XPanel Interface that at the same time uses the ComRing (or is a ComRing Communicator in this case).



Ok, NOW that is scary :) I am influencing you so much Mike? ;) LOL

(BTW the plugin sample compiles but doesn't work, I think is due to something applying a Custom Object to a Camera!) :)

On the past I needed to teach a few simple programming languages. And something I ALWAYS insisted was COMMENT your code. A couple of lines of comments can save you of future headaches! :)

And as Matt pointed it would help others to understand your code.

Best regards,
David

Lightwolf
06-11-2007, 04:58 PM
Ok, NOW that is scary :) I am influencing you so much Mike? ;) LOL
Actually you are. ComRing is something I wanted to tackle anyhow, and now you do :)

Cheers,
Mike

jay3d
06-11-2007, 10:09 PM
Hi,

I found that comment in the D paper:



Retains investment in existing C code
Rather than trying to compile existing C code, which would require D to carry on with all the legacy decisions of C, instead D assumes existing C code will be compiled with a C compiler, and connects directly to it at the object code level. D supports all C types (more than C++ does!), common calling conventions (including printf's), and runtime library functions, so C code need never realize it is interfacing to D code.

There's no need to convert C code to D; new functionality can be written in D and linked in to the existing C object code. Indeed, some parts of the standard library - e.g. std.zlib, std.recls - are widely used C and C++ libraries that have been incorporated with no changes, only D declaration files were created for the libraries' C interfaces.


It would be useful at the start before building D wrappers around the SDK code, to make the programmer gets familiar with D first :)

hehe, sorry to annoy you guys everytime, but simply i cannot resist begining programming with that :D

maybe we can co-operate to make two language wrappers one for C++ and one for D in the future;

any ideas would be great though!

best regards!

Lightwolf
06-12-2007, 02:22 AM
It would be useful at the start before building D wrappers around the SDK code, to make the programmer gets familiar with D first :)

That wouldn't be a wrapper though, just an interface of D into the C SDK.

A wrapper would mean encapsulating all of the SDK into D classes.

Cheers,
Mike

fyffe
06-29-2007, 12:57 PM
I use C++ for all Happy Digital plugins. I also use a wrapper to do this. That way, I don't have to cut-and-paste any of the initialization code, etc. A simple shader plugin can be implemented in just a few lines of code, total.

You knew that already, LightWolf :)

The wrapper I wrote is completely lightweight, meaning it uses all original LightWave structures in memory, but interprets them as my wrapper classes. The wrapper never adds any extra copying or indirection that wasn't already in the SDK. There is absolutely no performance hit. And the shorter, cleaner code that I get from my C++ style makes things very easy to maintain for me.

However, NewTek seemed to do alright using C to build LightWave, so go ahead and use that if it suits you.

- Graham

Lightwolf
06-29-2007, 02:10 PM
You knew that already, LightWolf :)

I did :D

And one day... we'll merge our wrappers ... one wrapper to rule them all ;) (I'm just afraid that they might be designed too different...)

Cheers
Mike

Sensei
06-29-2007, 03:06 PM
And one day... we'll merge our wrappers ... one wrapper to rule them all ;) (I'm just afraid that they might be designed too different...)

I am still opting for maximum integration architecture f.e.:


class LWCCommandSequenceTest : public LWCCommandSequence
{
public:
LWCError Process( void )
{
Evaluate( "MAKE_BOX <0,0,0> <1,1,1>" );
return( errorNone );
}
};

LWCCommandSequenceTest pluginTest( "Test" );

Have no more ServerDesc[] table, and build it in real-time in plug-in activation function..

The all LW plugin classes put into corresponding to it LWC<name> class, and to have them as LW plug-in just sub-class it, intercepting the main essencial routines and do something in them..

Lightwolf
06-29-2007, 04:46 PM
I am still opting for maximum integration architecture f.e.:

That's basically how mine works without the fancy plugin-activation... I just didn't have time to design it to behave for all the cases that I have in mind.

No reaons to use a prefix though, C++ supports namespace.

Cheers,
Mike