För mig är debuggern det helt avgörande när jag väljer miljö att utveckla i. Det finns en del som skriver C++ kod och inte använder debuggern, istället skriver de ut värden och kompilerar om. Det går ju bara bort på 0.1 sekund. Den typen av utveckling fungerar inte mer än om man möjligen sitter med små skol eller hobbyprojekt. En gissning är att de lärt sig koda på universitet eller liknande och där är det inte så noga hur kod skrivs, mer att de lyckas lösa något.
Utvecklare måste använda debuggern om de skall förstå och minimera antalet buggar.
Inom frontend är det än vanligare att inte använda debuggern i browsern exempelvis, typiskt för utvecklare som kör react eller annat ramverk. När de inte använder debuggern så räkna med att det blir många buggar som behöver fixas.
Om man jobbat i team och de exempelvis kör morgonmöten eller andra regelbundna samlingar så går det ibland att märka bara på hur aktiva olika är på mötena. Om utvecklare är lite si och så vad gäller att skriva buggfri kod, de brukar hela tiden ha massa saker att göra medan de som kan skriva bättre kod har mycket mindre att göra.
Chefer/ansvariga som eventuellt inte kan programmera eller förstår programmering, de fattar inte alltid utan tolkar detta som "oj vad duktiga de är som kämpar så". De tystare utvecklarna som gör rätt från början uppfattas tvärtom om kanske lite lata.
Menar inte att det alltid är så här men jag har sett det några gånger.
Säger en utvecklare "jag vill inte använda debuggern", kanske för att den tränat in andra tekniker. Då måste den utvecklaren tänka om eller förstå att produktivitet aldrig kan bli speciellt bra.
Personligen väljer jag nästan alltid Visual Studio och utveckla med för där är debuggern överlägsen. VS Code är inte alls lika bra och VS code är så seg också när projekten växer. Den fungerar för frontend men inte C++ mer än för mindre projekt.
Sublime Text brukar jag använda i frontend. Den är snabb men har inte så mycket funktionalitet självklart. Men man slipper bli irriterad på att smågrejjer tar några sekunder extra.
Skrivet av Yoshman:
Och det är väl ett ännu större argument för att använda något som ger mer kontext då alla relevant debuggers har sedan väldigt långt tillbaka explicit stöd för STL.
Det är det inte. Exempelvis undviker jag att använda std::unique_ptr just på grund av att den är lite jobbigare att debugga och jag tycker inte det är svårt med minne. Den typen av buggar har jag inte, kan knappt komma ihåg sist jag skulle ha en smäll för att minne lästes på fel adress. Om inte annat så lär sig C och C++ programmerare hur detta måste hanteras när de skriver debugkod och utvecklar ny funktionalitet.
Enda jag kan komma ihåg sett till minne är för drygt två år sedan. Skrev funktionalitet som använde sprintf. Och då så i linux med GCC använde sprintf en större buffer än med CL och LLVM i windows. Minns jag rätt så skiljde det på en byte när den skrev double värden (men är osäker nu vad det var för värde).
Ser ut som vs code, debuggern där är inte bra Jag hovrar de flesta värden och vill gärna kunna se vad det är då.
I VS code fungerar det knappt och man behöver klicka upp nästan allt som inte är primitiva värden.
Med det sagt så självklart blir det också problem med att debugga om man sköter buffern själv som "uint8_t" puBuffer". Nu är denna strings klass ganska enkel men så här skriver jag ofta kod (observera NDEBUG)
Och så använder jag också onödigt många variabler, det är för att kunna hovra värden vid debug. Detta är saker som kompilatorn optimerar bort ändå. Att skriva smarta en-rads funktionalitet är att göra sig själv en björntjänst
/** ---------------------------------------------------------------------------
* @brief Replaces the string at the given puPosition with a new string.
*
* This method manages the replacement of a string within a custom string buffer
* where each string is prefixed with its length in 32-bit unsigned integer format,
* and the data is stored in 32-byte aligned blocks.
*
* @param puPosition Pointer to the position where the string should be replaced. The position must be at the 32-bit length before string.
* @param stringReplace The new string to replace the existing one.
*
* @details
* - **Buffer Management**:
* - Checks if the new string requires more space than the existing one; if so,
* it ensures the buffer has enough capacity by potentially increasing its size.
* - If the new string's block size differs from the old one, it shifts the data
* following the replacement point to maintain buffer integrity.
*
* - **Assertions**:
* - Ensures the position for replacement is within the buffer's bounds.
*
* @pre
* - `puPosition` must be a valid pointing to a position within the string buffer.
* - `stringReplace` should not exceed the maximum size that can be represented by `uint32_t`.
*
* @post
* - The content at `puPosition` is replaced with `stringReplace`.
* - If necessary, the subsequent data in the buffer is shifted, and `m_uSize` is updated accordingly.
*/
void strings32::replace( uint8_t* puPosition, const std::string_view& stringReplace)
{ assert( puPosition >= buffer() ); assert( puPosition < buffer_end() ); assert( (puPosition - buffer()) % 4 == 0 );
#ifndef NDEBUG
std::string_view string_begin_d( c_str_s( puPosition ), length_s( puPosition ) );
auto uLength_d = length_s( puPosition );
#endif
// ## Get the position of the string to replace and calculate the block sizes
uint64_t uOffset = puPosition - m_puBuffer; // Offset of the string to replace
uint8_t* puReplacePosition = puPosition; assert( puReplacePosition < buffer_end() ); assert( puReplacePosition >= buffer() );
uint32_t uOldLength = *reinterpret_cast<uint32_t*>(puReplacePosition); // uOldLength: Length of the existing string
uint32_t uOldBlockSize = align32_g(uOldLength + (uint32_t)sizeof(uint32_t));// uOldBlockSize: Total block size of the existing string
// ## Calculate the new block size and check if the buffer can accommodate the new string
uint32_t uNewLength = static_cast<uint32_t>(stringReplace.size()); // uNewLength: Length of the new string
uint32_t uNewBlockSize = align32_g(uNewLength + (uint32_t)sizeof(uint32_t)); // uNewBlockSize: Total block size required for the new string
int64_t iSizeDifference = static_cast<int64_t>(uNewBlockSize) - static_cast<int64_t>(uOldBlockSize); // iSizeDifference: Difference between new and old block sizes
// ## Check if the new block is larger than the old one, then make sure the buffer can accommodate the extra bytes and update position
if( iSizeDifference > 0 )
{
reserve_add(static_cast<uint64_t>(iSizeDifference));
puReplacePosition = buffer() + uOffset; assert( puReplacePosition < buffer_end() ); assert( puReplacePosition >= buffer() );
}
// ## Check if there is any size difference, then shift the subsequent data to accommodate the new block size
if( iSizeDifference != 0 ) // If there is any size difference
{
uint8_t* puSource = puReplacePosition + uOldBlockSize; // puSource: Pointer to the data after the old block
uint64_t uMoveSize = m_uSize - (puSource - m_puBuffer); // uMoveSize: Number of bytes to move to adjust for the size change, it's the size from start of value to end of buffer that is used
memmove(puSource + iSizeDifference, puSource, uMoveSize); // Shift the subsequent data to accommodate the new block size
m_uSize += iSizeDifference; // Update the used buffer size after the replacement
}
*reinterpret_cast<uint32_t*>(puReplacePosition) = uNewLength; // Write the new string length into the block header
puReplacePosition += sizeof(uint32_t); // Move the pointer to the start of the string data
memcpy(puReplacePosition, stringReplace.data(), uNewLength); // Copy the new string data into the block
#ifndef NDEBUG
std::string_view string_d( (const char*)puReplacePosition, uNewLength );
uLength_d = (uint32_t)string_d.size();
#endif
}
är det svårare saker kan debug kod vara nära hälften av all kod. Blir det fel om ett år när man glömt av och det skulle smälla måste det vara lätt att förstå exakt vad som görs. Därav är sådan här kod väldokumenterad också
