Structures From C
BlitzMax Forums/OpenGL Module/Structures From C
| ||
| [delete this thread!] It's off topic now XD |
| ||
| What exactly are you asking? That you want a language just like C, that takes/understands C structures, works just like C, but isn't C? Blitz is BASIC, it's not C/C++ - what were you expecting? I guess I didn't understand. I'm mildy annoyed that everything works this way, I had everything up and running(including more!) just fine in C, now it's like I'm starting all over If everything was running fine in C, how come you changed? There must be a reason and it must have been good enough or you wouldn't have changed. Aaron |
| ||
| Nah, I don't want C, That's why I bought Blitzmax, I just want implementing modules from C libraries to be easy as including "mylibrary.h" that comes with a C Library. :) I havn't left C, however I bought Blitzmax to see how it will hold up. (Possibly Illogical idea! XD) |
| ||
| To come on these forums and make a ridiculous comment like: "It seems as though Blitzmax is trying to be the little brother who just wants to be C++. " Shows how idiotic you really are and just how little you know about programming languages and their historical evolution. I have yet to hear anyone accuse C++ (or any other OOP based language) of “trying to be the little brother who just wants to be SmallTalk”. SmallTalk was the *FIRST* OOP based programming language released more than 30 years ago, and C++ was inspired by it and HEAVILY borrowed many of SmallTalk’s OOP programming techniques. So because BM uses structs and classes it is somehow trying to be C or C++ ??? Where’s the common sense in that? ! As I see it, BM is an advanced evolution of BASIC with many "C/C++-like" features which were included to empower YOU (the BASIC programmer) not to somehow emulate C++. My god, we’re talking about memory structures here, a COMMON form of data management in many different languages. It’s called evolution my friend, not emulation. Just remember, English would not be the sophisticated expressive language it is today if it didn’t EVOLVE and borrow and adapt many words from other foreign languages such as French. (and I’m crtain no Englishman could be accused of ever wanting to be FRENCH!!!:) I don't think anyone at BR has, as you put it, "suckered you", but you are without doubt a 100% genuine sucker Zenith. (no offence) |
| ||
| You read my post wrong, sorry if there were any confusions. I didn't say it was trying to be C/C++ because of structs and classes. The problem is, when implementing modules based on C/C++ libraries, you lose the whole point of NOT using C/C++ because you end up having to re-write the headers into bmx code. Oh and I was offended, because you either didn't clearly read what I had written, or you just want to throw nasties at me. :P |
| ||
| The big advantage of BlitzMax having clean, simple hooks to graphics, sound, I/O, and other useful system-level things like timers. And even more so, these are fully CROSS-PLATFORM hooks. On one particular OS, none of this is difficult. It can be finicky, yes. Sometimes you have to hunt down weird bits of knowledge (especially for things like switching to fullscreen mode), but it's all doable. But you will still only have covered one platform, not three. Maintaining cross-platform code to do all of these things is messy. A secondary advantage is that Blitz is generally easier to mess about with than C and C++. Maybe not hugely so, but the advantage is still there. This comes from a lot of little things that have a cumulative effect. For example, there aren't endless compiler switches to mess with. You aren't as tempted to unnecessarily compress code to the point of being unreadable. You don't have to puzzle over obscure declarations as much. Now, if your goal is to work directly with existing C code and structures, then I'm not sure what you'll gain with Blitz. You might be better off using a game library for C++. Occasionally converting C structures over to Blitz isn't so bad, however. |
| ||
| If you want to use _authentic_ C/C++ structs, you should use your C compiler. I would have thought that was logical. I don't remeber any claims that said BM uses identical C structs. "C-like", sure, but not identical |
| ||
| I came only to ask questions, I don't mean to flame or hurt anyones feelings. I'm sorry to have asked for my money back but it is my right, -- however I shouldn't have written it here. I didn't see it like I should have, as its like a slap in the face. I understand what you mean junkster, and yes maybe I shouldn't have bought it -- it was my choice after all. I have done all that you have said, and more. I came to the conclusion that perhaps Blitzmax would rid me of all this. (Which most of which it has and will) However, I'd like to use the C libraries I had used in C itself -- but implementing them is more work than actually getting down to the fun that Blitzmax is. I have been a Blitz customer since it first came out for PC, waaaay back whenever. :) (And was even a Blitz3d beta tester! woo!) Kraft - you are also correct, but it would definitely take alot of the extra work out of it! Though, my questions won't really be answered until I see official BR arguements. |
| ||
| It's the age old problem of ones will, taking a circle, eventing a wheel, and someone taking that wheel and making a better wheel, or a diferent type of wheel, mean while serverial generations later, someone events a diferent type of connection to the wheel that is like the other but has a different number of nut holes, now joe blogs sitting on the side walk with his flat tire goes for his spare, and discovers much to his horror that in order to get his new spare wheel on the car he must drill new holes for it to fit properly, now then while driving down the road the wheel flys off and kills some passer by. How does this relate? C/C++ .h & .lib/.obj files should be importable as default without modification to either source or header, or you'll end up crashing some app down the road because you forgot to assign the proper veriable datatype to you converted type for whatever your C/C++ .h .lib/.obj might happen to do, it is better therefore to use the orginal code written by the orginal author, then if nothing else you can point the finger at whomever wrote the orginal first. now then, there are serverial problems (correct me if I'm wrong), that I noticed that would be a bit of a sticky problem, when converting structs. there is no unsigned datatypes ( c/c++ use thes prolifically ), I don't think I noticed any Union type either, although I've only skimmed that part of the documentation. |
| ||
| kraft, there are terms of use associated with this site, please refrain from personal attacks (ie calling the poster idiotic rather than his post). Zenith, I know where you are coming from but after implementing several modules myself I have changed my view on the shortcomings of the struct/type barrier which is: 1. BlitzMax modules should present functional interfaces to C/C++ libraries, breaking an API down to a list of functions makes it a lot easier to learn and use and keeps the BlitzMax tradition of you don't need to use OOP to program in BlitzMax. 2. Writing the glue that presents an API in a functional form is a lot easier to do in C than in BlitzMax. More often than not libraries are published with example C source that demonstrates the operation of the API. By taking these examples and building them into basic C helper functions with the resource management that is often required is usually a simple process. Yes it's a shame it can't be done in .bmx but after accepting that C is often the best tool for the job I've come to realize it's the combination of the two that is BlitzMax's true strength. |
| ||
| That's not the answer I was hoping for. |
| ||
| I do understand, but it just feels dirty to have to write a C/C++ wrapper. Why shouldn't I just use C then? Reason enough to buy Blitzmax, was so I wouldn't HAVE to go back to that. However, all you can say in response is something like, "If I don't want to write C wrappers, then what am I doing here?". Well I'm here because blitz has always been about fun. :) |
| ||
| Then do exactly what I said - use C cause that's what you seem to want. If all you're worried about is having to convert all your current structs, why not just write a simple converter that takes an H file and spits out a bmx file using Type and Field instead? I think you'd be able to get most simple (aggregate) C stuff out the other end pretty easily. In fact, if you make this fully featured so it can convert most C stuff, then you'd probably have some fans! Aaron |
| ||
| Yeah, I wouldn't have much problem doing that, but I figured it should have already been implemented. I hope this won't be the new motto(Or arguement, or last card in your stack)... : "Aww heck.. Screw it, Just use C!" |
| ||
| BlitzMax is not C, so it can not parse/compile C code! You can write tools to convert C code to Max - I did this for the gl/glew stuff - but again, Max is not C and it is possible you will have problems converting certain C idioms. That said, with the ability to poke/peek via pointers, pretty much anything's possible. How much 'C-ness' to give Max was certainly a consideration during its development, but I decided early on that I didn't want to add a bunch of unsafe (c-arrays), crashprone (unions) and confusing (signed/unsigned) features purely to make importing C code easier. |
| ||
| Well if anything, signed/unsigned is not consfusing at all -- it's IMPORTANT! Even within Blitzmax itself. |
| ||
| But the biggest benefit(I can see) would be making bmax a great choice for developing 3rd party libs for C++/Any language. Many people buy/use Purebasic just for it's .dll/.lib creation. You can already export blitz types directly to C++, including object links, by padding a C++ struct with 16 bytes(e.g, 4 ints)..(In b3d.) so couldn't bmax just provide a pointer to the memory starting after that blitz info? and vice versa, blitz creates a shell for incoming structs. Even if it didn't support ALL of C++'s data types, that could be made clear.. |
| ||
| Fare enough, argument. however my rebuttle to this of course is that by making it harder to convert C to bmx your somewhat shooting yourself in the little toe if not the foot, since doing so makes it much more time consuming to access the wide and hugely massive source base that C/C++ currently has in great abundance, I've talked to verious language programmers in the last 4 years, one of which at least regreats greatly that he didn't support both signed/unsigned, and as far as I'm aware is taking steps to fix this issuse, be that as it may I'm used to having to convert large amount of header files, was about to look at fmod but I see someone has already done that ;) AaronK: it's not as easy as all that, since .h files hardly ever come in a standard format, and there all sorts of little gotch'yas when writting such an application, it is better to do this by hand normally, unless your dealing with a common standard as Mark was when he did the gl/glew stuff, it's possiable is what I'm trying to say, but it is not easy. |
| ||
| Yeah, I wish GCC would have some debug output to tell you all the structures it has detected, and their fields. :) |
| ||
| zenith : that would help, but its not a means to a complete and perfect end, since C headers have this nasty little habbit of using it's macro language within a header to perform many diferent operations. |
| ||
| argh true :/ |
| ||
| indeed. however adding sign & unsigned datatypes, and unions goes a long way in aiding that path way, the work around for the C macro system is to build one like it in BMX itself, pitty the language wasn't as extendable as the command set. |
| ||
| I tend to think Mark made a good call when he decided to leave out unsigned values and unions. With 32-bit values, it's rare indeed to need an unsigned value, other than for addresses. On a simple level, the distinction requires you to make a decision between signed and unsigned each time you use an int. On a slightly higher level it opens the door for peculiar errors, such as assigning an unsigned value to a signed value and getting incorrect results (because you need more than 32-bits to store the result). Let's keep BlitzMax simple and powerful. It's already more powerful than most people realize. |
| ||
| I thought about it though, a signed 32-bit int can still do everything an unsigned 32-bit int can, it's not like you're REALLY losing 1 bit, because you can still use it if you go negative :) |
| ||
| Actually Zenith's original question deserves a proper response: It would be nice if a C struct could easily have a corresponding Blitz representation for purposes of dealing with C-based APIs (which almost all APIs ultimately are). A language doesn't have to become C to do this. RealBasic used to have a handy tool which would convert C function calls from the Macintosh universal header files into the equivalent Basic declaration, allowing reasonably simple stuff to be done automagically. Both RealBasic and Blitz3D have memoryblock objects for dealing with arbitrary lumps of junk that don't necessarily correspond neatly to internal data types. |
| ||
| Both RealBasic and Blitz3D have memoryblock objects for dealing with arbitrary lumps of junk that don't necessarily correspond neatly to internal data types. So does BlitzMax. Look at CreateStaticBank() that references an exsiting block of memory. It's like PowerBasics "Dim At" command. I do think BliztMax should have a TypePtr command or simmilar to solve this issue: http://www.blitzbasic.com/Community/posts.php?topic=41809 |
| ||
| I thought about it though, a signed 32-bit int can still do everything an unsigned 32-bit int can, Think about it again then. |
| ||
| Think about it again then. What can it do that an unsigned 32 bit integer can't? More to the point, what can it do that a signed 64 bit integer can't? |
| ||
| More to the point, what can it do that a signed 64 bit integer can't? Now that's a much more interesting question.As to the original question, I thought that was rather obvious. It can accurately represent negative (2's complement) binary numbers so that basic arithmetic still works (plus and minus is the same operation, the same for division and multiplication) without having to be emulalted by a more complex command sequence. As far as I know, Zenith understands binary arithmetic well enough to understand that. As for the question regarding what an unsigned 32 bit integer can do that a signed 64 bit one can't, I wouldn't know, because that's not the position I'm argueing from! Guess I must have read his response wrong? |
| ||
| Re. Some comments made in this topic are counter-productive and don't help anyone. Personally I would have liked to see the ability to import C structures... but alas, it wouldn't really be basic. Maybe somebody could write a tool to generate wrappers easily? What can it do that an unsigned 32 bit integer can't? Hold more. Unsigned ints don't loose a bit to a sign in the number therefore they can represent higher numbers. Cya! Tommy. |
| ||
| Sorry, that should read "What can it do that a signed 32 bit integer can't"? Hold more. Unsigned ints don't loose a bit to a sign in the number therefore they can represent higher numbers. If, for example, your program *needs* to be able to access files >2gb, then it's probably going to be preferable for it to access files >4gb. Unsigned ints can represent higher +ve numbers than signed ints, but if you really need that extra size, why not just use a 64 bit signed int? |
| ||
| Yes, it was counter-productive, but someone had to ask. :) |
| ||
| Since this topic is stil alive: Mark posted one soulution to sending a Type as a "Struct" in this topic: http://www.blitzbasic.com/Community/posts.php?topic=41809 I've realized that I all along have assumed that when you make a type instance, the data is packed in the old Blitz3D way, even though a type now also contains metods and functions. It does seems to hold true so far, but it's not in the docs, so who knows... |
   |