|
|
|
#1 |
|
Messages: n/a
Hébergeur: |
Hi,
While adding a class, I usually have question: to make it static or not. Here is an example: class myclass { SomeType someTypeMember; public: SomeOtherType DoSomething() const { //do something with someTypeMember and return SomeOtherType return someOtherType; } }; The same class can be written as (the method I don't prefer): class myclass { public: static SomeOtherType DoSomething(SomeType someTypeVar) { //do something with someTypeVar and return SomeOtherType return someOtherType; } }; Is there a recommended reason why one style should be preferred than other? Thanks in advance, -Neel. |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
* neelsmail@rediffmail.com:
> > While adding a class, I usually have question: to make it static or > not. Choose "not". > Here is an example: > > class myclass { > SomeType someTypeMember; > public: > SomeOtherType DoSomething() const { > //do something with someTypeMember and return SomeOtherType > return someOtherType; > } > }; > > The same class can be written as (the method I don't prefer): > > class myclass { > public: > static SomeOtherType DoSomething(SomeType someTypeVar) { > //do something with someTypeVar and return SomeOtherType > return someOtherType; > } > }; > > Is there a recommended reason why one style should be preferred than > other? Yes, 'static' leads to a lot of problems (e.g. wrt. threading) and limits the class's usefulness (e.g. instantiation or derivation). What you need /seems/ to be some insight into how classes are used. Yes, you can use a class as a way to encapsulate an action. But generally a class is a type, from which you instantiate objects, where each object is comprised of a state plus relevant operations on that state, where those operations maintain some assumptions (called the class invariant) about the object's state. Cheers, & hth., - Alf -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
neelsmail@rediffmail.com wrote:
> Hi, > > While adding a class, I usually have question: to make it static or > not. Here is an example: > > class myclass { > SomeType someTypeMember; > public: > SomeOtherType DoSomething() const { > //do something with someTypeMember and return SomeOtherType > return someOtherType; > } > }; > > The same class can be written as (the method I don't prefer): > > class myclass { > public: > static SomeOtherType DoSomething(SomeType someTypeVar) { > //do something with someTypeVar and return SomeOtherType > return someOtherType; > } > }; > White space is free these days... > Is there a recommended reason why one style should be preferred than > other? > If function operates on the class rather than an instance of the class it should be static. If the member function is not static, an instance of the class is required in order to call it. Static members make the design clear and avoid the overhead of the unused this pointer. -- Ian Collins. |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
On Jul 17, 1:11pm, Ian Collins <ian-n...@hotmail.com> wrote:
> neelsm...@rediffmail.com wrote: > > Hi, > > > While adding a class, I usually have question: to make it static or > > not. Here is an example: > > > class myclass { > > SomeType someTypeMember; > > public: > > SomeOtherType DoSomething() const { > > //do something with someTypeMember and return SomeOtherType > > return someOtherType; > > } > > }; > > > The same class can be written as (the method I don't prefer): > > > class myclass { > > public: > > static SomeOtherType DoSomething(SomeType someTypeVar) { > > //do something with someTypeVar and return SomeOtherType > > return someOtherType; > > } > > }; > > White space is free these days... > > > Is there a recommended reason why one style should be preferred than > > other? > > If function operates on the class rather than an instance of the class > it should be static. > > If the member function is not static, an instance of the class is > required in order to call it. > > Static members make the design clear and avoid the overhead of the > unused this pointer. > > -- > Ian Collins.- Hide quoted text - > > - Show quoted text - Thanks for the replies. This is a way I look at it: - Yes, class is a type with associated actions. - But, I look at it as composite data type (if there is such a term). - In the example given above, you can consider it a data type. With more number of members but few/just one action, it becomes a very nice way to bind it together. - When you are using this class you can use it: const SomeClass someObject(someType); This way it becomes a very good place to keep related things together (even if it doesn't have an action associtated with it but generally it does). - This is the same reason why I don't prefer static because it looks as if it's a replacement for global functions than a class. - The only thing that gets in the way is if it isn't static there has to be a object created before we can use that class. But, given the fact that if you have static it will always live, I like to remedy the object creation problem with either singleton or simply by calling: someOtherType = SomeClass(someType).SomeMethod(); Does this makes sense? Thanks, -Neel. |
|
![]() |
| Outils de la discussion | |
|
|