INI file wrapper

[czerny]

This is a small wrapper to ini files. It supports UNICODE.
In case you use UNICODE, there is a starting section

Code: [Select]

[Encoding]
Type=Unicode

[DMac]

I was just working on another version of this!
I'll put mine up here too, for what it's worth.

[Attachment Version 2] Fixed quick and dirty demo to support UNICODE]

[Attachment Version 3, 01-16-2015] Employed The Anonymous Data Type code pattern suggested by Czerny and documented the code.

[czerny]

Hi DMac,

you have used the T-types in your variables and functions. But the project doesn't compile as a unicode project?

Another question:

Why do you cast a LPINSTANCE to a LPINIFILE? Why not use a LPINIFILE directly?

[DMac]

Hello czerny,

you have used the T-types in your variables and functions. But the project doesn't compile as a unicode project?

The demo was a quick and dirty project I am using to develop the wrapper.  I converted it to generics and updated the wrapper so now it works as intended.

Why do you cast a LPINSTANCE to a LPINIFILE? Why not use a LPINIFILE directly?

LPINIFILE is the public pointer.  In this case there are no useful public members so it is just a handle  (INIFILE is the head of INSTANCE).  The LPINSTANCE pointer then provides the offsets to the entire actual heap allocated private storage.  What I am doing here is implementing a type of object oriented encapsulation.  This pattern then necessitates the use of a factory method New_IniFile() to create the objects.  And the destructor IniFile_Destroy() to release them.

This halfway to C++ approach fits well with my actual target project.

[czerny]

Why do you cast a LPINSTANCE to a LPINIFILE? Why not use a LPINIFILE directly?

LPINIFILE is the public pointer.  In this case there are no useful public members so it is just a handle  (INIFILE is the head of INSTANCE).  The LPINSTANCE pointer then provides the offsets to the entire actual heap allocated private storage.  What I am doing here is implementing a type of object oriented encapsulation.  This pattern then necessitates the use of a factory method New_IniFile() to create the objects.  And the destructor IniFile_Destroy() to release them.

This halfway to C++ approach fits well with my actual target project.

Yes, but why do you use two pointers. One is enough! See my adt-example on the wiki.

[DMac]

czerny,

That's a nice example.  I never really thought about it that way; and in this case, it makes sense to implement this strategy.

Now let's suppose that you wanted some public fields visible to the user as well as the  private  ones.  Could you do it with just one struct?  If so how?

[czerny]

You are right, that makes the whole thing more complicate. But you can do the following: see attachment.
I use two structs here but have not to cast.

I have not found a good reason to use public vars. There is only little overhead to write a set.. and get.. methodes and you can do some range checks and so on. The existance of the object pointer can tested this way too.
But I agree with you. In such cases it might be simpler to cast.

[DMac]

I just looked at this example and it is essentially what I came up with for an object in my current project.  The difference though (and my use of a cast) is that the private portion cannot be accessed or inferred from the public portion.  I (ab)used the design pattern that windows uses for the WM_NOTIFY message's public header (common to all messages) as the first member of a private structure.

I agree that proper encapsulation of code would use the anonymous data type with getters and setters for the public portions.

In fact, as I considered this I couldn't come up with any other way of doing it myself.

[DMac]

Just updated and documented my contribution here based on the suggestions from this forum.

Thanks czerny and Timo.