Thread: Suggestions for extra features

Here's an example of an extra feature I built into my version of printf:

Code:

			pawPrintf
			(
				L"%80lc\n%|80ls\n%80lc\n",
				L'=', L"Draw Loop", L'='
			);

Output:

Code:

================================================================================
                                    Draw Loop
================================================================================

I'm also planning to add time specifiers, I also have a binary specifier, modifiers for UTF-8, UTF-16, UTF-32, TCHAR & whatever happens to be the biggest character type on the system (in this case UTF-32)

Are there any other suggestions people would like to have added to my printf, I'm planning it to be part of a optional library for a cross-platform, cross-distro solution to making apps, because of the design hinging on the PATH & related variables it also works as a solution to "supporting" flatpack snaps etc with just instance of the app, they would just launch the paw version under the hood and let paw map in the directories containing what libraries & binaries it is looking for, not just system wide binaries & libraries but also app specific and even debug & timed variants, these are the way they would be mapped in before the main executable is launched:

paw [--dev=dir] --start[=arch,ext(exe,AppImage,etc)] command
paw [--dev=dir] --debug[=arch,ext(exe,AppImage,etc)] command
paw [--dev=dir] --timed[=arch,ext(exe,AppImage,etc)] command

In all cases the binaries & libraries for the --start command will be mapped in just before the native executables, this has the side effect of built-in portability (provided there's no hard system dependencies made by the app & it's own libs, the paw library is going to be a optional solution to that issue) & the debug/timed libraries will be mapped in before that if they're requested, there won't be a need to differentiate the names of the binaries libraries either since that is already solved by the PATH etc variables having the paw directories mapped in, that should simplify makefiles etc too since the job of sorting out the directories. The --dev option is for non-installed development builds so it's easier to utilise paw for that also

Is it really the case that no-one has any suggestions or features they would want in a new library's version of printf? This is planned to be a be-all end-all solution to cross-platform development, even flatpak, snaps etc could make use of it under the hood to enable users to continue using them while also getting a consistent experience of the same app in any platform/packaging option, the only possible points of inconsistency would be hardware and any native stuff like what memory info is list-able for processes etc. I really want this 1st iteration be excellent enough that it draws plenty of interest, it's not expected to be perfect but close enough that both companies & small time developers alike would migrate to it over time as their main development branch

Originally Posted by christop

My only suggestion is not to change the meaning of existing format strings, which can be surprising to people who are already familiar with printf. I would add a new sub-specifier like "/n" (or some other character besides "/"), where n is the number of times to repeat, so the format would look like "%/80lc" to mean "repeat 80 times".

This can be combined with the other sub-specifiers like "%100/80lc" which means repeat the character 80 times and right justify it in a field 100 characters wide (i.e., 20 spaces followed by 80 equal signs).

Nice, didn't think of that, relatively easy to do also, not sure if / is the best way to represent that option though, what do you think of using ^ instead? most a familiar with that being used in math as a power of operator, not too much of a stretch to associate with repeat argument as well