Thread: Suggestions for extra features

  1. #1
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,737

    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

  2. #2
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,737
    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

  3. #3
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    955
    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).

  4. #4
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,737
    Quote Originally Posted by christop View Post
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. C++ future features?
    By Dave11 in forum C++ Programming
    Replies: 17
    Last Post: 10-23-2014, 10:23 PM
  2. Dependence on C++11 Features
    By Elkvis in forum General Discussions
    Replies: 2
    Last Post: 07-27-2012, 03:42 PM
  3. C++ IDE features
    By czy11421 in forum Tech Board
    Replies: 4
    Last Post: 09-11-2006, 06:48 AM
  4. ADT features
    By Mhk in forum C# Programming
    Replies: 0
    Last Post: 03-05-2002, 03:21 PM

Tags for this Thread