C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›639 »

newsomnuke: Feb 25, 2007

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

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 14:18

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

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.

Or, to be specific about my problem, how do you tell flex to read from a memory buffer rather than yyin?

Use the YY_INPUT macro to define a different read operation.

# ? Feb 11, 2009 01:55

FearIt: Mar 11, 2007

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:

	SendMessage(AIM_HWND, WM_KEYDOWN, 0x11, 0); 
	SendMessage(AIM_HWND, WM_KEYDOWN, 0x4E, 0); 
	Sleep(1000); 
	SendMessage(AIM_HWND, WM_KEYUP, 0x4E, 0);
	SendMessage(AIM_HWND, WM_KEYUP, 0x11, 0);

It seems to only be processing the N though as I can see my IM window move to the next SN that starts with the letter.

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

slovach: Oct 6, 2005; Lennie Fuckin' Briscoe

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

narfanator: Dec 16, 2008

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

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

Now what kind of crappy-rear end local variable would that be?

# ? Feb 11, 2009 05:26

Smackbilly: Jan 3, 2001; What kind of a name is Pizza Organ! anyway?

What does the C++ standard have to say about this?

code:

class FooOuter;

class Bar 
{
  private:
    void target() {};

  friend class FooOuter;
};

class FooOuter 
{
  private:
    class FooInner 
    {
       void callTarget(Bar b) 
       { 
         b.target(); // Legal or not?
       }
    };
};

I ask because I ran into one version of g++ which accepts this as legal, and another (older) version which does not. Based on the fact that the newer version considers it legal, I assume this is a bug in the older version of gcc, but I thought that friendship was supposed to be very restrictive and not inherited or transitive, so if it's legal that surprises me and I'm curious as to what the rationale is.

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

Smackbilly: Jan 3, 2001; What kind of a name is Pizza Organ! anyway?

narfanator posted:

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++)

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

raminasi: Jan 25, 2005; a last drink with no ice

narfanator posted:

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++)

Yeah, a static variable would do this, but the odds are infinitesimal that it's what you actually want.

# ? Feb 11, 2009 06:15

narfanator: Dec 16, 2008

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

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

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

narfanator: Dec 16, 2008

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:

{
foo f;
}

the object "f" still exists, while the reference "f" doesn't. I think you could also rephrase as "Objects of this type can be deleted by going out of scope."

# ? Feb 11, 2009 08:01

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

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. ...
code:
class A {
    class B { };
    friend class X;
};
class X : A::B {     // ill-formed: A::B cannot be accessed
                     // in the base-clause for X
    A::B mx;         // OK: A::B used to declare member of X
    class Y : A::B { // OK: A::B used to declare member of X
        A::B my;     // ill-formed: A::B cannot be accessed
                     // to declare members of nested class of X
    };
};

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

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

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

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

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

DoctorTristan: Mar 11, 2006; I would look up into your lifeless eyes and wave, like this. Can you and your associates arrange that for me, Mr. Morden?

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:

#ifndef MYCONSTANTS_H
#define MYCONSTANTS_H

  const int initialisationSize = 1000;

#endif

and adding #include "myconstants.h" in any file where I need it? Or do I need to do it using an extern? Lastly, does the constant need to be in the same namespace as the class implementation that needs to see it?

# ? Feb 11, 2009 16:50

newsomnuke: Feb 25, 2007

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?

No, globals are visible to all namespaces.

# ? Feb 11, 2009 17:28

newsomnuke: Feb 25, 2007

Avenging Dentist posted:

Use the YY_INPUT macro to define a different read operation.

I ended up using yy_scan_string() instead because it's a bit tidier, but thanks. Now to sort out the wonderful shift/reduce errors I'm getting...

# ? Feb 11, 2009 17:30

That Turkey Story: Mar 30, 2003

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

newsomnuke: Feb 25, 2007

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.

Oh, sorry

. I know #defines can be evil, but I really fail to see what's so especially bad about using them for simple constants?

# ? Feb 11, 2009 18:07

Vanadium: Jan 8, 2005

The preprocessor does not know about namespaces.

# ? Feb 11, 2009 18:17

newsomnuke: Feb 25, 2007

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

MarsMattel: May 25, 2001; God, I've heard about those cults Ted. People dressing up in black and saying Our Lord's going to come back and save us all.

Surely the #define would also be a global symbol?

# ? Feb 12, 2009 00:41

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

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

Contero: Mar 28, 2004

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:

#include "scheme-private.h"
#include <stdio.h>
#include <stdlib.h>

pointer doit (scheme *sc, pointer args) {
   printf("did it\n");

   return sc->NIL;
}

int main ()
{
   scheme scm;
   FILE *file;

   scheme_init(&scm);

   file = fopen("init.scm", "r");
   if (!file)
      printf("didn't open\n");
   scheme_load_file(&scm, file);
   if (fclose(file))
      printf("didn't close\n");

   scheme_define(&scm, scm.global_env, mk_symbol(&scm, "doit"), mk_foreign_func(&scm, doit));

   scheme_load_string(&scm, "(main (doit))");

   scheme_apply0(&scm, "main");

   scheme_deinit(&scm);
   return 0;
}

Luabind: Looks great. I haven't had much time to load it up yet though. I wasted a lot of time trying to build lua from scratch on windows using cl from the command line which was a little horrifying :gonk:

. I only now realized there's an installer for windows.

# ? Feb 12, 2009 05:11

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

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

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

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

MarsMattel: May 25, 2001; God, I've heard about those cults Ted. People dressing up in black and saying Our Lord's going to come back and save us all.

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).

(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)

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

That Turkey Story: Mar 30, 2003

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.

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)

dynamic_cast will return 0 if you are not casting to a proper child type and throw an exception in the case of references. If you know the type of the child before hand, use static_cast.

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

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

(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

narfanator: Dec 16, 2008

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).

* Or malloc or my_gay_alloc

Okay, pointers or nothing. Thanks!

# ? Feb 12, 2009 19:27

MarsMattel: May 25, 2001; God, I've heard about those cults Ted. People dressing up in black and saying Our Lord's going to come back and save us all.

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.

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

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.

Edit: Assuming your "boring reasons" mentioned earlier don't stop you doing this.

# ? Feb 12, 2009 20:10

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

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.

Edit: Assuming your "boring reasons" mentioned earlier don't stop you doing this.

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

Thug Bonnet: Sep 22, 2004; anime tits ftw

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

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

I don't see what you're even trying to do with this??

# ? Feb 13, 2009 01:51

Thug Bonnet: Sep 22, 2004; anime tits ftw

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:

#include <list>
#include <iostream>

class Vehicle{
	public:
		Vehicle(){};
		virtual ~Vehicle(){};
};

class Car: public Vehicle{
	public:
		Car(){};
		virtual ~Car(){};
};

class Porsche: public Car{
	public:
		Porsche(){};
		virtual ~Porsche(){};
};

class VehicleDealership{
	public:
		VehicleDealership(){};
		virtual ~VehicleDealership(){};

	protected:
		void addVehicle(Vehicle* v){
			l.push_back(a);
		};

	private:
		std::list<Vehicle*> l;
};

class CarDealership: public VehicleDealership{
	public:
		CarDealership(){};
		virtual ~CarDealership(){};

	protected:
		void addCar(Car* c){
			l.push_back(c);
			addVehicle(c);
		};

	private:
		std::list<Car*> l;

};

class PorscheDealership: public CarDealership{
	public:
		PorscheDealership(){};
		virtual ~PorscheDealership(){};

		void add(Porsche* p){
			addPorsche(p);
		};

	protected:
		void addPorsche(Porsche* p){
			l.push_back(p);
			addCar(p);
		};

	private:
		std::list<Porsche*> l;

};

int main(){
	PorscheDealership* pdp = new PorscheDealership();
	Porsche* pp = new Porsche();

	PorscheDealership->add(pp);

	return 0;
};

# ? Feb 13, 2009 02:47

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

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

Thug Bonnet: Sep 22, 2004; anime tits ftw

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.

EDIT: I mean actual, real-world problem 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

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

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

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 14:18

floWenoL: Oct 23, 2002

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.

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.

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›639 »