Get all section names from an ini file

GetPrivateProfileSectionNames: http://msdn.microsoft.com/en-us/library/ms724352(VS.85).aspx

Why you don't want to take any ini-file parser from the internet?
http://www.codeguru.com/cpp/w-p/files/inifiles/article.php/c4455

http://www.codeproject.com/KB/cpp/CIniFile.aspx

http://www.codeproject.com/KB/cpp/IniReader.aspx

When i use the code above i only get the first section. How to enumerate them?

char buf[64];
GetPrivateProfileSectionNames(buf ,64, "c:\\test.ini");
cout << buf << endl;

                                              

1:
2:
3:

All the section names are terminated with a '\0'. So if you print the buffer you get only the first. The last name is terminated with two '\0';

for example ( two sections, "FIRST" and "LAST"):

buf[0] = 'F'
buf[1] = 'I'
buf[2] = 'R'
buf[3] = 'S'
buf[4] = 'T'
buf[5] = 0  <----- 1 terminator
buf[6] = 'L'
buf[7] = 'A'
buf[8] = 'S'
buf[9] = 'T'
buf[10] = 0 <----
buf[11] = 0  <----- 2 terminators

Can you give me a snippet how to get both names?

:)
So, I'd say, this API is very old and better use something else.
It is "only for compatibility with 16-bit Windows-based applications".

>>>> So, I'd say, this API is very old and better use something else.
It is older than 17 years. That was when I started with VC1.1 at Windows 3.1. But most functions of WINAPI have the same age. And the method to return a list of strings whithin one string separated by single zero chars and a final double zero was used in many other WINAPI functions as well, e. g. the filenames selected when using OpenFileDialog were returned same way.  BTW, you can use the strtok function to parse such kind of buffer.

   char* p = strtok(s, "\0");
   do
   {
       cout << p << endl;
       p = strtok(p + strlen(p) + 1, "\0");
   }
   while (p != NULL);

what is the way MFC source code is parsing such kind of 'dynamic string arrays'.

I don't think that a younger API necessarily was better? I myself made a inifile class in a portable project where they already had a inifile class which was poorly bad. In OS/2 they had a infile class where the maximum entry length was limited to 100 chars. Also the entries per section were limited. None of those classes had a function to retrieve all sections or all entries of a given section.
 
>>>> It is "only for compatibility with 16-bit Windows-based applications".
No. It is part of WINAPI and was used in the youngest versions of VC as well. The only point is that nowadays projects probably would use XML files rather than inifiles. But even that must not really be an advantage.

>>>> It is "only for compatibility with 16-bit Windows-based applications"

In my opinion this sentence was written in MSDN in the past, when Windows 95 was released; at that time Microsoft tought that all applications should put their configuration data in the system registry. As we learn some years later, system registry is not a good solution for all kind of informations (COM teach...)... a separate private file is often better!

Sure, as itsmeandnobodyelse said, may be that XML is more modern and powerfull, but for simple application configuration, INI files are still a convenient, and often easy (to read, write...) way to go.

Yes, you're right. But I took "only for compatibility with 16-bit Windows-based applications" from MSDN.
How I remember in 2000 this API (or only MFC?) worked only with 16K ini-file.
Everybody has own ini-file, xml-parser, ...
I'd say, sometimes it is even dangerous - I just continue with your idea. These "home-made" parsers should be at least faster than their standard implementations. And use less memory.
I have to use "home-made" implementations, because I do a lot of work for the windows mobile/CE devices. So when you say, for example, to try to avoid the pointers... I cannot. I have only 32MB per process.
To make this comment more related to the question :), i will say that I hope that strlen is faster then strtok. Also you call strtop more often then I did in my "strlen" example.  And, anyway, you use strlen. :)
Funny discussion about a very simple question. Nice to talk with you. Thanks.

>>>> all applications should put their configuration data in the system registry
They did both. You could have your inifile in registry and/or as a file on the disk. Win.ini and system.ini still are in registry (and still working as they did in Win3.1 in many options). I could bet that putting a win.ini to windows folder would override the settings which are in registry.

The question was:  how can i enumerate all sections from an ini file.
Accepted solution (ID:25240853) does not contain any word about it.

Are you sure? The code was partial, but this is the mos inportana part....
Here is the code  im using:

	char IniPath[] = "c:\\test.ini";
	char SectionBuffer[256];
	vector<string> Sections;
	int l = 0;
	int nSize = 256;
 
	GetPrivateProfileSectionNames(SectionBuffer, 256, IniPath);
	for (int i = 0; i < nSize; ++i)
	{
	    if (SectionBuffer[i] == '\0')
	    {
	        if (i > l)
	        {
	            string s = &SectionBuffer[l];
	            Sections.push_back(s);
	        }
	        else if (i == l)  // 2 zeros detected
	            break;
	        l = i+1;
	    }
	}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:

No. The code is good. But you asked other things.
You need to mark the right answer. In the best case the post you marked as the accepted solution can be the assist.
Full answer is ID:25240817. Here is the code that takes the section names from your ini-file. That's what you asked.