Considering C++ as a hobby...

[PvtCupcakes]

[QUOTE=esalaka;24759113]Technically all Project Euler challenges can be done by hand, too, it just... Is a little hard. :smile:[/QUOTE]

I solved one by hand. I was in a discrete math class at the time and I noticed that one of the problems was just a simple Combination.

That one would have been hard to do with a computer; it was how many different ways could you get from point A to point B on a grid of some size.

[gparent]

[QUOTE=ROBO_DONUT;24866863]I've ranted about this quite a few times now. The gist of it is that Microsoft thinks C is a dead language and has no intention of updating its support in MSVC to the latest spec. Plenty of missing header files, etc. A few implementations of standard library functions ([URL="http://www.di-mgt.com.au/cprog.html#snprintf"]snprintf is one example[/URL]) in MSVC are broken such that they are actually dangerous to use and Microsoft refuses to fix them.[/QUOTE]
That article is about a function that has been deprecated for the past 5 years. New code should use [URL="http://msdn.microsoft.com/en-us/library/f30dzcf6.aspx"]_snprintf_s[/URL]

EDIT: You're right about them not caring about C though, just felt like mentioning this isn't the best example today.

[efeX]

[QUOTE=gparent;24877730]That article is about a function that has been deprecated for the past 5 years. New code should use [URL="http://msdn.microsoft.com/en-us/library/f30dzcf6.aspx"]_snprintf_s[/URL]

EDIT: You're right about them not caring about C though, just felt like mentioning this isn't the best example today.[/QUOTE]

Well by all means tell us a better example.

[ROBO_DONUT]

[QUOTE=gparent;24877730]That article is about a function that has been deprecated for the past 5 years. New code should use [URL="http://msdn.microsoft.com/en-us/library/f30dzcf6.aspx"]_snprintf_s[/URL][/QUOTE]
So we should use Microsoft's non-standard function because they screwed up the regular one.
This is the reason nobody in their right mind tries to port a program written in C from a sane compiler (like gcc, icc, etc.) to MSVC. It'll compile fine (because it still provides a routine labelled snprintf), then you'll get all sorts of weird run-time behavior. You're really better off pretending it doesn't exist and porting with GCC+MinGW.

[gparent]

[QUOTE=ROBO_DONUT;24881727]So we should use Microsoft's non-standard function because they screwed up the regular one.[/QUOTE]
Are either of them even standard to begin with?

[ROBO_DONUT]

[QUOTE=gparent;24937500]Are either of them even standard to begin with?[/QUOTE]
Yes, snprintf is part of the C99 spec. It's also part of the Single Unix Specification v2 (1997).
Microsoft's shitty broken version probably results from SUSv2 not actually requiring the formatted string to be null-terminated (the full description of snprintf is "snprintf() is identical to sprintf() with the addition of the n argument, which states the size of the buffer referred to by s." :rolleyes:). The C99 definition is more clear on this point and requires the last byte to be null even if the string is truncated.

[gparent]

No, I meant _snprintf, not snprintf (might be a define, but it didn't seem like it on MSDN). From what I understand, if you have to use _snprintf() in unix, then it seems like both implementations are broken.

[esalaka]

[QUOTE=gparent;24938073]No, I meant _snprintf, not snprintf (might be a define, but it didn't seem like it on MSDN). From what I understand, if you have to use _snprintf() in unix, then it seems like both implementations are broken.[/QUOTE]

The Microsoft implementation is called _snprintf because it doesn't do what snprintf should.

[Agent766]

[QUOTE=esalaka;24938144]The Microsoft implementation is called _snprintf because it doesn't do what snprintf should.[/QUOTE]

I don't think any of Microsoft's products do what they're supposed to.

[gparent]

[QUOTE=esalaka;24938144]The Microsoft implementation is called _snprintf because it doesn't do what snprintf should.[/QUOTE]
I see.

[ROBO_DONUT]

[QUOTE=gparent;24938073]No, I meant _snprintf, not snprintf (might be a define, but it didn't seem like it on MSDN). From what I understand, if you have to use _snprintf() in unix, then it seems like both implementations are broken.[/QUOTE]
I'm not sure I understand what you mean. _snprintf is the C99-compatible, "safe" version of snprintf. They prefixed it with an underscore because they didn't want to "break compatibility" with software that was using their broken snprintf (which is obviously a load of crap because any software which relies on a null-terminator which is only sometimes present deserves to be broken).

The problem is that software which is ported from any other compiler will use sprintf, not _sprintf. It will compile because MSVC has a function called sprintf, but it's most likely not the one they intended to use. The incompatibility will probably not be immediately obvious and will result in strange problems at runtime.

[gparent]

[QUOTE=ROBO_DONUT;24938190]-snip-[/QUOTE]
Yeah, I misunderstood what you said. But like I said, I totally agree that their C support is terrible anyway, I just saw your example differently than I should've.

[Wyzard]

[QUOTE=ROBO_DONUT;24938190]The problem is that software which is ported from any other compiler will use sprintf, not _sprintf. It will compile because MSVC has a function called sprintf, but it's most likely not the one they intended to use. The incompatibility will probably not be immediately obvious and will result in strange problems at runtime.[/QUOTE]
They probably intend for you to do something like

#ifdef WIN32
# define snprintf _snprintf
#endif

so that you can call the standard function like usual, and you get the newer implementation in newly-compiled code, but existing compiled programs that already refer to "snprintf" in their symbol table are unaffected. I doubt you're expected to actually call _snprintf() directly.

[CowsCanFly]

[QUOTE=Wyzard;24946749]They probably intend for you to do something like

#ifdef WIN32
# define snprintf _snprintf
#endif

so that you can call the standard function like usual, and you get the newer implementation in newly-compiled code, but existing compiled programs that already refer to "snprintf" in their symbol table are unaffected. I doubt you're expected to actually call _snprintf() directly.[/QUOTE]

Except that, from memory, the fixed MS functions actually have more arguments, so that wouldn't work.

[ROBO_DONUT]

[QUOTE=CowsCanFly;24948908]Except that, from memory, the fixed MS functions actually have more arguments, so that wouldn't work.[/QUOTE]
They don't.

The problem with the preprocessor junk is that:
1. It's not obvious unless you're familiar with MSVC's idiosyncrasies.
2. It's only one of many tiny little quirks that you have to work around.

[editline]12:40AM[/editline]

Also, [url]http://msdn.microsoft.com/en-us/library/2ts7cx93(VS.71).aspx[/url]
Eight nested blocks :barf:

[Chandler]

[QUOTE=ROBO_DONUT;24949551]They don't.

The problem with the preprocessor junk is that:
1. It's not obvious unless you're familiar with MSVC's idiosyncrasies.
2. It's only one of many tiny little quirks that you have to work around.

[editline]12:40AM[/editline]

Also, [url]http://msdn.microsoft.com/en-us/library/2ts7cx93(VS.71).aspx[/url]
Eight nested blocks :barf:[/QUOTE]

Oh then you're going to love this.

_snprintf isn't actually all that safe itself. You need to use one of the following
[url]http://msdn.microsoft.com/en-us/library/f30dzcf6.aspx[/url]

On the bright side, no nested loops :v:

[gparent]

[QUOTE=ROBO_DONUT;24949551]Also, [URL="http://msdn.microsoft.com/en-us/library/2ts7cx93%28VS.71%29.aspx"]http://msdn.microsoft.com/en-us/library/2ts7cx93(VS.71).aspx[/URL]
Eight nested blocks :barf:[/QUOTE]
ROFL. That is disastrous.

[ROBO_DONUT]

I think the worst I've ever done was [url=http://github.com/ml32/ML3D-Export-Blender/blob/master/ml3d_export.py]six nested blocks[/url], and that was only because of time constraints and sheer crapitude of the Blender API.

[SyntheticGod]

[QUOTE=fusion407;24834789]if (youtubechannel != thenewboston){
cout << "find an online book";
}

else {
cout << "picky...";
}

happy..?[/QUOTE]

I just started understanding basic C++ and its actually somewhat easy. I'm not going advanced yet but I find it fun. I also understood this too.

[Zally13]

[QUOTE=Xion12;24972041]I just started understanding basic C++ and its actually somewhat easy. I'm not going advanced yet but I find it fun. I also understood this too.[/QUOTE]
Yeah that's really simple. I started and the book I'm reading is taking it slow. Hope to see you create some good stuff!