Giters

nayuki / QR-Code-generator

High-quality QR Code generator library in Java, TypeScript/JavaScript, Python, Rust, C++, C.

Home Page:https://www.nayuki.io/page/qr-code-generator-library

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

VBA port

wqweto opened this issue · comments

commented

https://github.com/wqweto/VbQRCodegen

I suppose these ports are pouring here already :-))

Can you put links in README to all other language ports being mentioned in the repo's issues so that people don't waste time duplicating effort?

commented

See https://www.nayuki.io/page/qr-code-generator-library#third-party-ports .

I won't endorse third-party ports in the GitHub source code where history is cloned and retained forever.

commented

I won't endorse third-party ports in the GitHub source code where history is cloned and retained forever.

Sure, it's your project w/ your rules. Just noticed some people took on porting to already existing languages but this probably was before you making the list of ports available on your website.

Btw, I did somewhat thorough review of the C implementation in master and found some nits if you care to share these in a PR? Not sure how current master is though, might be not worth it.

commented

Finally had a chance to process this. I added your project to the list on the aforementioned web page section.

Yes, people were porting my library years before I started that subtle section on the page. It's true that duplication of effort is an issue.

I see that you based your work on my C port, which is actually by far my own least favorite port because it uses manual memory management and terrible (but correct) arithmetic. I would like to hear about issues you found in my code; please open a new issue (or pull request) about that new topic.

commented

What nits did you find in my C library port? Thanks

commented

I'm sorry but it was quite some time ago I grokked your original codebase I've forgotten the details and don't have the time to return to this again.

There was nothing serious as far as I remember, just some small oddities (using both x % 8 style vs x & 7), and some repeated parts (e.g. qrcodegen_encodeText could use qrcodegen_makeBytes in final else part).

You can certainly close the issue now if you wish.

commented

small oddities (using both x % 8 style vs x & 7)

I chose to do it this way because x % 8 is clearer but x & 7 is faster at the CPU level. The former is executed once per QR Code, whereas the latter is executed once per module. Whether this is the best practice is a matter of opinion, though. I think the remainder form is clearer because substitution is easier - x % 8 == 0 means multiple of 8, x % 5 == 0 means multiple of 5 - but x & N == 0 requires N to be one less than a power of 2, and could be written as decimal like 1023 or in hexadecimal like 0x3FF.

some repeated parts (e.g. qrcodegen_encodeText could use qrcodegen_makeBytes in final else part)

I looked over my code again and the answer is no. qrcodegen_makeBytes() performs a memcpy() from uint8_t data[] to uint8_t buf[] which is okay. The final else case of qrcodegen_encodeText() numerically converts each element of char *text to uint8_t buf[]. I'm not 100% sure that copying bit patterns is totally safe and portable on every possible platform. For one, char could be signed or unsigned. I'm not sure if char can be wider than uint8_t, or if every uintN_t type must map onto a primitive type like char or it could be some extended type like __int8 (kind of like __int128). Also I'm not sure if type-punning char * to uint8_t * is kosher either. As C refuses to nail down these details and semantics, I chose to code very defensively and assume the worst.

For some background reading, see my Summary of C/C++ integer rules. Cheers.