You can change the Label's Modifiers property in the form designer from "private" to "public" or "internal". Then you can do fInstance.lblWhatever.Text.
Or you can expose the whole label via a property/accessor like so (this would go in your 'form' class):
public Label StatusLabel
{
get { return lblStatus; }
}
Or you can just expose the property of the label that you need like so:
public string StatusLabelText
{
get { return lblStatus.Text; }
set { lblStatus.Text = value; }
}
[ed] If that doesn't make sense let me know and I'll try to explain a little bit better.
You can change the Label's Modifiers property in the form designer from "private" to "public" or "internal". Then you can do fInstance.lblWhatever.Text.
Or you can expose the whole label via a property/accessor like so (this would go in your 'form' class):
public Label StatusLabel
{
get { return lblStatus; }
}
Or you can just expose the property of the label that you need like so:
public string StatusLabelText
{
get { return lblStatus.Text; }
set { lblStatus.Text = value; }
}
[ed] If that doesn't make sense let me know and I'll try to explain a little bit better.
Right, so once it's exposed, how can I change it. When I create a new object instance of the form, it's separate from the form that is already existing.
Example:
Program starts, the form from the form class is displayed. Say I have a button that calls a method from another class. In that class how would it access the currently displayed form. If I make a new form(), it's a new form thus not visible and not affecting the current form.
To show you what I mean:
public partial class Form1 : Form
{
public Label statuslbl
{
get { return label1; }
}
private void button1_Click(object sender, EventArgs e)
{
a test = new a();
test.labelChange();
}
}
public class a
{
public void labelChange()
{
Form1 form = new Form1();
form.statuslbl.Text = "Test";
}
}
Click button, nothing. Which makes sense because it's creating a new form that isn't displayed.
So how can I affect the form that is already displayed with out using back assward form control searches
When you pass that method the "this" keyword, it passes the current instance of the class that you're "in". So in this case, the 'form' class is passing itself to the DoWorkAndUpdateMyLabel method.
Then in your MyWorkClass you'd do something like:
public void DoWorkAndUpdateMyLabel(FrmMain MyForm)
{
MyForm.label.Text = "Doing work...";
[... do a bunch of tedious work ...]
MyForm.label.Text = "Done!";
}
[ed the millionth] This assumes there aren't any threading issues to worry about. :P
So this isn't exactly programming so much as modding, but I have a question:
In the Oblivion construction kit, you can apparently manipulate emotional displays by putting down like "Sad = 20" or something. Can you do that in GECK or Source SDK? Also, there's simple lip sync.
I'm being asked to help create something for a research project and I'd like to move on up from the ugly people of Oblivion.
Edit: Hmmmm. Source has what seems like a pretty simple face-muscle system. I'm sure I could just be like "sad=20 means A=10 B=15 C=4..." if I spent some time looking at it. And that way I'd be working on a system that people actually use.
So this isn't exactly programming so much as modding, but I have a question:
In the Oblivion construction kit, you can apparently manipulate emotional displays by putting down like "Sad = 20" or something. Can you do that in GECK or Source SDK? Also, there's simple lip sync.
I'm being asked to help create something for a research project and I'd like to move on up from the ugly people of Oblivion.
Edit: Hmmmm. Source has what seems like a pretty simple face-muscle system. I'm sure I could just be like "sad=20 means A=10 B=15 C=4..." if I spent some time looking at it. And that way I'd be working on a system that people actually use.
You rig the model so that the sliders reflect the appropriate "muscles" and then in FacePoser you can adjust those sliders and save the results as expressions.
Then you can use those in a scene, crossfading them with ramps, so you can go from expression A to expression B and such. It's not quite the same as blending some core expressions but it is much more flexible, especially with flex animations (where you have a timeline for the individual sliders, not just a "destination" expression).
Since the muscle sets and sliders are universal, your animations and expressions can be applied to any model after you have it rigged.
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
So this isn't exactly programming so much as modding, but I have a question:
In the Oblivion construction kit, you can apparently manipulate emotional displays by putting down like "Sad = 20" or something. Can you do that in GECK or Source SDK? Also, there's simple lip sync.
I'm being asked to help create something for a research project and I'd like to move on up from the ugly people of Oblivion.
Edit: Hmmmm. Source has what seems like a pretty simple face-muscle system. I'm sure I could just be like "sad=20 means A=10 B=15 C=4..." if I spent some time looking at it. And that way I'd be working on a system that people actually use.
You rig the model so that the sliders reflect the appropriate "muscles" and then in FacePoser you can adjust those sliders and save the results as expressions.
Then you can use those in a scene, crossfading them with ramps, so you can go from expression A to expression B and such. It's not quite the same as blending some core expressions but it is much more flexible, especially with flex animations (where you have a timeline for the individual sliders, not just a "destination" expression).
Since the muscle sets and sliders are universal, your animations and expressions can be applied to any model after you have it rigged.
Oooooh
I'll have to see what he's got rigged up to start with, but that sounds great. Honestly, I think Team Fortress 2 characters would work better for expressing emotion than the monstrosities that populate Oblivion.
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
It is all done compile time if given a constant and simply a single inline multiplication given a variable. Since it's radians for a parameter, it's less likely that we're talking constants here so it's effectively the same as an inline function but with Macro Fun.
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
It is all done compile time if given a constant and simply a single inline multiplication given a variable. Since it's radians for a parameter, it's less likely that we're talking constants here so it's effectively the same as an inline function but with Macro Fun.
It's also unsafe as identifiers beginning with a double underscore are reserved for the implementation (in C++ at least). As are identifiers beginning with an underscore and a capital letter.
When you pass that method the "this" keyword, it passes the current instance of the class that you're "in". So in this case, the 'form' class is passing itself to the DoWorkAndUpdateMyLabel method.
Then in your MyWorkClass you'd do something like:
public void DoWorkAndUpdateMyLabel(FrmMain MyForm)
{
MyForm.label.Text = "Doing work...";
[... do a bunch of tedious work ...]
MyForm.label.Text = "Done!";
}
[ed the millionth] This assumes there aren't any threading issues to worry about. :P
There are threading issues. If you execute DoWorkAndUpdateMyLabel from the button click then it will execute from the GUI thread. This means you won't really see the label change as the GUI will essentially lock up.
What you can do is...
Action doWork = new Action(() => {
// Do stuff here
});
lblStatus.Text = "Working...";
doWork.BeginInvoke(new delegate((IAsyncResult result) => {
Invoke(new MethodInvoker(() => {
lblStatus.Text = "Done";
}));
}), null);
The begin invoke creates a new thread for the work and then calls the delegate after completion. Since its in a different thread you need to invoke it or the GUI thread cant actually update.
Unless you want to do something like log the calls that you need a custom dll for (there are a lot of them, writing the wrapper dll is actually a matter of autogenerating code, I did it once in C++)
I guess I don't see that as a threading issue. That's an issue where you're using the current thread yourself, and the GUI might not get enough time to go through the message loop to update itself often enough. That's a limited resources issue. A threading issue would have resulted in the dreaded "cross-thread operation is not valid" message. DUN. DUN. DUNNNNNNNNN.
I just tried it out on my machine, calculating MD5 sums for about 300 files, updating a ProgressBar and Label after each file (just in a loop: a foreach on a Directory.GetFiles) and it works just fine. The bar redrew as it should have, and the label did the same.
Plus, we're talking a simple example here. I'm not sure that we're ready to get into threading and why you can't update the GUI from another thread. I'm going to have a look at the Action class though. I've not used it yet. (Still working with 2.0 for work projects, I only get to use >2 for personal stuff ATM)
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
It is all done compile time if given a constant and simply a single inline multiplication given a variable. Since it's radians for a parameter, it's less likely that we're talking constants here so it's effectively the same as an inline function but with Macro Fun.
It's also unsafe as identifiers beginning with a double underscore are reserved for the implementation (in C++ at least). As are identifiers beginning with an underscore and a capital letter.
it is also horseshit and that man should be slapped in the face.
The begin invoke creates a new thread for the work and then calls the delegate after completion. Since its in a different thread you need to invoke it or the GUI thread cant actually update.
I went the constructor(?) route to reference the form.
It's doing a database query which is rather slow sometimes, so I just put it on a background worker and any GUI updates are delegated as needed.
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
It is all done compile time if given a constant and simply a single inline multiplication given a variable. Since it's radians for a parameter, it's less likely that we're talking constants here so it's effectively the same as an inline function but with Macro Fun.
It's also unsafe as identifiers beginning with a double underscore are reserved for the implementation (in C++ at least). As are identifiers beginning with an underscore and a capital letter.
it is also horseshit and that man should be slapped in the face.
Zek and I. We are on the same wavelength.
Jasconius on
0
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
It is all done compile time if given a constant and simply a single inline multiplication given a variable. Since it's radians for a parameter, it's less likely that we're talking constants here so it's effectively the same as an inline function but with Macro Fun.
It's also unsafe as identifiers beginning with a double underscore are reserved for the implementation (in C++ at least). As are identifiers beginning with an underscore and a capital letter.
it is also horseshit and that man should be slapped in the face.
Zek and I. We are on the same wavelength.
How old is the guy who wrote this? I kinda expect that sort of junk from the crusty old C programmers.
If he's younger than 50, he definitely deserves a slap.
Macros also don't do any type checking. Back in the hayday macro functions where basically inline functions. Which can offer some speed enhancements for simple shit like that. So, that said, unless he's programming for some sort of palm device with like... 3 kb of memory and no processor power short of a moldy piece of toast, he needs to get slapped in the fucking face.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
There's nothing wrong with simple macro functions like that. There are no side effects, the parameter is evaluated only once, it's properly parenthesized (although I would have written the constant part as * (180.0 / M_PI)) and the function is sensibly defined across all numeric types, including both signed and unsigned integers (and anything else that converts to double). Indeed anything that defines operator * (float) or operator * (double) will work with it
The fact that __ prefixes are reserved is actually quite irrelevant as the compiler never sees that code.
edit: I think the only real complaint that you could level against it other than EWW MACRO would be that integer numbers of radians dont make any sense, so you can't use an integer fixed-point representation easily (of course doing that requires you to use a whole separate math library for everything other than + and - anyway). The inverse function (degree to rad) would be fine since integer numbers of degrees works.
An inline function for floats would be more than sufficient, plus, less confusing (and ensures data type integrity). Less is more when dealing with macros in the C languages. Granted you can get radians<->degrees for doubles/ints/unsigned data, etc, but, really, is there a point? How often do you deal with angles > maybe a couple thousand, or, completely whole number angles?
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
So I want to make a wrapper for opengl for C#. What would be the best method of finding all the dll's and header files for it?
It would be opengl 1.0 at first.
I'm wondering why you want to do this, educational purposes? Cause I think I read somewhere writing wrappers is quite a big and boring undertaking if you want it to be any good, and there are already opengl wrappers for C# out there.
Alright, lets teach the Guy Who Doesn't Know C why in the world people are so into macros, and why people keep trying to turn a simple function into a macro. Why are people doing this? I don't get it. Are they global so they're easier to get to? Are they less work to define, like there's the definition and implementation all in 1 place/line rather than a definition in a *.h and the implementation in the *.c? I'm lost. :P
Alright, lets teach the Guy Who Doesn't Know C why in the world people are so into macros, and why people keep trying to turn a simple function into a macro. Why are people doing this? I don't get it. Are they global so they're easier to get to? Are they less work to define, like there's the definition and implementation all in 1 place/line rather than a definition in a *.h and the implementation in the *.c? I'm lost. :P
Macros are not global (unless you make them so), more difficult to define than an inline procedure (due to \ continuations and parameter evaluation), and nested macros can be very difficult to read. I don't know Objective-C, but looking at his question, I think he's trying to call CGPointMake() with custom offsets, without any function call overhead (a reasonable goal).
The primary reasons to use them are 1) performance 2) metaprogramming.
1) Macros are always inlined, which can give the programmer more control over how the assembly is generated than depending on a compiler's inline analysis -- using a macro to perform (for example) array permutation in a digest algo can be much faster than a static procedure. Additionally, if a parameter can be determined at compile-time, the entire macro might be calculated down to one constant. This is why you'll see something like DEGREES_TO_RADIANS() defined as macro, because if it's given a numeric literal for a parameter the compiler will pre-calculate it.
2) Macros can generate code, including procedures, structures, etc. In C, which has very little runtime introspection, this can be used for nice features which are annoying or impossible to represent with static code.
3) it also pisses off everyone you work with except for 3 people from the 70s who care about that stuff, or that creepy guy who talks about how his palm pilot is amazing because he can develop in C, man.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Anyway, for those who hate macros, I pose a question to you: how would you do this without macros and maintaining both the execution speed and the simplicity?
The begin invoke creates a new thread for the work and then calls the delegate after completion. Since its in a different thread you need to invoke it or the GUI thread cant actually update.
I went the constructor(?) route to reference the form.
It's doing a database query which is rather slow sometimes, so I just put it on a background worker and any GUI updates are delegated as needed.
If a background worker does the query then the GUI wont lock up. I believe if you update the GUI from the background worker you will need to use the Invoke method. If the GUI is updated as needed then there shouldn't be an issue however I have gotten into the habit of making methods to update the GUI and forcing invoke on them. Its relatively little overhead and gives me more flexibility with using threads.
So I want to make a wrapper for opengl for C#. What would be the best method of finding all the dll's and header files for it?
It would be opengl 1.0 at first.
I'm wondering why you want to do this, educational purposes? Cause I think I read somewhere writing wrappers is quite a big and boring undertaking if you want it to be any good, and there are already opengl wrappers for C# out there.
All the C# wrappers thus far are incomplete, no longer updated and I think its a good way to learn opengl. I think starting with 1.0 (I believe 1.0 doesnt support hardware rendering) would at least give me a good place to start.
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
Hey cool, it's like a lambda substitution but in C!
In truth modern compilers make this kind of trick unnecessary. It's the sort of thing that used to be useful, should be obvious to anyone who truly understands the language . . . but sadly makes people want to punch you in the face if you try it.
(For the record, if I saw this in someone else's code I'd be fine with it, but I NEVER do stuff like this. CPU is cheap -- better that the code be understood than be fast-but-obscure.)
I think you can file that trick along with people who use ? : trinary statements instead of if-thens. "I wish this was ML or OCAML but I'm stuck with C, so I'm going to make life difficult for everyone who never learned a functional language."
mspencer on
MEMBER OF THE PARANOIA GM GUILD
XBL Michael Spencer || Wii 6007 6812 1605 7315 || PSN MichaelSpencerJr || Steam Michael_Spencer || Ham NOØK QRZ || My last known GPS coordinates: FindU or APRS.fi (Car antenna feed line busted -- no ham radio for me X__X )
So I want to make a wrapper for opengl for C#. What would be the best method of finding all the dll's and header files for it?
It would be opengl 1.0 at first.
I'm wondering why you want to do this, educational purposes? Cause I think I read somewhere writing wrappers is quite a big and boring undertaking if you want it to be any good, and there are already opengl wrappers for C# out there.
All the C# wrappers thus far are incomplete, no longer updated and I think its a good way to learn opengl. I think starting with 1.0 (I believe 1.0 doesnt support hardware rendering) would at least give me a good place to start.
It's not a good way to learn OpenGL, it's a good way to learn how to marshal data between C and C#. Which is almost undoubtedly a very, very boring process. Anytime you wrap one language's API in another, it's almost all boilerplate, with maybe a little adaptation to the new language's paradigms vs. C ones (polymorphism replacing different function names for different types, high level objects abstracting out VBOs and texures, etc).
Additionally, if you learn OpenGL 1.0, that will do you almost no good with OpenGL 3.x. 1.0 has a very limited fixed function pipeline. More features were added in versions up until 3 to reflect changes in the hardware over time, but by now even those features are mostly deprecated. What you really want to do is learn the still-relevant parts of the fixed function toolkit, and soak up as much knowledge as you can regarding the new, programmable shader model which is the way to do things in the present and the foreseeable future.
Get the red book (OpenGL Programming Guide) and the orange book (OpenGL Shading Language), for anything 3.x or later, if you really want to learn OpenGL.
I think you can file that trick along with people who use ? : trinary statements instead of if-thens. "I wish this was ML or OCAML but I'm stuck with C, so I'm going to make life difficult for everyone who never learned a functional language."
Oh god tell me about it. I'm working with a bunch of java programmers who love their damn ternary expressions, and consider putting the body of an if statement on a new line to be a waste of a good line.
But, you can see how you can write yourself into a corner where you either have to precompute some miscellaneous value that you cannot for the life of you think of a good name for, or just do it inline and be done with it. Tends to happen most in string concatenations, particularly when building HTML tags. Or in fucking java web programming you have to check for null constantly.
Posts
You can change the Label's Modifiers property in the form designer from "private" to "public" or "internal". Then you can do fInstance.lblWhatever.Text.
Or you can expose the whole label via a property/accessor like so (this would go in your 'form' class):
public Label StatusLabel { get { return lblStatus; } }Or you can just expose the property of the label that you need like so:
public string StatusLabelText { get { return lblStatus.Text; } set { lblStatus.Text = value; } }[ed] If that doesn't make sense let me know and I'll try to explain a little bit better.
Right, so once it's exposed, how can I change it. When I create a new object instance of the form, it's separate from the form that is already existing.
Example:
Program starts, the form from the form class is displayed. Say I have a button that calls a method from another class. In that class how would it access the currently displayed form. If I make a new form(), it's a new form thus not visible and not affecting the current form.
To show you what I mean:
public partial class Form1 : Form { public Label statuslbl { get { return label1; } } private void button1_Click(object sender, EventArgs e) { a test = new a(); test.labelChange(); } } public class a { public void labelChange() { Form1 form = new Form1(); form.statuslbl.Text = "Test"; } }Click button, nothing. Which makes sense because it's creating a new form that isn't displayed.
So how can I affect the form that is already displayed with out using back assward form control searches
Your 'form' class's button handler:
private void btDoStuff_Click(object sender, EventArgs e) { MyWorkClass.DoWorkAndUpdateMyLabel(this); }When you pass that method the "this" keyword, it passes the current instance of the class that you're "in". So in this case, the 'form' class is passing itself to the DoWorkAndUpdateMyLabel method.
Then in your MyWorkClass you'd do something like:
public void DoWorkAndUpdateMyLabel(FrmMain MyForm) { MyForm.label.Text = "Doing work..."; [... do a bunch of tedious work ...] MyForm.label.Text = "Done!"; }[ed the millionth] This assumes there aren't any threading issues to worry about. :P
This will give me a lot to work with, and should be a good help!
Edit for your edit:
Yeah, I'm messing with thread delegation, seems that you can call invoke like normal on them.
More editing: Also that second way is nice and even easier! But the one before was enlightening too!
In the Oblivion construction kit, you can apparently manipulate emotional displays by putting down like "Sad = 20" or something. Can you do that in GECK or Source SDK? Also, there's simple lip sync.
I'm being asked to help create something for a research project and I'd like to move on up from the ugly people of Oblivion.
Edit: Hmmmm. Source has what seems like a pretty simple face-muscle system. I'm sure I could just be like "sad=20 means A=10 B=15 C=4..." if I spent some time looking at it. And that way I'd be working on a system that people actually use.
You rig the model so that the sliders reflect the appropriate "muscles" and then in FacePoser you can adjust those sliders and save the results as expressions.
Then you can use those in a scene, crossfading them with ramps, so you can go from expression A to expression B and such. It's not quite the same as blending some core expressions but it is much more flexible, especially with flex animations (where you have a timeline for the individual sliders, not just a "destination" expression).
Since the muscle sets and sliders are universal, your animations and expressions can be applied to any model after you have it rigged.
He's using #define to create... basically a function... but what is actually the point of this? How is this different from just making a function that does exactly as it prescribes?
I could understand if you have a #define for M_PI * 180, since that would save you the FLOP... buuuut.... how does this get optimized when there's an argument?
Oooooh
I'll have to see what he's got rigged up to start with, but that sounds great. Honestly, I think Team Fortress 2 characters would work better for expressing emotion than the monstrosities that populate Oblivion.
It is all done compile time if given a constant and simply a single inline multiplication given a variable. Since it's radians for a parameter, it's less likely that we're talking constants here so it's effectively the same as an inline function but with Macro Fun.
It would be opengl 1.0 at first.
There are threading issues. If you execute DoWorkAndUpdateMyLabel from the button click then it will execute from the GUI thread. This means you won't really see the label change as the GUI will essentially lock up.
What you can do is...
Action doWork = new Action(() => { // Do stuff here }); lblStatus.Text = "Working..."; doWork.BeginInvoke(new delegate((IAsyncResult result) => { Invoke(new MethodInvoker(() => { lblStatus.Text = "Done"; })); }), null);The begin invoke creates a new thread for the work and then calls the delegate after completion. Since its in a different thread you need to invoke it or the GUI thread cant actually update.
http://www.opengl.org/resources/bindings/
Unless you want to do something like log the calls that you need a custom dll for (there are a lot of them, writing the wrapper dll is actually a matter of autogenerating code, I did it once in C++)
I just tried it out on my machine, calculating MD5 sums for about 300 files, updating a ProgressBar and Label after each file (just in a loop: a foreach on a Directory.GetFiles) and it works just fine. The bar redrew as it should have, and the label did the same.
Plus, we're talking a simple example here. I'm not sure that we're ready to get into threading and why you can't update the GUI from another thread. I'm going to have a look at the Action class though. I've not used it yet. (Still working with 2.0 for work projects, I only get to use >2 for personal stuff ATM)
it is also horseshit and that man should be slapped in the face.
I went the constructor(?) route to reference the form.
It's doing a database query which is rather slow sometimes, so I just put it on a background worker and any GUI updates are delegated as needed.
Zek and I. We are on the same wavelength.
How old is the guy who wrote this? I kinda expect that sort of junk from the crusty old C programmers.
If he's younger than 50, he definitely deserves a slap.
But, in context, that was written for something much more powerful than a Motorola Razr.
The fact that __ prefixes are reserved is actually quite irrelevant as the compiler never sees that code.
edit: I think the only real complaint that you could level against it other than EWW MACRO would be that integer numbers of radians dont make any sense, so you can't use an integer fixed-point representation easily (of course doing that requires you to use a whole separate math library for everything other than + and - anyway). The inverse function (degree to rad) would be fine since integer numbers of degrees works.
An inline function for floats would be more than sufficient, plus, less confusing (and ensures data type integrity). Less is more when dealing with macros in the C languages. Granted you can get radians<->degrees for doubles/ints/unsigned data, etc, but, really, is there a point? How often do you deal with angles > maybe a couple thousand, or, completely whole number angles?
I'm wondering why you want to do this, educational purposes? Cause I think I read somewhere writing wrappers is quite a big and boring undertaking if you want it to be any good, and there are already opengl wrappers for C# out there.
http://stackoverflow.com/questions/3257767/writing-a-macro-for-this-objective-c
I have read much worse, though. The interpreter for False was itself a good humored joke on "Good C style". Spoiler if you dare.
/* Introducing: Portable False!!!! PortableFalse is different from AmigaFalse in: - its Portable!!! :-) - full stack checking - strongly typed (no joke, really!) - debug-modi - real and meaningfull errormessages - ` inline assembly not supported - : and ; not supported for other than variable access. - "beta" (flush) and "zero-slash" (pick) from the amiga charset are now 'B' and 'O' resp. - 'D' toggles stack-watch mode on and off. format: [ bottom_of_stack , ... , top_of_stack | next_symbol ] - "-q" on command line is quiet mode: no title printing. (usefull for "filter"-type programs: 1> False -q filter.f <bla >burp) this is v1.2, changes from v1.1 include minor fixes for Ultrix and Irix. (the stunning original formatting hast been left intact now). Also, remaing commandline arguments are parsed as integers and put into variables b-z (a = argc). this source has been writtin in good C style: - no modularity whatsoever (only main()) - only global variables - lots of ugly macros (replacing functions) - great source formatting and indentation still compiles on a great number of ansi-C compilers on Amiga/SunOs/ Linux/Ultrix/Irix etc. if you have trouble porting it to your machine, your compiler sucks. */ #define MZ 10000 #define MS 1000 #include <stdio.h> #define NIL 0 #define NUM 0 #define FUNC 1 #define VADR 2 #define UNDEF 3 #define l(x) ;break;case x: #define x(num) {ernum=num;goto er;} #define push(v,a) {if(S-2<sbeg)x(4)else{*--S=(v);*--S=(X)a;};} #define pop(v,a) {if(S+2>se)x(5)else\ {if((ex=(int)a)!=(ge=(int)*S++))x(6);v= *S++;};} #define pa(v,av) {if(S+2>se)x(5)else{av= *S++;v= *S++;};} #define ru(v) {if(rp-1<rbeg)x(13)else{*--rp=(v);};} #define ro(v) {if(rp+1>rend)x(14)else{v= *rp++;};} #define CA(c) {ru(p);p=c;} #define pu(x) push(x,NUM) #define po(x) pop(x,NUM) #define op(o) {po(b)po(d);pu((X)((int)d o (int)b));} #define cm(o,tt) {pa(b,((X)tt))pop(d,(X)tt);pu((X)(-(int)((int)d o (int)b)));} #define un(o) {po(b)pu((X)(o (int)b));} #define ne (p<ent) #define W while #define ec {W((*p!='}')&&ne)p++;p++;if(!ne)x(10);} #define P printf typedef char* X; typedef char** XP; X ST[MS],RST[MS],var[52],b,d,e,f,t1,t2,t3; XP sbeg=ST+12,se=ST+MS-12,S,ts,rbeg=RST+12,rend=RST+MS-12,rp,vp; int ernum=0,t,tt,db=0,ex,ge,qq,ac=1,ic=0,it; FILE* fh; char *fn=0,src[MZ+5],a,c=0,*s,*ent,*beg,*p=0, *erstr[]={"no args","could not open source file","source too large", "data stack overflow","data stack underflow","type conflict", "stack not empty at exit of program","unknown symbol", "portable inline assembly not available","unbalanced '{'", "unbalanced '\"'","unbalanced '['","return stack overflow", "return stack underflow"}; char*types[]={"Integer","Functional","Variabele","Uninitialised"}; int main(int narg,char*args[]) { S=se;rp=rend;t=1;for(vp=var;vp<(var+52);){*vp++=(X)UNDEF;}; while(ac<narg) { if(args[ac][0]=='-'&&args[ac][1]=='q'){t=2;} else if(!fn){fn=args[ac];} else {it=0;sscanf(args[ac],"%d",&it);var[(++ic)*2+1]=(X)NUM;var[ic*2]=(X)it;}; ac++; }; var[1]=(X)NUM;var[0]=(X)ic; if(t==1)P("Portable False Interpreter/Debugger v0.1 (c) 1993 $#%%!\n"); if(!fn)x(1);if((fh=fopen(fn,"r"))==NIL)x(2);s=src; *s++='\n'; W(a=fgetc(fh),!feof(fh))if((src+MZ)<=s){fclose(fh);x(3)}else{*s++=a;}; *s++='\n';fclose(fh);ent=s-1;beg=src+1;p=beg; W(ne) { c= *p++;if(c>='0'&&c<='9'){int num;sscanf(p-1,"%d",&num); W((*p>='0')&&(*p<='9'))p++;push((X)num,NUM);} else if(c>='a'&&c<='z'){push((X)&var[(c-'a')*2],VADR);} else switch(c) { case' ':case '\n':case'\t': l('+')op(+) l('-')op(-) l('*')op(*) l('/')op(/) l('&')op(&) l('|')op(|) l('_')un(-) l('~')un(~) l('=')cm(==,tt) l('>')cm(>,tt) l('%')pa(b,e) l('$')pa(b,e)push(b,e)push(b,e) l('\\')pa(b,e)pa(d,f)push(b,e)push(d,f) l('@')pa(b,t1)pa(d,t2)pa(e,t3)push(d,t2)push(b,t1)push(e,t3) l('O')po(b)if(S+((t=(int)b*2)+2)>se)x(5)b= *(S+t);d= *(S+t+1);push(d,b) l(':')pop(b,VADR)pa(d,e)*((XP)b)=d;*(((XP)b)+1)=e; l(';')pop(b,VADR)push(*((XP)b),*(((XP)b)+1)); l('.')po(b)P("%d",(int)b); l(',')po(b)P("%c",(char)b); l('^')pu((X)fgetc(stdin)); l('B')fflush(stdout);fflush(stdin); l('\"')W((*p!='\"')&&ne){fputc(*p,stdout);p++;};p++;if(!ne)x(11); l('{')ec; l('\'')pu((X)*p++); l('`')x(9); l('D')db=!db; l('[')push((X)p,FUNC)t=1;W(t>0&&ne){a= *p++;if(a=='['){t++;}else if(a==']'){t--;}else if(a=='{'){ec}else if(a=='\"'){W((*p!='\"') &&ne)p++;p++;if(!ne)x(11);};};if(!ne)x(12); l(']')ro(e)if((int)e==0){ro(p)po(b)if((int)b) { ro(d)ru(d)CA(d) ru((X)1);} else { ro(d)ro(d); };}else if((int)e==1){ro(p)ro(b) ro(d)ru(d)ru(b)CA(d)ru((X)0);}else{p=e;}; l('!')pop(b,FUNC)CA(b); l('?')pop(b,FUNC)po(d)if((int)d){CA(b);}; l('#')pop(b,FUNC)pop(d,FUNC)ru(d)ru(b);CA(d)ru((X)0); break;default:x(8); }; if(db){c= *p; if(c!=' '&&c!='\n'&&c!='\t'&&c!='{'&&c!='\"'){ ts=S+20;if(ts>se)ts=se;P("["); W(ts>S){t=(int)*(ts-2);if(t==FUNC){P("<func>");}else if(t==VADR){ P("<var>");}else P("%d",(int)*(ts-1));ts-=2;if(ts>S)P(",");}; P("|'%c']\n",*p); }; }; }; c=0;p=0;if(S!=se)x(7); er:if(ernum) { P("\nERROR: %s!\n",erstr[ernum-1]); if(c)P("WORD: '%c'\n",c); if(ernum==6)P("INFO: Expecting %s type, while reading %s type.\n", types[ex],types[ge]); if(p){ ent=p;beg=p; W(*(beg-1)!='\n'){beg--;}; W(*ent!='\n'){ent++;}; t=ent-beg;*ent=0; if(t>0) { P("LINE: %s\n",beg); qq=p-beg+3; P("AT:");for(t=0;t<qq;t++){putchar(' ');};P("^\n"); }; }; }; return 0; };Macros are not global (unless you make them so), more difficult to define than an inline procedure (due to \ continuations and parameter evaluation), and nested macros can be very difficult to read. I don't know Objective-C, but looking at his question, I think he's trying to call CGPointMake() with custom offsets, without any function call overhead (a reasonable goal).
The primary reasons to use them are 1) performance 2) metaprogramming.
1) Macros are always inlined, which can give the programmer more control over how the assembly is generated than depending on a compiler's inline analysis -- using a macro to perform (for example) array permutation in a digest algo can be much faster than a static procedure. Additionally, if a parameter can be determined at compile-time, the entire macro might be calculated down to one constant. This is why you'll see something like DEGREES_TO_RADIANS() defined as macro, because if it's given a numeric literal for a parameter the compiler will pre-calculate it.
2) Macros can generate code, including procedures, structures, etc. In C, which has very little runtime introspection, this can be used for nice features which are annoying or impossible to represent with static code.
Anyway, for those who hate macros, I pose a question to you: how would you do this without macros and maintaining both the execution speed and the simplicity?
http://codepad.org/40saVCma
Class hierarchy for the test
p1 p2 \ / p4 p3 \ / foo | barRun when optimized I get
dynamic_cast<T*>: 1.270371
T::TryCast: 0.036376
A rather dramatic difference
If a background worker does the query then the GUI wont lock up. I believe if you update the GUI from the background worker you will need to use the Invoke method. If the GUI is updated as needed then there shouldn't be an issue however I have gotten into the habit of making methods to update the GUI and forcing invoke on them. Its relatively little overhead and gives me more flexibility with using threads.
All the C# wrappers thus far are incomplete, no longer updated and I think its a good way to learn opengl. I think starting with 1.0 (I believe 1.0 doesnt support hardware rendering) would at least give me a good place to start.
In truth modern compilers make this kind of trick unnecessary. It's the sort of thing that used to be useful, should be obvious to anyone who truly understands the language . . . but sadly makes people want to punch you in the face if you try it.
(For the record, if I saw this in someone else's code I'd be fine with it, but I NEVER do stuff like this. CPU is cheap -- better that the code be understood than be fast-but-obscure.)
I think you can file that trick along with people who use ? : trinary statements instead of if-thens. "I wish this was ML or OCAML but I'm stuck with C, so I'm going to make life difficult for everyone who never learned a functional language."
XBL Michael Spencer || Wii 6007 6812 1605 7315 || PSN MichaelSpencerJr || Steam Michael_Spencer || Ham NOØK
QRZ || My last known GPS coordinates: FindU or APRS.fi (Car antenna feed line busted -- no ham radio for me X__X )
Anyway, you're looking for GL.h. It's found in Microsoft's Platform SDK at least.
You will need to link against opengl32.dll which is already in your system32 dir.
All versions of GL will support HW rendering, they just add features (and recent versions handle 1.x drawing methods inefficiently)
It's not a good way to learn OpenGL, it's a good way to learn how to marshal data between C and C#. Which is almost undoubtedly a very, very boring process. Anytime you wrap one language's API in another, it's almost all boilerplate, with maybe a little adaptation to the new language's paradigms vs. C ones (polymorphism replacing different function names for different types, high level objects abstracting out VBOs and texures, etc).
Additionally, if you learn OpenGL 1.0, that will do you almost no good with OpenGL 3.x. 1.0 has a very limited fixed function pipeline. More features were added in versions up until 3 to reflect changes in the hardware over time, but by now even those features are mostly deprecated. What you really want to do is learn the still-relevant parts of the fixed function toolkit, and soak up as much knowledge as you can regarding the new, programmable shader model which is the way to do things in the present and the foreseeable future.
Get the red book (OpenGL Programming Guide) and the orange book (OpenGL Shading Language), for anything 3.x or later, if you really want to learn OpenGL.
Oh god tell me about it. I'm working with a bunch of java programmers who love their damn ternary expressions, and consider putting the body of an if statement on a new line to be a waste of a good line.
But, you can see how you can write yourself into a corner where you either have to precompute some miscellaneous value that you cannot for the life of you think of a good name for, or just do it inline and be done with it. Tends to happen most in string concatenations, particularly when building HTML tags. Or in fucking java web programming you have to check for null constantly.
ternary operators are awesome.
as long as you don't make your rows too long I don't see the problem.