Psuedoscience? No. But your programming paradigm doesn't really fall under the realm of science. It's really whatever helps you maintain cognitive control of your software.
In a small program, less than 10 thousand lines, you can get away with procedural programming. Once you get beyond that, like around a 100 thousand lines or a million lines, you'll be sorry you adopted that paradigm. It's a pattern I see with hardware guys that write software. They code like their stuff is always going to be less than a thousand lines.
memset. I wouldn't use OOP in such a way. That example adds unnecessary complexity. What I might do, depending on the circumstances, is wrap that function with a class to give me a shot at preventing it from trashing memory.
Here's an example of a good use of a class.
#include "common.h"
#ifndef INTCON_H_
#define INTCON_H_
class CIntCon
{
public://methods
CIntCon(DWORD dwAddress,DWORD dwPort,int iTimeOut=30);
virtual ~CIntCon();
void Disconnect();
FailureTypes Status();
int Write(const char * pSendThis,int iLengthInBytes);
int WriteViaPassthrough(const char * pSendThis,int iLengthInBytes,int iTarget);
int Read(BYTE * pReadBuffer,int iBytesToRead);
public://variables
private://methods
void Connect();
private://variables
FailureTypes m_fConnectStatus;
DWORD m_dwAddress;
DWORD m_dwPort;
int m_sock;
int m_iTimeout;
};
#endif /* INTCON_H_ */
#include "IntCon.h"
#include <ifaddrs.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.h>
CIntCon::CIntCon(DWORD dwAddress,DWORD dwPort,int iTimeout)
{
m_sock=-1;
m_dwAddress=dwAddress;
m_dwPort=dwPort;
m_iTimeout=iTimeout;
Connect();
}
void CIntCon::Connect()
{
struct timeval tv;
struct sockaddr_in addr;
if(m_sock>=0)
close(m_sock);
m_sock=socket(AF_INET,SOCK_STREAM,0);
if(m_sock<0)
{
m_fConnectStatus=ERROR_NO_SOCKET;
return;
}
tv.tv_sec = m_iTimeout;
tv.tv_usec = 0;
if(setsockopt(m_sock, SOL_SOCKET, SO_SNDTIMEO,(struct timeval *)&tv,sizeof(struct timeval))!=0)
{
close(m_sock);
m_sock=-1;
m_fConnectStatus=ERROR_SOCKOPT_FAILED;
return;
}
//tv.tv_sec=1;
if(setsockopt(m_sock, SOL_SOCKET, SO_RCVTIMEO,(struct timeval *)&tv,sizeof(struct timeval))!=0)
{
close(m_sock);
m_sock=-1;
m_fConnectStatus= ERROR_SOCKOPT_FAILED;
return;
}
bzero((char*)&addr,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=htonl(m_dwAddress);
addr.sin_port=htons((BYTE)m_dwPort);
if(connect(m_sock,(struct sockaddr *)&addr,sizeof(addr))!=0)
{
if(connect(m_sock,(struct sockaddr *)&addr,sizeof(addr))!=0)
{
close(m_sock);
m_sock=-1;
m_fConnectStatus= ERROR_CONNECT_FAILED;
return;
}
}
m_fConnectStatus= ERROR_OK;
}
void CIntCon::Disconnect()
{
if(m_sock>=0)
{
close(m_sock);
m_sock=-1;
}
}
FailureTypes CIntCon::Status()
{
return m_fConnectStatus;
}
int CIntCon::Write(const char * pSendThis,int iLengthInBytes)
{
if(pSendThis==NULL || iLengthInBytes<=0)
{
return -1;
}
if(m_sock>=0)
{
return write(m_sock,pSendThis,iLengthInBytes);
}
else
{
return -1;
}
}
int CIntCon::WriteViaPassthrough(const char * pSendThis,int iLengthInBytes,int iTarget)
{
char * pPassthrough=NULL;
int iRet=0;
if(pSendThis==NULL || iLengthInBytes<=0 || m_sock<0)
return -1;
pPassthrough=(char*)calloc(1,sizeof(char)*strlen(pSendThis)+strlen("Passthrough xxx_"));
sprintf(pPassthrough,"Passthrough %i_%s",iTarget,pSendThis);
iRet=Write(pPassthrough,strlen(pPassthrough));
free(pPassthrough);
usleep(25000);//not sure if this is necessary yet
return iRet;
}
int CIntCon::Read(BYTE * pReadBuffer,int iBytesToRead)
{
if(pReadBuffer==NULL || iBytesToRead<=0)
{
return -1;
}
if(m_sock>=0)
{
/*int iTryCounter=0;
int iRet=0;
do
{
iRet=read(m_sock,pReadBuffer,iBytesToRead);
iTryCounter++;
}while(iTryCounter<10 && iRet<1);
return iRet;*/
return read(m_sock,pReadBuffer,iBytesToRead);
}
else
{
return -1;
}
}
CIntCon::~CIntCon()
{
Disconnect();
}
It's appropriate for what I'm using for since I'm using sockets in a very specific way in this particular application. It makes the client code much cleaner.
There are some criticisms that c++ is c with OOP crammed into it. This is a valid complaint. Haskwell and Wolfram? I've never worked with those. If you want a language with great OOP built into it from the start then the dotnet framework or Java is the way to go.