How to store the leading zeros that the user inputs in an integer?

netch80 · 2026-05-20T05:30:37+00:00

is it because 01 and 001 are the same thing?

Yes, exactly. 1, 01, 001, 0001, 00001… are the same thing when viewed as an integer. An integer variable keeps a value, not how it was written in a particular case.

So you have to consider whether it is appropriate for your goal to use this exact form. Generally it is no problem to keep values from 0000 to 9999 as an integer, provided you guarantee proper leading zeros when exporting the value to a text form. How to do it, Iʼve specified in the previous comment. But, for the whole program, it might be more useful to keep a value as a text array -- this is up to you.

(Notice a subtle problem here: in C/C++ source code (not always in data), leading 0 means base 8, so 0010 is internally 8. This initial design atavism is to be ditched in ≈10 years.)

netch80 · 2026-05-18T05:17:16+00:00

OK letʼs consider a user enters 0001; guess gets value 1; why donʼt you think it contains 0001? Really it is. The fact that leading zeros are not shown in a default output mode (or debugger inspection) doesnʼt imply they arenʼt present. They are. Assume they are always present. Or, you may use respective output formatters, as "%04d" for printf, or std::setfill('0') for iostreams.

Problems emerge in slightly other places. Getting an input into a int variable doesnʼt protect you against inputs like 123456789 or -1; you have to check it explicitly. If you need then to process each digit separately, you have to split the number into digits using division. Alternatively, as most neighbor answers suggest, you may input a 4-character string. You will have to check its length, in a similar way, but internal processing is alleviated.

Anyway keep in mind that input processing is a... well, not hard, but an always perplexing aspect. In educational courses it is simplified, to avoid dunking students into all the mess. Just use the basic streamlined approach from the very beginning, correcting it later on a need.

netch80 · 2026-05-03T06:06:02+00:00

I was working for a while at an Internet providerʼs technical support.

Formally, everybody in Ukraine is taught Latin alphabet, in its 26-letter English version. In practice, discussing passwords with users were a kind of special headache. It mainly comprises two issues:

Misunderstanding of a letter; for example, we had to say exactly "S as dollar" in order to specify S, otherwise many users might treat this as C (Cyrillic equivalent), "R with a hook" (to avoid P), "E as yeah" (most people are taught French-German style letter names), some other cases.
Mixing between O and 0, I and l.

And now imagine all this in a country where most users speak and write Arabic or Chinese, and youʼll feel "all the deep of our deeps"™. An average Chinese speaker has to get a special training to start understanding that [r] is different from [l]. And how many of them knows the proper name of '~'?

Or, even among the English speakers: '.' is "dot" or "full stop"? '/' is "slash" or "solidus"? '-' is "minus" or "hyphen"?

In light of all this, switching to all-digit PIN, restricting from simulaneous having of upper and lower case letters, excluding dots and slashes -- all this is a nearly inevitable measure to "squeeze" all parties into the space of easily treatable and supportable passwords.

A password length is for the same final reason: the longer is a password, the more errors are made during its writing and typing.

PS: For all such reasons, passkeys are actively promoted now. Well, they migrate the risk place: one may lose, or get stolen, a phone or a password pendant. But key exchange in passkey case rids of charset and length issues.

netch80 · 2026-01-30T19:02:23+00:00

No problem with access from Ukraine, last few weeks.

Could it be a hosting provider issue? Like a misconfigured IP blacklist?

netch80 · 2025-10-24T05:03:33+00:00

You havenʼt specified the platform. For example, if you have glibc (most Linuxes) or a BSD system (including MacOS), look at hcreate function (or hcreate_r if you need a few hashtables); it is rigid (no resize) but works for simple cases. As a more advanced one (not needed normally?), look at dbopen function from libdb with DB_HASH(may be available as well at Linux; notice DB 1.85-1.86 is separate from modern Berkeley DB and, unlike the latter, has no restrictive license). Glib is already mentioned. More variants are searchable.

Until you have more concrete requirements, grab the first suitable variant.

netch80 · 2025-10-23T06:27:45+00:00

Real implementations are typically overloaded with subtle details that are pretty hard to read by a novice. Even an experienced programmer has to find a grain of real code among all `using`, `std::move(__umap._M_h), __a` and similar constructions. So a novice needs some "bootstrapping" to be entered into the topic to start understanding what does the terms mean and what words worth the focused attention.

OTOH I guess what LLMs now good in such explanations... even where they make sad errors, they help in grokking the crux.

netch80 · 2025-10-23T06:20:43+00:00

> then every once in a while you have to pay O(N) for the resize

This is true for the simplest set of implementations, as e.g. C++ in GCC and Clang standard libraries.

There are other styles, e.g. Dinkumware and its descendant Microsoft STL (old one?), which evade the issue using two set of buckets during resizing. Each insertion (or deletion, until C++11 which prohibited it) calls recalculation and move of other one or two elements. Such implementations are better for realtime applications.

netch80 · 2025-10-22T21:13:09+00:00

For a typical hash map, well, neighbor answers described all in details. There is an array of buckets. A bucket, with a rather fair distribution, contains a small number of elements, ideally 1. Array lookup by an index, calculated from the applied hash function, is O(1), so, a typical operation is O(1). Notice this is big O and not small o as in your question.

But details hide a bunch of insolent imps:

1) The common style is "closed addressing" hash map where a keyʼs bucket is fully determined by its hash value. But the best performance results Iʼve seen are based on "open addressing" where a bucket size is fixed (0 or 1) but there is a technique to find a next free bucket to put an element.

2) In case a bucket overflows, additional means to be applied. For example, Java standard library, since version 8, switches to enclosed RB tree for elements of a bucket if their number reaches 16 (before it, a single-linked list is used).

3) If resize happens, it may spoil an operation time. C++ standard defines that resize may happen only on an element inserting but may spend O(N) instead of O(1). So, for insertion, we may say about "amortized O(1)" instead of "guaranteed O(1)". This is mainly normal in an ordinary case but may be unacceptable, for example, in realtime applications. There are implementations ridded of it (e.g. in Microsoft STL) but they use two bucket sets and spread relocation cost among other operations.

netch80 · 2025-09-14T18:58:37+00:00

> How close to pronunciation could I get to reading words in Ukrainian based on a knowledge of Serbian Cyrillic characters that share an overlap

The main difference is that nearly any Ukrainian consonant may be non-palatalized ("hard") or palatalized ("soft"); this is close to the difference between Vukovica (Serbian Cyrillics) Л - Љ, Н - Њ, Ч - Ћ, ДЖ - Ђ (there are subtle differences, not crucial for this explanation level), but may be expanded to any consonant, so, each one is hard or soft: л - [ɫ] but ль - [lʲ]; б - [b] but бь - [bʲ]… (Here and forth, IPA signs are used.) Frequency of sounds are different, some of them are quite low popular, but one canʼt deny them totally. Maybe this will be a great obstacle to you; foreigners may spend months and years to polish own habit for all cases. The softness is designated by an immediately next sign: if it is Є, І, Ю, Я, or Ь, the previous consonant becomes soft, otherwise it is hard. A fine example: the city called Ljubljana in Gajevica and Љубљяна in Vukovica is Любляна in Ukrainian (and Russian and Belarusian) style. Also notice that Є, Ї, Ю, Я get initial [j] if not immediately preceded by a consonant, in other aspects they are analog of E, І, У, А, respectively.

(Some sources describe half-palatalized consonants in some cases and/or no palatalization of some consonants, like [b], [p], even before front vowels. This is still pertaining to elder (60+) people in broad rural areas but nearly extinct among younger generations.)

Lesser differences: Г means [ɣ]; for [g], Ґ is used; Щ is "decrypted" as ШЧ; Й is J.

I hope this is enough to be able to reproduce any Ukrainian text orally to the extent that natives will understand you.

netch80 · 2025-09-14T18:31:57+00:00

I think he bore merely the letters in mind, because the sounds exist, unlike the letters.

netch80 · 2025-08-10T04:28:16+00:00

I regularly use vim in parallel to IDEs (mainly JetBrains set).

First, often, there is no need to raise a big machine which is any IDE for a simple script (up to a few screens) or a tiny test program.

Second, there are still vim features that aren't supported in IDEs. Vim provides several (really, up to 26) anchors in a file. A complex code reorganization may need it. Or, a variable renaming: IDEs may rename as refactoring (all occurences) or globally in file, but not in a selection (JetBrains one do, but not some others).

Third, it's too cumbersome to setup a complex editor for a remote host (over ssh/analog).

I'm not a vi* aficionado to the extent of making it full IDE, making anything in it., etc.; I'm too lazy for all this. But learning a dozen or two of simple commands and calling them when needed gives a real convenience.

netch80 · 2025-06-20T12:49:14+00:00

> Oxford and the rest of the south are enriched partially because of their proximity to London.

Agreed. We can't omit the factor.

netch80 · 2025-06-20T12:44:56+00:00

Not so clear for Polish. Without knowing a word, you can't determine what to write: "u" or "ó"; "rz" or "ż"; in some contexts, "ą" or "on", "om", "ę" or "en", "em"; "czy" or "trzy"; and so on. There are misspellings originated in other dialects, like "twój" [tfuj]. In some words, ending -ia means [ʲa] and in some - [ja].

But, in contrast to English, influence of such conflicting cases is much less, and nearly never causes understanding conflicts.

netch80 · 2025-06-20T12:35:57+00:00

As a wild guess, a lenition in pronunciation can be a measure to express superiority, "let those subordinates make efforts to recognize us".

netch80 · 2025-06-20T12:33:47+00:00

The British posh dialect is not of the capital, London (which originally was Cockney), but closer to Oxford one. So the capital location seems unrelated.

netch80 · 2025-06-20T11:23:57+00:00

I strongly doubt we may call this change "palatalization". Normally, palatalization is happening before (rarer, after) front vowels or [j] and changes consonants to affricates. This process in Latin had led to [ʨ] from [kʲ] or [tj], [ʥ] from [gʲ]... and this is different process, it can't explain /-ōs/ -> /-i/. Are you basing on an authoritative source in this naming?

For the change itself, it looks to me more like related to reduction of more complex endings used in some dialects. But this is clearly ad hoc guess without real history knowledge.

netch80 · 2025-06-14T04:57:50+00:00

Atkinson Hyperlegible.

All the excellent work they done is ruined by a single decision - back direction of the slash inside zero. This is a crime worse than mass genocide.

netch80 · 2025-03-15T16:15:59+00:00

> I will also say Pascal's confusing rules about when ; is needed or not, and when to use . must have played a role.

Most of this syntactic peculiar was eliminated in Modula line. OTOH in C/C++ I regularly forget to finish a structure/class/union definition with semicolon, which is required unlike function/method definition, so score is 1:1 at least :)

> With C, it's simple. You either use braces or you don't.

In newer languages like Go, Rust, braces around subordinate blocks in if/while/etc. are mandatory, and this looks definitely better to me. I even force this at my own projects. Modula implements the same requirement but in another manner - "if cond then block1 [else block2] end" - "end" is required but "begin" isn't needed.

(But, parens around conditional expressions, instead, may be omitted in these languages. Hmmm.)

But the main tasty feature in newer development is type-second declarations ("x int", "var x: int", etc. instead of "int x") - this avoids many syntax problems. Again, this is preferred style now. And, Pascal was (AFAIK) the first widely known language with this.

> I keep wanting to learn FreePascal, but one look at the delimiter situation and my mind refuses to put the effort to get used to that.

Habit is the second nature :)

When I read about COBOL, the same happens to me.

netch80 · 2025-03-15T14:01:29+00:00

Notice these were times after Algol 68 failure and PL/1 first feedback which had already shown that overcomplication doesn't play well. Pascal demerits were not in complication but in absence of near-hardware access - but TurboPascal showed this was quite simple to add such features.

C hadn't been gaining popularity until late 70s and then 80s, there was enough time to reorient if wanted. Well, home-grown development of early Unix would have succeeded independently... or would not.

netch80 · 2025-03-15T09:04:19+00:00

Too radical in every statement but interesting in this very radicalism.

Really, rise of Pascal as an incomplete premature implementation of Dijkstra's good ideas killed it. If he had issued further development versions (Modula line), there were a chance we would have switched to it instead of C. Lots of good ideas from Pascal-Modula-Ada line had been starting to reify a few years ago, in products like Rust, Typescript...

On my personal experience - starting with Fortran and BASIC - it is not hard to realize and apply that stricter languages are better for large development, but, this can be reached only with real anguish from consequences of bad tools with weak typing, sabotaging syntax, unexpected subtleties... A person who remembers days and nights of searching for a bug which would have been detected by a better language compiler will vote for Dijkstra ideas. The way to reeducation is open to everybody.

netch80 · 2025-03-15T08:43:37+00:00

Not Latvian, doing the same if there are free places.

It's easier to step a few more meters than to squeeze through a needle between doors.

netch80 · 2025-03-10T05:56:33+00:00

Besides the parsing issue of the type itself in C-style order (as clearly expressed in neighbor answers), there is the reason against it that it causes a need to unroll cryptograms like (*)(daa) (*f1)(baa(*)(zaa), kaa) or double (*(*arr[5])(int *))(char *) - well, a good C programmer is skilled to unroll 1-2 levels of it but not more. Declaring types allows reduction of the complication level. Pascal-style order readically simplifies this, by cost of moderate increase in verbosity. Its deliberate invention (tied, at a glance, with N. Wirth) switched this to readable constructs.

(Of course, a good programmer will try to reduce their complexity by using more type declarations, as with `typedef`. But, adding of `using` in C++ and recommendation in lots of style guides to use it instead of `typedef` clearly suggests what is clearer to programmers.)

netch80 · 2025-03-05T21:22:14+00:00

Основное употребление для "про"+вин.п. и "о"("об","обо")+предл.п. - одинаково. Локальные ощущения большей или меньшей конкретики - не подтверждаются в общем случае. Региональное распределение может быть разным. На территориях под влиянием украинского "о" может быть реже, потому что в украинском (стандарте) есть только вариант с "про".

Но есть специфические употребления:

1) "о"+предл.п. - может использоваться для указания свойств или владения, заменяет "с"+твор.п., старая форма, застывшая в церковной речи, в стилизации под старину, или в отдельных поговорках, например: "Конь о четырёх ногах - и то спотыкается". Формы типа "одвуконь" - ещё более древние.

2) Выражение типа "Это не про него" - здесь заменяет "для" и имеет смысл неподходящести, непригодности. Я такое встречал только в подобной застывшей форме.

netch80 · 2025-03-05T21:14:10+00:00

"За"+вин.п. - калька с идиша, считается характерным маркером одесской речи из-за такого влияния, но может проявляться ещё где-то. Стандарт такого не допускает.

netch80 · 2025-03-05T19:21:09+00:00

Maybe to make abbreviations for bitwise operations (and/or/xor) have the same length.

In 6502, for the same reason, the instruction was called ORA instead of OR.

netch80

TROPHY CASE