Though implementation problem

Well, OO or not, what's good about C++ is that you aren't limited to one paradigm.

True, but apparently that's your favorite tune.

Did you forget a "no" keyword in there?

Hah! Yes. That's what I get for being in a hurry.

If they are terrible names, what would you suggest?

'ToUTF16' is alright if the other names in the set also represent a shift in character encoding, but I would couple them by indirection. (Instead of 'utf16_name = my_name.ToUTF16()' you allow for 'utf16_name = my_name.Encoding().ToUTF16()'.) However, I assume, being you, you will also provide methods like 'ToUpper' and 'ToLower' that do not represent a change in encoding. That said, the names imply that it converts the existing string data; I understood that you intended the data to be spawned anew and then converted, and with this in mind, the name of the method should indicate this behavior. As for 'ToANSI', at least change it to 'ToASCII', but that doesn't fit either if you are intending it to imply "Microsoft ANSI".

If it part of what the object does, then yes. Neatly organized.

But what does an object do? At what point does "what an object can be directed to do" stop implying "what feat an object is capable of"? You said something in another thread about cats meowing. A cat can be directed to do marvelous things; they are fairly intelligent animals, but they will never naturally do anything beyond what is required to survive.

If classes cannot be extended indefinitely, how do OO people do it? Create several classes built around the same thing?

I do not know how "OO" people would do it because "OO" is a garbage buzzword used as an umbrella term for several techniques. Of course, the behavior of an object is usually too closely coupled to the object. Worse, most seem to think that the interface is more important than the mechanic. These two factors lead to code with altogether too many interfaces associated with altogether too many classes. This is a problem. It can be fixed. Instead of, in your case, providing a variety of methods to provide behavior for conversion of every encoding you may find useful, you instead provide a single method for conversion and a constructor/operator pair that changes the 'codec's used by the conversion. You get your "everyone would know where to look", "the object does the work", and even the sexy syntax without polluting the interface, and, this is the important bit, you have made the class infinitively expandable--even at runtime--without creating an impossibly vigorous tree of class relationships. To be said simply: you give the object the dictionary, ask the object to do the translation, and it performs the translation. Lovely.

(In terms of that cat meowing thing, consider this: virtually all animals have some form of vocalization, but different animals in the same species vocalize differently. What I'm suggesting: give the animals a voice--an object describing the characteristics of that voice.)

But come on, give me some slack here.

You are "reinventing the wheel" so that it might be more suitable to your tastes. You have all the slack from me you could ever want. I'm probably one of the few people around who encourages--even demands as a tutor--that one "reinvents the wheel".

C++ isn't just straight forward.

C++ is remarkably strait forward. Trust me on this, one can get the design wrong in any language; C++ is one of the few that allows you get the design right!

I'm testing methods and ways of doing things.

Obviously. I am not trying to dissuade you from experimenting; I'm only warning you of mistakes. I don't even care if you make such mistakes. It would possibly be wiser just to listen, but first hand experience is usually invaluable.

Without experimenting, you won't learn anything.

^_^

Tell that to the alchemists. (Occasionally, just listening to the experienced is enough.)

Soma

But if the wrapper member starts to divulge from the free function, it means the free function must be updated, as well, since seeing as if there was no member from the beginning the functionality that is required simply doesn't exist.

Yes, so you must update two functions instead one, for no added benefit. Consequently, you might as well not have the member function since the free function will suffice.

The concept of free functions is to increase encapsulation and to protect the class against changes, and to increase code reuse...
So what are the purposes of member functions? To provide the functionality that the free members lack?

To provide the core behaviour of the class, the necessary behaviour that needs to access the internals instead of adapting existing behaviour.

Originally Posted by laserlight

Yes, so you must update two functions instead one, for no added benefit. Consequently, you might as well not have the member function since the free function will suffice.

"If one function changes, so must the other..."
I think I get that point. It's better than putting all functionality as member functions, however. It's a small thing that you might have to sacrifice if you want the best of both worlds, so to speak...
But then again, the free member function isn't supposed to change very much because otherwise there's no point in making it free. It's supposed to remain static as they class implementation changes. Otherwise I could just have made it a member instead...

Then I take it option 3 means you go the way of the standard library. Lots of low level functionality and algorithms. Much code reuse, but little programmer friendly, so it becomes hard to maintain.

This is a simple matter of experience and understanding. You've admitted that you don't even know how much of the STL works. You assume that because the source looks unusual to you it must be unusual to everyone. The STL is much simpler than any other library; even being generous regarding the different kinds of abstraction there are only five different concepts at the core. Once you understand the concepts utilized by the STL, all of which can be used in environments that do not use templates/generics as an implementation mechanism, understanding the source is trivial. (That is to say, at least as trivial as any other source.)

The picture I'm seeing is that it might just give the best of both worlds with as little sacrifice as possible (there will, of course, be no perfect solution, but as I see it, it's a small sacrifice that won't do that much harm).

There is a perfect solution. Understanding the STL is hampered only by the verbose public interface. The interface can easily be simplified by using more abstraction and expression templates in the implementation--for example, the normal interface for much of the STL could use 'ranged_pair' instead of a pair of iterators.

Soma

Originally Posted by iMalc

That's knowledge I gained form a course some time ago.

What was the name of that course and does the Guy has a book? Thank you!

Originally Posted by phantomotap

True, but apparently that's your favorite tune.

Not always.

Originally Posted by phantomotap

'ToUTF16' is alright if the other names in the set also represent a shift in character encoding, but I would couple them by indirection. (Instead of 'utf16_name = my_name.ToUTF16()' you allow for 'utf16_name = my_name.Encoding().ToUTF16()'.) However, I assume, being you, you will also provide methods like 'ToUpper' and 'ToLower' that do not represent a change in encoding. That said, the names imply that it converts the existing string data; I understood that you intended the data to be spawned anew and then converted, and with this in mind, the name of the method should indicate this behavior. As for 'ToANSI', at least change it to 'ToASCII', but that doesn't fit either if you are intending it to imply "Microsoft ANSI".

The problem is that there's no way I can convert existing data from ansi to unicode because that would break how templates work, so I must return a new object with the data... Yet, the ToUpper/ToLower can simply transform the data inside the class, so there's no need to return a new object.
I guess more appropriate names then, might be, such as
ConvertToUpper <-- would convert the existing data to uppercase
ToUpper <-- would return a new object with the data

But this does give me an idea about trying to break up the class in components and placing those classes as objects inside the main class, as to split up encoding-related functions into an Encoding class, as it seems you were suggestion something in lines of as (obj.Encoding().ToUTF16).

Originally Posted by phantomotap

But what does an object do? At what point does "what an object can be directed to do" stop implying "what feat an object is capable of"? You said something in another thread about cats meowing. A cat can be directed to do marvelous things; they are fairly intelligent animals, but they will never naturally do anything beyond what is required to survive.

Well, I think that's difficult. There's a fine line where everything do end.
Obviously it's bad to mix everything into one single class.

Originally Posted by phantomotap

I do not know how "OO" people would do it because "OO" is a garbage buzzword used as an umbrella term for several techniques. Of course, the behavior of an object is usually too closely coupled to the object. Worse, most seem to think that the interface is more important than the mechanic. These two factors lead to code with altogether too many interfaces associated with altogether too many classes. This is a problem. It can be fixed. Instead of, in your case, providing a variety of methods to provide behavior for conversion of every encoding you may find useful, you instead provide a single method for conversion and a constructor/operator pair that changes the 'codec's used by the conversion. You get your "everyone would know where to look", "the object does the work", and even the sexy syntax without polluting the interface, and, this is the important bit, you have made the class infinitively expandable--even at runtime--without creating an impossibly vigorous tree of class relationships. To be said simply: you give the object the dictionary, ask the object to do the translation, and it performs the translation. Lovely.

(In terms of that cat meowing thing, consider this: virtually all animals have some form of vocalization, but different animals in the same species vocalize differently. What I'm suggesting: give the animals a voice--an object describing the characteristics of that voice.)

That's generic programming if I'm not mistaken. It's true - such functions should come first, but then again, they may not be the easiest or pretties to use, so creating wrappers for them if/when you have time seems like a good thing to me.

Originally Posted by phantomotap

This is a simple matter of experience and understanding. You've admitted that you don't even know how much of the STL works. You assume that because the source looks unusual to you it must be unusual to everyone. The STL is much simpler than any other library; even being generous regarding the different kinds of abstraction there are only five different concepts at the core. Once you understand the concepts utilized by the STL, all of which can be used in environments that do not use templates/generics as an implementation mechanism, understanding the source is trivial. (That is to say, at least as trivial as any other source.)

Well, I'll just take your word for that.

Originally Posted by phantomotap

There is a perfect solution. Understanding the STL is hampered only by the verbose public interface. The interface can easily be simplified by using more abstraction and expression templates in the implementation--for example, the normal interface for much of the STL could use 'ranged_pair' instead of a pair of iterators.

Yay for classes wrapping STL functionality, eh? XD

Originally Posted by Elysia

Then I take it option 3 means you go the way of the standard library. Lots of low level functionality and algorithms. Much code reuse, but little programmer friendly, so it becomes hard to maintain.

So the aim is to go for option 2

One's personal lack of experience with the standard library does not translate into an overall un-programmer-friendliness of it for everyone.

I know you're aiming for extensibility and I know that's because you think it's best. It's simply that you haven't learnt otherwise. Your aparent closed-mindedness is possibly your greatest weakness.

Actually reusability is where I really like Prolog. Code reusability goes through the roof in that language! Write code once and reuse it in many ways later on you never imagined you could initially.

That's generic programming if I'm not mistaken. It's true - such functions should come first, but then again, they may not be the easiest or pretties to use, so creating wrappers for them if/when you have time seems like a good thing to me.

No. What I offered has nothing to do with generics and everything to do with composition.

You demand:

Code:

my_instance.do_something_very_specific_x();
my_instance.do_something_very_specific_x_only_differently();

Composition (What I offered is a composition hierarchy.):

Code:

something_very_specific instructions1;
something_very_specific instructions2;
some_class my_instance(instructions1);
my_instance.do_x();
my_instance(instructions2);
my_instance.do_x();

This: "But this does give me an idea about trying to break up the class in components and placing those classes as objects inside the main class, as to split up encoding-related functions into an Encoding class, as it seems you were suggestion something in lines of as (obj.Encoding().ToUTF16)." is another form of composition.

Well, I think that's difficult.

Not really; once the class has a method all instances of a class may not understand you've lost the battle. (See class 'duck'. If you put a 'quack' method you've lost. Some ducks species do not quack you see.)

Yay for classes wrapping STL functionality, eh? XD

O_o

How many times have I told you, methods that only wrap functionality that is easily accomplished with free functions are less than useless; such methods only increases coupling, cost of development, and cost of education, and decreases encapsulation, functionality, and cohesion.

There is no fault in the capabilities of the STL nor in the design beyond the usage being rather verbose. Sacrificing capability is not an option. (Your prejudice costs a lot.) The STL interface would benefit from deriving even the mechanics from traits/policies/expressions where possible so that the interface doesn't require specific adapters/functions/parameters to define this behavior. I don't suggest this because I think it would make the source sexy. I suggest it, indeed have even coded it, because it is less verbose.

The difference between warping the existing STL interfaces with countless class specific methods and what I suggest is obvious: My suggestion is not a simple interface change for the sake of a few novice programmers; it would require a more robust implementation mechanism, allowing for a simpler interface, because it would never require the adapters/functions to be written in the first place.

Soma

From what I have seen so far from Java programming (and I am really not an experiences java programmer), classes are extremely minimalistic and distinction has been made to data classes and function classes.
A function which listens to an even is not implemented in the class which contains the event, for example.

I think this is due to the absence of namespaces in Java. In other words, I agree with Laserlight that instead of making functions a member of a class, they should be member of a namespace. Classes and namespaces should be minimalistic?

I was about to suggest this, when I read her/his comment...

Originally Posted by MarkZWEERS

I think this is due to the absence of namespaces in Java.

Absense? Java does have namespaces; they just renamed them to something else (packages) just like they rename everything else to try to confuse people.

If a function can do its job the same (or better) as a free function, then it shouldn't be a member function.
Lets take your example of ToUpper(). If it's a member function, it can only convert that particular class to upper-case. So if you have several different string classes, or even char* strings, you need to write several different ToUpper() functions. If you had a general ToUpper() free function, any class (which implements some type of iterators) or even char* strings could all use that one function. That would save a lot of time not having to re-invent the wheel, even if it's just re-wrapping the wheel.
I found a class at work with over 150 member functions & 120 member variables!!! Worse yet, there was absolutely no documentation about what any of it does... So trying to modify it is a nightmare. Don't make the same mistake as they made, otherwise the developer that has to inherit your code will curse your name until the end of time.

BTW Elysia, don't you ever sleep? I see you posting 24 hours a day!

std::basic string has like 107 member functions, maybe Elysia should use that. It recoded a bunch of algorithms as member functions, too. I think Elysia will be very happy with the decisions in the design.

Originally Posted by cpjust

If a function can do its job the same (or better) as a free function, then it shouldn't be a member function.
Lets take your example of ToUpper(). If it's a member function, it can only convert that particular class to upper-case. So if you have several different string classes, or even char* strings, you need to write several different ToUpper() functions. If you had a general ToUpper() free function, any class (which implements some type of iterators) or even char* strings could all use that one function.

Yeah, I've learned this much.

That would save a lot of time not having to re-invent the wheel, even if it's just re-wrapping the wheel.

I consider it a convenience. Something that makes it better if I have time to do it!
I mean, it adds extra time, so call it "free time stuff" - things you can do if you really have time or want to. It doesn't add anything to the project.

I found a class at work with over 150 member functions & 120 member variables!!! Worse yet, there was absolutely no documentation about what any of it does... So trying to modify it is a nightmare. Don't make the same mistake as they made, otherwise the developer that has to inherit your code will curse your name until the end of time.

I see that as a problem with the documentation. Obviously they didn't document it good enough! You could run into the same problem if the free functions weren't documented either!
The thing is... if they documented it properly, then that class would be easier to use than free functions (or at least for me), although modifying it might be another matter...

BTW Elysia, don't you ever sleep? I see you posting 24 hours a day!

I do sleep... But generally I do also have access to a computer where I go! It keeps me from getting bored

Originally Posted by citizen

std::basic string has like 107 member functions, maybe Elysia should use that. It recoded a bunch of algorithms as member functions, too. I think Elysia will be very happy with the decisions in the design.

I don't think so.
Std::string is one of the most unhelpful string classes I've seen. Replace is fatefully misnamed.
Find_first_of, for example, is also inappropriate named. It should be named more similarly to find_any_first_of or the like since it finds any of the characters in the string, not the entire phrase.
The replace function is misleading into believing it can search and replace a given occurrence of a string with another. Further, it does not reallocate or move data (I think?), so if you replace "Alice" with "Jonathan" you're going to overwrite data.
The std::replace is also flawed in that it can only replace single characters with another given character (if I remember this correctly). Who needs that? When I replace, I replace strings.
And std::string doesn't even have a char constructor, only for char*, so you'd have to convert your char into a string to pass it to the constructor or additionally construct the string and use insert.

This may not be 100% correct, but I'm not an expert at this yet.

I see that as a problem with the documentation. Obviously they didn't document it good enough! You could run into the same problem if the free functions weren't documented either!

I agree.

And std::string doesn't even have a char constructor, only for char*, so you'd have to convert your char into a string to pass it to the constructor or additionally construct the string and use insert.

Actually, one can use the constructor that takes a size and a char, and then just set the size to 1. Unfortunately, this is error prone if one mixes them up and sets the size to the char and the char to 1, like I did once

Ah, haven't found that one constructor. Though I suppose they could have been nice enough to add a constructor for only char, though.