|
Don't really agree with "showing it off".
When you learn a couple of patterns to solve a particular problem, you have the tendency to apply it on other problems and work around the rough edges, even though it makes it unnecessarily complex.
It's because you either don't 'see' the simpler solution (never change a winning team-code), or because you are used to solve more difficult problems and have a blind spot to see the obvious (university-code).
I can't speak for every programmer off course because some people are asshats, but it's not because something looks like the instruction manual of a galaxy-class warp drive written in Greek, that it's intentionally made incomprehensible.
.
|
|
|
|
|
Yes Joe, I agree with you.
Your solucion is the best one.
I never programmed it otherwise.
Only when the size goes over some multiple of 1000 bytes
I decide to allocate heap memory.
And yes: some programmers don´t even know why.
_______________________________________
|
|
|
|
|
Once you've been indoctrinated in the ways of collections, you forget that sometimes a fixed size array actually does do what you want!
|
|
|
|
|
It's called job security. 
|
|
|
|
|
Joe Woodbury wrote: Have people gotten so accustomed to complexity that they think of only complex
solutions?
C'est la vie , i often was told that a programmer that is learning a new language (or tool) tries to use every possible function of it, anyway i always advocate for simplicity, because complex solutions usually are the hardest to mantain (or change).
|
|
|
|
|
There's a lazy reason for vector. The programmer doesn't have to remember "4" in the code that indexes it, because they can use vector size. (You can use sizeof of course)
Complexity like this is often a result of the engineer trying to cater for every imaginable change that could possibly be required in the future. So the engineer ends up saying, "What if we need to change these unsigned integer indexes into a list of Reticulating Splines?! Oh well, better make it some horrible templated monstrosity!"
I've said it myself. Only, replace "templated monstrosity" with "cathedral of generalized reusability"
Stephen Coda
|
|
|
|
|
We write more code with more complexity because languages have gotten more complex over the years, and also because we've been educated to more forms of complexity. Those various solutions deal with that complexity better.
Simple new/delete isn't the safest solution in an operator-overloaded, exception-throwing world. The smart pointer solves that issue transparently (although I'm not sure whether it deletes a single character of the array, or the entire array).
The vector<> solution allows a wider range of primatives to be used against the array, in addition to being leak-safe like the smart pointer and guaranteed to call the array version of delete.
The stack solution is probably the best, and what I would opt for, if I knew I'd never need to use any of the STL primatives on it. Besides, it doesn't run any risk of memory fragmentation like ALL of the other solutions do
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
If the number 4 was used somewhere else in the function (e.g. in the condition of a loop), I would have defined a const int fieldSize = 4; or something like that before the first usage. In the improbable case that the number needs to be increased, it avoids the trap of changing it only in one place and then having to look for the occasionally occurring error.
Regarding allocation on the stack I had an embarassing moment myself last week. I had created an object on the stack (didn't test how large it was), and it worked fine in debug mode. In release mode it crashed somewhere. Took some time and usage of several message boxes to find out the crash occurred in the moment the function containing the object was called. Then it dawned to me that I had stumbeld across this same problem some years ago in a different place. The stackzize was smaller in release mode.  I needed to allocate that object on the heap, and voilá it worked.
|
|
|
|
|
It really depends on what the "stuff" you do is, but in general I'd go with your solution.
BTW, another possibility (stack allocation, just like in your case):
std::array<char, 4> data;
|
|
|
|
|
We are running a Jenkins service for automatically building our projects and also our setups (with a call to Visual Studio's command line). Now, one of the setups failed. I scrutinized the output for finding the reason - but no, everything was marked fine. At least I thought so when I searched for "Fehler" (German word for "error"), since the entries were like e.g. "51 erfolgreich, Fehler bei 0," or "0 Fehler, 1 Warnungen" just everywhere. Why did it fail then?
Well, I tried the a search for "error" - and voilà here it is: "error MSB3104: Die referenzierte <Path-to-some\Other.dll>-Assembly wurde nicht gefunden..." The error message is available in a nice mixture of German and English.
Great idea: if something goes wrong, use the English term "error", otherwise use German.
|
|
|
|
|
OT (Sorta)
I am going to be removing CC.NET from my build server and reinstalling Jenkins, then setting up a reverse proxy in IIS to point a URL at the Jenkins instance. I do not like CC.NET very much, but I do like Jenkins.
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
I found this in one of my old codes:
public string ReadFile(string filename)
{
try
{
return File.ReadAllText(filename);
}
catch
{
return File.ReadAllText(filename);
}
}
ProgramFOX
|
|
|
|
|
If at first you don't succeed...
|
|
|
|
|
The funniest of all, is that when I was programming that,
that I didn't know why I got an error sometimes...
ProgramFOX
|
|
|
|
|
Maybe the file was in use 
|
|
|
|
|
Makes sense to me.
If you're considering stopping reading your e-book and getting some work done, it deals with your crisis of conscience for you.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark Wallace wrote: If you're considering stopping reading your e-book
But...
How can I stop reading my e-book if I'm not reading a e-book?
ProgramFOX
|
|
|
|
|
You don't. You throw a IAmNotReadingAnEBookException!
I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image.
Stephen Hawking
|
|
|
|
|
I'd do it three times, because three is the magic number:
public string ReadFile(string filename)
{
try
{
return File.ReadAllText(filename);
}
catch
{
return File.ReadAllText(filename);
}
finally
{
return File.ReadAllText(filename);
}
}
|
|
|
|
|
If that's C#, it won't compile; you'll get a "Control cannot leave the body of a finally clause" compiler error.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yes, you are right. So let's remove the last "return" (but not the File.ReadAllText).
|
|
|
|
|
That would compile on java, I think.
|
|
|
|
|
Really? 
Which value would expect to be returned here?
try
{
return 1;
}
catch
{
return 2;
}
finally
{
return 42;
}
I think the C# compiler is doing the right thing. Either the return in the finally block is ignored, in which case it shouldn't be allowed, or it replaces any value returned from the try or catch blocks, which is just confusing.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Oh I wasn't saying it should be allowed, but I think it is.
|
|
|
|
|
FTSOTR, that does compile in Java (with a little syntactic fix) and returns 42.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
