Thread: Though implementation problem

I don't like the idea to be limited to one paradigm either. I use them as I see fit. However, to these kind of things, classes are best IMHO. All functionality for an object to be grouped inside its object and not broken out.
Why is it so difficult to learn C++ and not VB or Java (unsure about this one) or such languages, I wonder? Because everything is neatly organized into one place.
If a programmer has to rely on algorithms to get things done (and I mean simple tasks), or go browse through a namespace that's not named in the docs, things DO get harder.

Difficulty is what I try to avoid. No wonder C++ is difficult to learn.

And some don't seem to understand my point either...
Classes, like functions, can be extended. It's your job to make sure they can be. They should be. Otherwise you did something wrong.

One class should be one thing. Don't add everything into it. But a string class should have certain things, such as ToLower/ToUpper, which the standard library seem to lack.
Classes can grow just as free functions can grow. Now, the problem is to find a way to make it possible for the classes to grow similar to free functions.

I don't think I'd use static members, though. They would appear inside the class namespace. I'd rather make them free and move them into the Strings namespace... Neatly organized.

Perhaps another question is: how do I break out the implementation from the definition of a specialized template?

Instead of:

Code:

	template<> class StrConversion<wchar_t>
	{
	public:
		CStringExA ToANSI() { /*... */ }

	private:
		virtual const wchar_t* GetData() = 0;
	};

This:

Code:

	template<> class StrConversion<wchar_t>
	{
	public:
		CStringExA ToANSI();

	private:
		virtual const wchar_t* GetData() = 0;
	};

	template<> CStringExA strConversion<wchar_t>::ToANSI() { /* ... */ }

I don't like the idea to be limited to one paradigm either. I use them as I see fit. However, to these kind of things, classes are best IMHO. All functionality for an object to be grouped inside its object and not broken out.
Why is it so difficult to learn C++ and not VB or Java (unsure about this one) or such languages, I wonder? Because everything is neatly organized into one place.
If a programmer has to rely on algorithms to get things done (and I mean simple tasks), or go browse through a namespace that's not named in the docs, things DO get harder.

I don't I'd use static members, though. They would appear inside the class namespace. I'd rather make them free and move them into the Strings namespace... Neatly organized.

That sounds like a contradiction: you claimed that it is difficult to learn C++ because things are not neatly organized, then you claimed that the use of a C++ namespace can make things neatly organised.

So, what's wrong with placing your free functions in an appropriate namespace? After all, they will be neatly organised, and you cited organisation as a reason for wanting to use classes instead of free functions.

Originally Posted by laserlight

That sounds like a contradiction: you claimed that it is difficult to learn C++ because things are not neatly organized, then you claimed that the use of a C++ namespace can make things neatly organised.

Yes, things are split apart. You must know where to look for it. This is the difficult part. It's better if all the functions for, for example, strings were just located inside one class. Then you wouldn't have to look for a namespace where those free functions are stored.
I mean, have you had a look at MSDN? Sure, it documents std::string, but nothing of the free functions or algorithms you want to use to use it better.
Easy to use, then, if you haven't been taught properly? Hardly.

So, what's wrong with placing your free functions in an appropriate namespace? After all, they will be neatly organised, and you cited organisation as a reason for wanting to use classes instead of free functions.

Yeah, but classes are simply more organized and makes it easier.
Otherwise you will put half in a class and half in a namespace, which makes it disorganized.
Or if you put everything in the namespace, we're back to plain C.

Originally Posted by brewbuck

By making ToANSI() a member function you are making the artificial statement that only a String has the business of converting characters from one character set to another. But what if you only had a single character, not a whole string, and you wanted to convert just that single character?

Is any of this getting through?

From what I'm gathering, you seem to think that we're at the mercy of the ToANSI function to convert the string.
I don't think so. It is necessary to provide options for manually processing the string. That means, that if you don't like what the class can offer, you can extract the data and process it yourself. This is evident by the GetBuffer function where you can get the data, run it through an algorithm and put it back.

I go by the design to not limit choices mostly. The class can be a convenience. But it shouldn't limit functionality because of it. If you need power, or more flexibility or want to do something with it, then you must be allowed to do so.

But perhaps a member function that converts a range isn't that bad either. It's convenience. The class does in no refuse to loan its data. But you can ask for permission to do so by asking nicely.

And how exactly does it help if ToANSI was free? It would still convert the whole string.

Ah, so you're basically after a sort of general function that convert an infinite number of string types to ansi.
A free function could be a boon for you, and for those only looking in the class, the member function could also be a boon, so they both have their purposes. Sure, I could make a free function, too, but it is general and have nothing to do with the actual class (since I'm guessing a general function must abstract away the type passed as an argument).

How many hundreds of those free functions that does the same would then exist?
Let's see the member as convenience and the free one as a better solution, so as to get rid of the need to make a new member function for every class.

And if newbies could have have found appropriate functions and solutions more easily...?
I dare say that if std::string was more OOP, it would have been far greater to use for me. It requires a lot of education to use it properly the way it is.

Originally Posted by brewbuck

No. I'm after a function that converts A SINGLE CHARACTER from one character set to another. Once you have that, your two implementations in the two classes become much smaller and the code duplication goes away.

Which again leads to the problem of algorithms. Clunky, bad looking and annoying.
Again, you're relying on tedious algorithms and a lot, think, bloated code to reduce the amount of code that goes into classes and/or functions.

I suppose we have your attitude to thank for that made the standard library into what it was today. A disorganized, hard-to-use library that takes several lines to do something easy.

You seem to sacrifice everything for less code.

And your sample is not unlike what I figured you were after. A generic function to perform an action on an undefined amount of types, regardless of its interface.
I do not doubt it is a good thing. It is. But it doesn't exactly make the code "beautiful" or whatever to call it. If I'd put wrappers to those functions for higher-level functions, then everything would become oh-so-much better.
Your code approach reminds me of Win32 API and C. Complicated crap with 20 lines to do one thing when it could be done with maybe 1, 2 lines.

It's funny how you agree now. Functions that are generic and can do a lot of things are good. Very good. You agree.
Yet for my classes, I'd rather write high-level wrappers and put them as members. The members are merely wrappers for the generic function. You agree wrappers are good.

To further add, I have never been against algorithms or powerful functions such as a generic one as you show, but the problem comes when you must use those in your code instead of higher level wrappers for simple functionality.
Should I need to do something that isn't/wasn't available, I'd write another high-level function for what I need to wraps an algorithm to do it.

This goes back to the original problem... Is it possible to write a wrapper member function for specialized types of the string class? One for UTF16 to ANSI for the wchar_t specialization and one ANSI to UTF16 for the char version. Having a UTF16 member function for wchar_t wouldn't make any sense since I can't convert UTF16 to UTF16.

Yes, things are split apart. You must know where to look for it. This is the difficult part. It's better if all the functions for, for example, strings were just located inside one class. Then you wouldn't have to look for a namespace where those free functions are stored.
I mean, have you had a look at MSDN? Sure, it documents std::string, but nothing of the free functions or algorithms you want to use to use it better.
Easy to use, then, if you haven't been taught properly? Hardly.

That is a documentation problem, not a design problem.

Yeah, but classes are simply more organized and makes it easier.
Otherwise you will put half in a class and half in a namespace, which makes it disorganized.
Or if you put everything in the namespace, we're back to plain C.

I think that the correct approach is to put everything in the namespace, unless you want to emphasize the separation from the core interface of the class. Obviously, we are not back to plain C since the namespace mechanism is at work to avoid name collision.

I dare say that if std::string was more OOP, it would have been far greater to use for me. It requires a lot of education to use it properly the way it is.

So you would rather that std::string be a polymorphic base class? OOP really is about abstraction, encapsulation, inheritance and polymorphism via objects. OOP is not about classes and whether functions are member functions, static member functions, or non-member functions.

If I'd put wrappers to those functions for higher-level functions, then everything would become oh-so-much better.

I think that is what you should do: provide wrappers to wrap the application of a generic algorithm to provide specific functionality that can be more easily used. That way, clients can enjoy both the flexibility of the generic algorithm and the quick access to the specific functionality. I believe this has been mentioned before.

EDIT:
Oh, and if the application of a generic algorithm would be inefficient, only then would you provide an efficient implementation, possibly by providing a member function instead. An example of this would be std::sort versus std::list::sort.