|
Steven A. Lowe wrote: several functions were over 75 pages long - that's about 4500 lines of code in a single function
That is just flat out a horror itself.
Steven A. Lowe wrote: asked what happened to her. They said she got a job with a larger firm in the same industry just down the street - teaching C programming!
That's even scarier.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
USE [Database1]
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN
|
|
|
|
|
 Hokay. So you can't just test the state of the connection then...
|
|
|
|
|
No of course not... security and permissions you know. 
|
|
|
|
|
Austin Harris wrote: If I can't see the box, how is it going to return 0....I don't know
|
|
|
|
|
|
|
We used to have a standard stored procedure that did that. I pointed out that a successful 'ping' didn't mean anything at all: the server could be down or the connection lost by the time that the next call was made. It's been phased out.
Someone did claim that there was a problem with some old version of ADO that wouldn't return the results of the first stored procedure call you made after connecting, and so you called a dummy procedure before what you actually wanted to do. I'm skeptical - I've never seen a bug report on that. It smells of cargo-cult programming, and of the worst kind: chinese-whispers cargo-cult programming, where the implementor has heard that there's a problem and has heard that this will fix it, but has not experienced the problem themselves.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Here is an example from our current development effort:
CYesNoDlgBar *yesNoBar = new CYesNoDlgBar(this, prompt);
yesNoBar->SetCadPtr(this);
ShowCadBarModal(yesNoBar);
ret = yesNoBar->GetResult() ? 1 : 0;
if (yesNoBar)
{
delete yesNoBar;
yesNoBar = NULL;
}
Unfortunately I can't track down which developer put in this piece of code as we changed source control and lost that history otherwise he would have got a piece of my mind, as would the one who was supposed to do the code review.
Cheers,
Brett
|
|
|
|
|
LOL 
Good luck of that coder... u changed ur source control...
Anand Desai
Developer
Atharva Infotech
|
|
|
|
|
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0;
|
|
|
|
|
Haven't done any C++ for years but I agree. There's a general guideline I came across somewhere: "always use an object or a reference unless you have to use a pointer."
I saw lots of unnecessary heap allocation over the years. Why make trouble for yourself when you don't need to? Perhaps it's a sign of misplaced C++ "machismo?" 
Kevin
|
|
|
|
|
Kevin McFarlane wrote: Perhaps it's a sign of misplaced C++ "machismo?"
On the contrary, I think it comes from the SmallTalk/Java style of OOP; create anonymous object and pass pointers/references to them around. Nothing wrong with that approach if you have a GC to clean up after you, but in C++ it is much better to create objects on stack than to worry about calling delete.
|
|
|
|
|
Nemanja Trifunovic wrote: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack.
because C allows you to shoot yourself in the foot, but C++ blows it off...
(guess who said it)
Yusuf
|
|
|
|
|
It's hardly the stack that'll contribute to your foot's annihilation in C++...
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Right on. I've seen too many examples of exactly the type of coder you're talking about...
|
|
|
|
|
Nemanja Trifunovic wrote: Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack.
In the general case, you are absolutely spot on. Also, never use pointer arguments to functions unless 0/NULL is a valid value for input.
But, but, but... consider the case when an instance of CYesNoDlgBar eats too much stack by itself, and can therefore only be created on the heap? [1]
Not that I actually think that was the case there...
[1] I've actually just some moments ago fixed the GIF parts of CxImage to be usable on a handheld device platform, where the default stack is just roughly a handful of 10 KB, because several member arrays of the CxImageGIF were harcoded to sizes accumulating to way above the available stack, causing runtime failures. Using std::vector<> solved it.
--
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
Too bad you can't find the guy who did that. Who knows what other gems he has laying around.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
|
KarstenK wrote: I think you find more of these eye-candy if you go for it.
I agree and that was the point of my post earlier
I would suspect the developer probably did such a thing as a coding standard of their own and the chances of more gems like that are probably bound to be found.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
This horror using GCC for AVR.
static void apicall( void ) __attribute__ ((noinline));
static void apicall( void )
{
asm volatile("ldi r22, %0" :: "M" ((FLASHEND>>1)&0xFF));
asm volatile("push r22");
asm volatile("ldi r22, %0" :: "M" ((FLASHEND>>9)&0xFF));
asm volatile("push r22");
#if( FLASHEND > 0x1FFFF )
asm volatile("ldi r22, %0" :: "M" ((FLASHEND>>17)&0xFF));
asm volatile("push r22");
#endif
asm volatile("ldi r22, %0" :: "M" (API_PROG_PAGE));
return;
}
unsigned char copy_flash( void *src, void *dst, unsigned char dst_hi )
{
unsigned char i;
if( (unsigned int)dst & (SPM_PAGESIZE-1))
return API_ERR_PAGE;
asm volatile("movw r26, %0" :: "r" (src));
asm volatile("movw r30, %0" :: "r" (dst));
asm volatile("mov r21, %0" :: "r" (dst_hi));
apicall();
asm volatile("clr r1");
asm volatile("mov %0, r22" : "=r" (i));
return i;
}
Why push a address on the stack and using the compiler emitted ret instruction instead of using a call instruction?
Assuming CPU registers remain unchanged between asm statements: bad
Changing CPU registers in assembler without informing compiler: worse
Why not write the subroutine to use the C calling convention?
|
|
|
|
|
What can I say? Kids these days...
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Looks like an attempt to do a tail-call optimisation, so that the subroutine call returns directly to our caller (i.e. copy_flash) rather than to apicall() itself. It's probably an attempt to save a little code space.
This can backfire though: modern processors do a lot of branch prediction, and unbalancing the call/return stack will screw up the branch predictor and make your code run slower. I know Raymond Chen wrote about this but can't find the link.
I would go for a direct jump to the API entry point. Perhaps the processor doesn't have a readily-accessible jump instruction? I'd be astonished if it didn't, though.
As for changing CPU registers, the Application Binary Interface (ABI) for the system will state which registers are volatile - can be changed by a function without saving it - and which are non-volatile - must be saved by the function before being used. A function must save all the volatile registers it's used before making a call, because the called function might trash them.
I agree with you on the weird manual call to apicall() though.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
This processor does have a jump instruction, but putting everything in copy_flash would be better. And the assumption the the return address is at the top of the stack breaks when optimisation is not enabled.
What registers can be changed by a function is irrelevant here. The question is what inline assembler is allowed to do, whilst Visual C++ will parse inline assembler to determine register usage, GCC will not. If one of the registers has been allocated for another purpose by the compiler, it will break.
Neither Visual C++ or GCC guarantees that registers will remain unchanged between consecutive asm statements. If profiling is enabled this code will break.
|
|
|
|
|
Timothy Baldwin wrote: Why not write the subroutine to use the C calling convention?
Some microcontrollers have unchangeable routines in ROM to perform various functions like writing to flash memory. Some of them require that such routines be used when writing to flash because (1) none of the RAM in the system supports code execution, and (2) while a write to flash is taking place, none of the flash memory can be used for any purpose including program execution. The register and calling conventions for such routines are what they are, and there is no way a programmer or compiler author can change them.
Sometimes microcontrollers require some really nasty coding tricks to make things work in practical fashion. When I use such tricks I make sure to thoroughly document what I'm doing, and I avoid using such tricks purely for the sake of "looking impressive". On the other hand, if an interrupt routine is going to be executing 10,000 times per second on a micro which runs 1,000,000 instructions per second, having clear readable code which takes 30 cycles longer than necessary is not as good as having code which is tricky and hard to read, but runs 50 cycles faster.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
