namespace leftpad { enum Dirn { Left = 0, Right = 1, };
// generic pad // either left or right padding // `src` and `ret` are NULL-terminated // callee must delete[] `ret` template<typename T, Dirn W> // W = Left or Right T* pad(T* src, int n, T ch = (T)' ') { const size_t c = strlen(src); const size_t p = W * (c*sizeof(T)); const size_t sz = (c+n) * sizeof(T); T* ret = new T[sz]; for(size_t i = p; i < p+n; i++) { // fill `ch` ret[i] = ch; } for(size_t i = (W^Dirn::Right)*n, j = 0; j < (c*sizeof(T)); i++, j++) { ret[i] = src[j]; } ret[sz] = 0; return ret; }
void testPad() { const char* t = "Donald Trump 2016";
>>9 That was just version 1.0. You really can't blame the first version for having bugs. I'm planning to eventually release version 2.0 that actually builds.
Name:
Anonymous2016-03-24 14:37
>>13 You wouldn't have bugs if you been writing test driven clean code.
>>14 You wouldn't have bugs if you actually used your brain and thought before writing.
I'm not going to write the C version because it's so bloody simple in Asm. There's more lines of comments than code here. Allocate your own buffers and do the length-checking yourself. ; al pad char ; ecx pad length ; edi dest string ; esi source string ; edx source length leftpad: rep stosb mov ecx, edx rep movsb ret
char *leftpad(char *s, size_t s_len, size_t n, int c) { char *to;
to = malloc(n + s_len + 1); /* no overflow checking? */ if (to) { memset(to, c, n); memcpy(to + n, s, s_len + 1); } return to; }
Name:
L. A. Calculus!jYCj6s4P.g2016-04-02 1:22
IF DA SIZE OF DA STRING PLUS n IS GREATER THAN INT_MAX, UR NOT USING DA FUNCTION PROPERLY. PERIOD. DAT'S DA CALLING CONVENTION. IF U CALL DA FUNCTION PROPERLY, IT WILL WORK PROPERLY. DAT'S ALL DER IS TO IT. END OF FUCKING STORY.
Please avoid strlen
NO. GO FIND OUT WAT A STRING IS.
N WHAT IF n+s_len+1 OVERFLOWS IN UR EXAMPLE? U'VE WRITTEN PAST THE END OF DA STORAGE ALLOCATED BY malloc N UR PROGRAM'S BLOWN TO BITS.
SO UR CODE AIN'T PERFECT EITHER. U'VE FAILED AT BEING PEDANTIC. NOW GET DA FUCK OUTTA MY THRED, SAFETY MAN.
AND IF UR GONNA ARGUE DAT RELYING ON A SENSIBLE CALL IS BAD PRACTICE, CHEW ON DIS, BITCH:
leftpad("GO FUCK YASELF", 123421, 4932, 's'); /* FIX YOUR FUNCTION YA FUCKIN MORON. MY CALL DIDN'T WORK. */
CHECK FUCKIN MATE. NEXT VICTIM.
Name:
Anonymous2016-04-02 11:30
>>42 Cudder will laugh at you, not with you if you keep using strlen.
>>43,44,45 This is how those cargo cult "best practices" start. I wasn't saying "never use strlen", I was just saying use it when it makes sense and not when it doesn't. It didn't make sense to use strlenin that particular situation but that doesn't mean it doesn't make sense ever.
Now I feel like Dijkstra trying to explain how goto is not inherently bad...
None of these C solutions work with unicode right? Once again the UNIX-loving toilet scrubbers somehow manage to feel superior while taking a whole thread to create code that's worse than what a freshman pythonista would write in 5 minutes.
Name:
Anonymous2016-04-12 0:27
//prog.go package prog
func LeftPad(s string, l int, pad byte) string { diff := l - len(s) if diff <= 0 { return s }
b := make([]byte, l) for i := 0; i < diff; i++ { b[i] = pad } copy(b[diff:], s) return string(b) }
//prog_test.go package prog
import "testing"
func BenchmarkLeftPadHMA(b *testing.B) { for n := 0; n < b.N; n++ { LeftPad("hax my anus", 20, ' ') } }
$ go test -bench=. testing: warning: no tests to run PASS BenchmarkLeftPadHMA-8 10000000 124 ns/op ok _/C_/Users/progrider/code/go/prog 1.419s
>>61 If you don't want to spend your time supporting awful garbage because you want to interoperate with the rest of the world maybe you should consider a change of profession. Or you could become a lisper and spend all your time writing blog posts about how smart you are without ever writing any code at all.
>>69 Look at what the code is doing before posting anything, fucktard. That doesn't work in the general case but >>76 has it right.
Name:
Anonymous2016-04-16 17:12
Fine guys, but for real internationalization (not merely "UTF-8 support"):
- Make leftPad accept an arbitrary UTF-8 sequence to pad by - Truncate the pad sequence only at UTF-8 codepoint boundaries (don't split multibyte characters) - Truncate the pad sequence at a locale-appropriate character boundary as determined by http://www.unicode.org/reports/tr29/
Enough of your broken toy programs, just admit defeat and use an ICU library
Name:
Anonymous2016-04-16 21:11
There are some fundamentally difficult and/or complex problems to completely solve in computing, and all of your little "optimized" shortcut shit is nothing more than that: Shit!
- Date & time processing - Text handling - Caching - Calculating the weight of Cudder's mom
An inherit its overhead and vulnerabilities for something as simple as this? No thanks.
>>80 Take a step away from enterprise and a step towards purity.
>>81 UTF-8 is the only worthy encoding. I suppose you think all programs should be equipped with image recognition so they can read ancient egyptian inscriptions on walls as well.
your programs should know how to work with any kind of encoding.
God, no. There's no advantage to perpetuating a bunch of shitty ancient code pages and other defective text encodings.
Most programs should accept only UTF-8 and emit only UTF-8. In the odd case where you need to accept non-UTF8 input, force the client to specify the encoding - don't autodetect.
>>83 Who said anything about autodetect? For the case >>79 was talking about you do not need to even know the encoding.
Name:
Anonymous2016-04-18 8:00
>>83 Fuck you. I do a lot of imaging old software & docs, and systems should have knowledge of all the shitty old encodings for when you need them. It's not like they take any considerable space or slow anything down.
All you backwards fucknuts need to have the machine fucking working for you, instead of trying to let the machine off the hook for complex cases. Are you dickheads are afraid of computing? This is what computers are for!
>>89 To everyone who is bothered by them, so everyone.
Name:
Anonymous2016-04-24 5:08
>>90 The rest of the world is bothered by you, so now what?
Kill yourself!
Name:
Anonymous2016-04-26 2:36
>>83 Elitist pricks. The whole world doesn't revolve around your UTF-8 narcissism, if anything forcing it leaves for less compatibility which is precisely what I'm paying you for, programmer boy
Name:
Anonymous2016-04-26 23:29
>>92 Compatibility with inferior solutions is not an advantage. The herd must be culled.
>>92 Do we really have a rockstar manager on our /prog/?
Name:
Anonymous2016-05-01 6:08
>>93 Are you going to go through all the files of humanity and convert the non-UTF-8 ones? Are you going to force people to use external converter applications to bring them in? Just support the fucking encodings. They're tiny to include.
Name:
Anonymous2016-05-01 14:08
Are you going to force people to use external converter applications to bring them in?
Yes, because they shouldn't have used those encodings to begin with.
Name:
Anonymous2016-05-02 7:04
>>97 And in 30 years, whatever has readily supplanted UTF-8 will say you shouldn't have used UTF-8 to begin with. Go fuck yourself.
Name:
Anonymous2016-05-03 0:04
>>98 Won't happen. UTF-8 is good enough for everyone, even if every emoji codepoint comes in 10 flavors.
>>99 The problem is not Unicode's ability to hold this many codepoints. It's a great advantage indeed.
The problem is complexity of the standard itself. There's more to it than mapping values to characters. And even that got its flaws in the implementation.
For example combining characters, "ö" vs. "ö", U+006F U+0308 vs. U+00F6. On top of that, all the UAX'es: Unicode Bidirectional Algorithm, East Asian Width, Unicode Line Breaking Algorithm, Unicode Normalization Forms and more. And these are all part of the standard, I'm not including "Unicode Technical Standards" with which software does not have to be conformant, to implement Unicode. Good luck parsing and implementing all quirks of Unicode.
Given that, emojis are just a minor problem.
Name:
Anonymous2016-05-04 1:27
>>101 Granted, the Unicode spec is complex. But you can use UTF-8 as an encoding without having to worry about most of the additional technical standards. I mean, you should probably at least normalize input when saving it to a persistent store, but hell - you can just ignore it and fail hard on all kinds of foreign language edge cases like all American software. UTF-8 don't care.
Name:
Anonymous2016-05-04 15:31
>>102 Until you try to get the length of a string, or try to equate strings.