There are crowdsales where the initial supply is set upon deployment which is set to the defined total supply (so that number is as many tokens that there will be) and when someone buys tokens during the crowdsale they get transferred.
On the other hand, we have crowdsales where the tokens are mintable and the initial supply is set to 0. So, when someone buys tokens, they are minted and then transferred while the total supply is increased. There's also (most times) a hard cap to set the maximum amount of tokens that will exist. When the crowdsale ends, if the hard cap was not met, tokens will be minted up to the hard cap and be transferred to the team.
So, in both cases the end result is the same. Why use mintable tokens and add extra complexity to the code if (as far as I can tell) the end result is the same? (As long, of course, that there is a hard cap and that tokens can not be minted after the crowdsale ended)
Here's an example to illustrate my point: https://github.com/bitclave/crowdsale/blob/057357fecbcc00c9a6cf96831d71d94fb7a13f03/contracts/CATCrowdsale.sol
- There's a hard cap.
- If the hard cap is not met, the missing tokens are minted and assigned to the crowdsale owner.
- Minting is only available during crowdsale. When the crowdsale is finished, a flag is set so no more tokens can be minted, and there's no way to enable minting again.
- There's no functions to burn tokens.
So, unless I'm missing something, in this case, for example, wouldn't it have been the same to make the token non-mintable with the same total supply as the hard cap? Or am I missing something?