|
If I've got a function which takes a FILE*, but I've got a const char* (ie I've already read the file in), what are my options? I'm currently using tmpfile() but it's hardly ideal. Or, to be specific about my problem, how do you tell flex to read from a memory buffer rather than yyin?
|
# ? Feb 11, 2009 01:21 |
|
|
# ? Apr 29, 2024 11:42 |
|
ultra-inquisitor posted:If I've got a function which takes a FILE*, but I've got a const char* (ie I've already read the file in), what are my options? I'm currently using tmpfile() but it's hardly ideal. Use the YY_INPUT macro to define a different read operation.
|
# ? Feb 11, 2009 01:55 |
|
I've been trying to figure out how to open a new AOL IM message window, basically by emulating a CONTROL+N message to the AIM HWND. My code for this call is: code:
Am I doing something wrong? edit: I figured out a way around this by using a spacebar hit instead, but I wanna leave the question open still, as I'm curions why control didn't work with my implementation. FearIt fucked around with this message at 04:52 on Feb 11, 2009 |
# ? Feb 11, 2009 04:02 |
|
I'm not 100% sure, but I'm pretty sure WM_CHAR, and WM_KEYDOWN will not send any modifiers. Maybe an uglier solution, but you can try SendInput.
|
# ? Feb 11, 2009 05:03 |
|
That Turkey Story posted:That is not CRTP. CRTP is class b : some_template< b > {}; You are correct, sir, and I have edited post. Thanks. New Question: Is there any way to say; "Even if this object-type is made as a local variable, don't destroy the object at the end of the scope"? (Again, C++)
|
# ? Feb 11, 2009 05:21 |
|
Now what kind of crappy-rear end local variable would that be?
|
# ? Feb 11, 2009 05:26 |
|
What does the C++ standard have to say about this?code:
I tried to google for the answer but everything I get has to do with interactions between the inner and the outer class, not between the inner class and a third-party class. Smackbilly fucked around with this message at 05:42 on Feb 11, 2009 |
# ? Feb 11, 2009 05:34 |
|
narfanator posted:New Question: Would using a static variable in local scope give you what you want? If not, then what behavior are you looking for?
|
# ? Feb 11, 2009 05:45 |
|
narfanator posted:You are correct, sir, and I have edited post. Thanks. Yeah, a static variable would do this, but the odds are infinitesimal that it's what you actually want.
|
# ? Feb 11, 2009 06:15 |
|
No, actually, a static would work. It's for testing functions, so I do expect to have them not compile later on, let alone not be called. But yah, static solves the immediate problem, but the real point of this is to learn coding tricks, so that doesn't answer /that/ part.
|
# ? Feb 11, 2009 07:22 |
|
narfanator posted:Is there any way to say; "Even if this object-type is made as a local variable, don't destroy the object at the end of the scope"? (Again, C++) Yes, use new. This should be obvious since the data must be on the heap (ok, not if it's static), since the stack gets wiped out when you exit a function.
|
# ? Feb 11, 2009 07:56 |
|
Sorry; should have been more clear; I thought that by "local variable" I was also saying I wasn't making the object via the "new" operator. I'd like to be able to put something in the class foo such that, when: code:
|
# ? Feb 11, 2009 08:01 |
|
Smackbilly posted:What does the C++ standard have to say about this? I don't know, what does the C++ standard have to say about it? (This is meant to imply that you can look at the standard just as well as I can.) Nevertheless, ISO/IEC 14882:2003 § 11.4 #2 posted:However, the declarations of members of classes nested within the friend class cannot access the names of private and protected members from the class granting friendship. ... So in conclusion, the older version of GCC was right. Note, however, that the newer version of GCC is right for C++0x, which changes the restrictions on friendship so that the two ill-formed statements above are legal.
|
# ? Feb 11, 2009 08:08 |
|
narfanator posted:Sorry; should have been more clear; I thought that by "local variable" I was also saying I wasn't making the object via the "new" operator. What's wrong with new? It is how you create objects that aren't a part of the stack*. You can wrap all that behavior up in your foo class so that it looks like a stack object, but I know of no language that allows objects on the stack to persist beyond the stack unwind (no, Java classes don't count; they're created on the heap). * Or malloc or my_gay_alloc
|
# ? Feb 11, 2009 08:12 |
|
The distinction here is that local variables aren't necessarily stack objects in an arbitrary language, or at least not purely stack objects. Certainly, many dynamic languages allow you to close on the variables of enclosing activations (variables, not just values). That said, local variables in C++ are always stack objects (EDIT: when they're not static, of course). If you really want this memory-leaking effect without explicit new expressions, you can just create a class which allocates a heap object in its constructor, keeps a reference to that object in a field, and then doesn't delete it in its destructor. rjmccall fucked around with this message at 08:55 on Feb 11, 2009 |
# ? Feb 11, 2009 08:45 |
|
I have another question about proper use of const. I want to define a compile-time constant that specifies how much space to reserve when initialising certain vectors; which I'll need to use in several places in my class definitions. Can I do this by creating a myconstants.h as follows:code:
|
# ? Feb 11, 2009 16:50 |
|
That would work, but it isn't particularly elegant. Just use a #define for a constant.DoctorTristan posted:Lastly, does the constant need to be in the same namespace as the class implementation that needs to see it?
|
# ? Feb 11, 2009 17:28 |
|
Avenging Dentist posted:Use the YY_INPUT macro to define a different read operation.
|
# ? Feb 11, 2009 17:30 |
|
ultra-inquisitor posted:That would work, but it isn't particularly elegant. Just use a #define for a constant. WHAT!? No. Use const, not a #define. Don't ever use #define for integral constants unless your value has to be used during preprocessing.
|
# ? Feb 11, 2009 17:40 |
|
That Turkey Story posted:WHAT!? No. Use const, not a #define. Don't ever use #define for integral constants unless your value has to be used during preprocessing.
|
# ? Feb 11, 2009 18:07 |
|
The preprocessor does not know about namespaces.
|
# ? Feb 11, 2009 18:17 |
|
Ok, did some reading up. Sorry for the misinformation. FWIW, it just seemed ugly to me having the same global variable defined in every translation unit.
|
# ? Feb 11, 2009 19:12 |
|
Surely the #define would also be a global symbol?
|
# ? Feb 12, 2009 00:41 |
|
ultra-inquisitor posted:Ok, did some reading up. Sorry for the misinformation. FWIW, it just seemed ugly to me having the same global variable defined in every translation unit. Who cares? It won't take up any memory. MarsMattel posted:Surely the #define would also be a global symbol? It's also present in every namespace and has the potential to gently caress up your code unless you're 100% sure that token isn't used in any other context in your entire program.
|
# ? Feb 12, 2009 01:42 |
|
Tinyscheme: This looked perfect. Works in windows, really small, just include the source, but I can't get it to work so far and there is pretty much nonexistent documentation for it. I made a hello world program and it just does nothing :I. Has anyone ever used this or can tell me anything about what might be wrong?code:
|
# ? Feb 12, 2009 05:11 |
|
C was pretty much the first language I taught myself and I quickly moved on to C++, but that with the Borland stardard before C99. When I got to college I was totally lost with how things were just so slightly different that the compiler would constantly flip out on me. The other day I tried to create an array of objects that each owned an array and I ran right back into all the little nitpick hodgepodge. So I had to declare myself incompetent in C++ and get comfortable again. I was wondering if it didn't seem like I'd use C++ for anything for awhile if I should instead direct my efforts towards C++0x. I sounds like they're planning to standardize that by 2010--I wonder how well that will go. But I don't want to go through this whole thing all over again in a year or two. I also wanted to know if anything substantial happened to the C++ specification since 1999. Knowing of any tricks should help me make sure I find a resource that is most up to date. For some perspective, it seems every 6 months when I write a C++ application I still get surprised about initialization lists in constructors. I do a lot of Java coding, but despite this I just never had to write a constructor that way "in the old days."
|
# ? Feb 12, 2009 06:28 |
|
Probably a pretty basic polymorphism question, but it's something I never picked up on. A project I'm working on has a class CRawBinaryData which inherits from CRawData, an abstract. Another separate module I'm working on stores pointers to CRawData. Obviously these pointers could be pointing to CRawBinaryData or some other child of CRawData. If I need to access functionality in CRawBinaryData from these CRawData pointers, is there a special form of casting required? Something like CRawBinaryData* bin = (CRawBinaryData*)mRawData or whatever is obviously not typesafe, but I'm unaware of the alternatives (if any). (ed: the idea to modify CRawData to have a member enum indicating its type has come up, but right now we can't do that for very boring reasons) Ciaphas fucked around with this message at 16:59 on Feb 12, 2009 |
# ? Feb 12, 2009 16:56 |
|
Ledneh posted:If I need to access functionality in CRawBinaryData from these CRawData pointers, is there a special form of casting required? Something like CRawBinaryData* bin = (CRawBinaryData*)mRawData or whatever is obviously not typesafe, but I'm unaware of the alternatives (if any). dynamic_cast might be useful, it uses RTTI to determine if the cast is valid (at run-time) and will either return a valid pointer or a null pointer.
|
# ? Feb 12, 2009 17:48 |
|
Ledneh posted:Probably a pretty basic polymorphism question, but it's something I never picked up on. A project I'm working on has a class CRawBinaryData which inherits from CRawData, an abstract. Another separate module I'm working on stores pointers to CRawData. Obviously these pointers could be pointing to CRawBinaryData or some other child of CRawData. But in general, if you find yourself having to dynamic_cast because you don't know what child type you are pointing to and you need to handle it differently than other children, you are probably missing a better solution. The general idea of polymorphism is to get transparent dispatching of appropriate behavior based on static or dynamic type data. If you are having to explicitly determine the type of the child and handle it accordingly in code that deals with your base, your interface is likely not rich enough or you are approaching your solution in a less-than-ideal way.
|
# ? Feb 12, 2009 17:55 |
|
(edit) ^^ I came on board recently so I don't know for sure, but I SUSPECT that at the nitty-gritty level the design of this project was played-by-ear rather than planned out at start. I might be able to redesign it after the upcoming deadline. But yeah I agree the situation is less than ideal. And it's not so much a case of "handling it DIFFERENTLY" as a case of "not handling it at ALL" if it's not a CRawBinaryData. I doubt that makes any difference to anyone, but I felt the need to be pedantic vOv --- Oh, THAT'S what those weird cast things are. Time to google about and learn up on the rest of them, I guess. Hope the project manager'll let me turn on RTTI in the compiler, too. Thanks Ciaphas fucked around with this message at 18:00 on Feb 12, 2009 |
# ? Feb 12, 2009 17:55 |
|
Avenging Dentist posted:What's wrong with new? It is how you create objects that aren't a part of the stack*. You can wrap all that behavior up in your foo class so that it looks like a stack object, but I know of no language that allows objects on the stack to persist beyond the stack unwind (no, Java classes don't count; they're created on the heap). Okay, pointers or nothing. Thanks!
|
# ? Feb 12, 2009 19:27 |
|
Ledneh posted:(edit) ^^ I came on board recently so I don't know for sure, but I SUSPECT that at the nitty-gritty level the design of this project was played-by-ear rather than planned out at start. I might be able to redesign it after the upcoming deadline. But yeah I agree the situation is less than ideal. Edit: Assuming your "boring reasons" mentioned earlier don't stop you doing this.
|
# ? Feb 12, 2009 20:10 |
|
MarsMattel posted:To avoid the cast and RTTI, you could define a public virtual bool CRawData::skip() const (or something actually meaningful in your code) with the default impl. returning false, and CRawBinaryData implementing with return true. This doesn't tackle the problems your design may or may not have, but it saves the cast & RTTI. They do, for right now, but that's a better idea than what I had. I'll write it down for when I'm sure that I can safely make the change. Thanks!
|
# ? Feb 13, 2009 00:09 |
|
Obviously this is eating more memory, but is safer re: the bag-of-apples is not-like bag-of-fruit. Is this legit? e: see below Thug Bonnet fucked around with this message at 02:47 on Feb 13, 2009 |
# ? Feb 13, 2009 01:47 |
|
I don't see what you're even trying to do with this??
|
# ? Feb 13, 2009 01:51 |
|
Avenging Dentist posted:I don't see what you're even trying to do with this?? Oh dang, sorry. I've got my head so far into it I didn't realize it didn't make much sense without context The idea is that there is a hierarchy of types, each more specific than the last, and containers that operate on these types independently. This is Re: this post. The intent is to avoid potentially unsafe casting, and the ability to cast and dereference to an improper type as seen in the C++-Faq-Lite here. I had meant to re-name things to make this more clear, we can use the car-lot analogy. code:
|
# ? Feb 13, 2009 02:47 |
|
That still makes no sense because none of your collection base classes even have a public interface, so it's not clear what problem you're actually trying to solve here. EDIT: I mean actual, real-world problem here. Avenging Dentist fucked around with this message at 03:02 on Feb 13, 2009 |
# ? Feb 13, 2009 02:54 |
|
Avenging Dentist posted:That still makes no sense because none of your collection base classes even have a public interface, so it's not clear what problem you're actually trying to solve here. In practice the base classes would be purely virtual, I just didn't want to crap up the post and make a huge(r) block of code. The intent is that only the top-most derived class (from Vehicle and VehicleDealership) would be intended to actually have public methods, and would thus be the final derivation. This is to prevent the other implementation (from my previous posts), in which only the base-most class would have a list to the base-most interface. In this case, VehicleDealership (would have a list of Vehicle*), and the classes that derive from it (for example, CarDealership, etc) would be responsible from casting properly from the list in VehicleDealership. The other wrinkle being that a View may be observed by more than one Presenter of different types. If you wanted to Porsche get(); from the PorscheDealership, previous I was requiring the implementation to cast up from the VehicleDealership's list of Vehicle* to a Porsche*. So now, while I have multiple lists at each level of interface, it's safer in theory because it avoids casting and the final derivation can be a bit more type-safe in what it add()s. Ultimately the purpose is to to have a loosely-coupled MVP style "Passive-View" relationship in which a Presenter class drives a View class without knowing anything more specific about it than it needs. I.E. GamePresenter drives a GameView, but any particular GameView may be of a more specific type like an OpenGlGameView, CursesGameView, etc.
|
# ? Feb 13, 2009 03:31 |
|
Thug Bonnet posted:Ultimately the purpose is to to have a loosely-coupled MVP style "Passive-View" relationship in which a Presenter class drives a View class without knowing anything more specific about it than it needs. I.E. GamePresenter drives a GameView, but any particular GameView may be of a more specific type like an OpenGlGameView, CursesGameView, etc. Okay, see, this is actual information about the real-world problem you're trying to solve, whereas all the rest of your posts have been polluted with paragraphs of abstract crap about types. Unfortunately, this information makes it sound like you have no idea what you're doing. Why can't a presenter just have a collection of View* and call virtual methods on them as appropriate? rjmccall fucked around with this message at 03:51 on Feb 13, 2009 |
# ? Feb 13, 2009 03:45 |
|
|
# ? Apr 29, 2024 11:42 |
|
Thug Bonnet posted:If you wanted to Porsche get(); from the PorscheDealership, previous I was requiring the implementation to cast up from the VehicleDealership's list of Vehicle* to a Porsche*. So now, while I have multiple lists at each level of interface, it's safer in theory because it avoids casting and the final derivation can be a bit more type-safe in what it add()s. What if someone has a PorscheDealership but add()s a non-Porsche car? Now your three lists (Car, Vehicle, Porsche) are out of sync. It may be more "typesafe", whatever that means in this context, but that bears no relation to its real-world utility. It seems you're better off having a Dealership<T> type but I don't know how that translates to your GameView.
|
# ? Feb 13, 2009 03:46 |