Computer Programming

The difference between a program flow chart and a system flowchart is that a program flowchart is for a single program. A system flowchart is designed for an entire system with each box representing a process.

#include<stdio.h>

#include<conio.h>

int main()

{

int i,j,k,row,m;

printf("Enter the no of rows:");

scanf("%d",&row);

m=row;

for(i=0;i<m;i++)

{

printf("\n");

for(k=0;k<row;k++)

printf(" ");

for(j=0;j<=i;j++)

printf(" *");

row--;

}

getch();

}

A procedural code is

* less maintainable * polluting the namespace of variables and methods

* making harder to decouple and modularize the code, as such, it is less reusable

than an object-oriented one

#include <stdio.h>

#include<iostream.h>

#include<conio.h>

#include<windows.h>

int main()

{

int q1, q2, q3, ave;

printf ("Enter 1st quiz: ");

scanf ("%d", &q1);

printf ("Enter 2nd quiz: ");

scanf ("%d", &q2);

printf ("Enter 3rd quiz: ");

scanf ("%d", &q3);

ave=(q1+q2+q3/3);

printf ("Average quiz is %d", ave);

getch() ;

}

Pseudocode is one method of describing an algorithm. Other methods use diagrams, prose, or maybe even regular programming languages.

An algorithm, on the other hand, is a method, a recipe, of solving a particular problem or group of related problems.

Probably one or two of these guys (you actually need at least two people!):

1. Bob Taylor, one of the original creators of the concept in 1962-1968. He had some sort of internet system between three offices.

Or

2. Lawrence G. Roberts, born 1937 in Connecticut, and who received the Draper Prize in 2001 "for the development of the Internet"

3. Leonard Kleinrock,

4. Robert Kahn,

5. Vinton Cerf.

These last four worked together and developed the 'internet concept' between themselves.

i.e. Larry Roberts and his team created the ARPANet, which was the first significant implementation of Leonard Kleinrock's theories on packet switching, a fundamental feature of (a) the modern internet and (b) ARPANet, the first large network form of the internet.

Yes. A computer programmer will at least use simple arithmetic. Most computer science degrees require a year of calculus, though I must admit that the most useful math classes I've taken were discrete mathematics. Math that deals with sequences, series, and sets tends to be the most common and useful (in my experience).

Of course it all depends on what specific field of programming you will be in.

If you will be doing a lot of network programming, then graph theory will probably be part of your everyday programming. Graphics programmers will need to know a good bit of geometry and trigonometry.

Object oriented programming allows programmers to classify data and methods by type. For instance, a shape is a type of object, a rectangle is a type of shape and a square is a type of rectangle. We can also say that a rectangle is a specialisation of a shape and that a square is a specialisation of a rectangle. Object oriented programming allows us to express relationships between types directly in code such that when we hold a reference to a square, we also hold a reference to a rectangle and a shape. As a result, we can pass a square or rectangle object to a function that knows nothing about squares or rectangles but knows everything about shapes.

All shapes can be drawn. Is it necessary for a function to know precisely how a shape is drawn? Of course not, it is only necessary to know that it can be drawn. Knowing this, the function can simply invoke the shape::draw() method regardless of the actual type of shape.

A rectangle inherits all the properties common to all shapes, thus a rectangle inherits the shape::draw() method. Moreover, a rectangle can specialise this method, overriding any default behaviour with its own specialised implementation in rectangle::draw(). Thus when we pass a rectangle object to a function that only knows about shapes and that function invokes the shape::draw() function, we actually invoke the rectangle::draw() function even though our function knows nothing about rectangles!

By the same token, a square inherits all the properties common to all rectangles, including all properties common to all shapes. Thus square::draw() inherits rectangle::draw() which overrides shape::draw(). However, a square does not actually need to override the draw method because the the implementation that applies to a rectangles also applies to a square. This is because rectangles and squares both have 4 vertices with internal angles of 90 degrees. The only thing that actually differentiates a square from a rectangle is that the adjacent vertices of a square are equidistant, but the actual vertices are defined by the rectangle so the rectangle has all the information required to draw a square. Again, the rectangle object does not need to know anything about squares in order to draw one!

Let's now look at how we can define all of these notions in an object-oriented programming language.

class shape {

public:

virtual void draw() = 0;

virtual ~shape() {}

};

class rectangle : public shape {

public:

rectangle (int top, int left, int width, int height): t {top}, l {left}, w {width}, h {height} {}

void draw() override;

void ~rectangle() override {}

private:

int t, l, w, h;

};

class square : public rectangle final {

public:

square (int top, int left, int size): rectangle {top, left, size, size} {}

};

Although this code is relatively short, it contains a lot of information. This is common in object oriented programming, we can glean a lot of information from very little code. A novice programmer might expect a few user-comments to explain everything in a bit more detail, but to a professional programmer this code tells us every we need to know.

For example, the shape::draw() method is declared a pure-virtual method (a virtual method with no implementation). This immediately tells is the shape class an abstract base class and thus prevents general users from instantiating objects of type shape. This reflects the real world where we can imagine a shape but we cannot draw one (we can only draw a specific type of shape). Being a base class (a class with at least one virtual method), the shape class also has to have a virtual destructor to ensure correct tear-down whenever a shape falls from scope. The shape class has no non-static data members thus we can take advantage of the empty class optimisation. That is, any class that inherits from shape will have zero overhead because there are no data members to inherit.

The rectangle class publicly inherits from shape. This means that all public methods of shape are public methods of rectangle. The rectangle specialises shape with the addition of 4 data members, t, l, w and h (top, left, width and height respectively). The constructor initialises these members at the point of instantiation. We also declare overrides for the inherited interfaces, shape::draw() and shape::~shape(). This is essential otherwise rectangle would also be an abstract base class and we wouldn't be able to instantiate rectangles.

The square class public inherits from rectangle and declares it final. This means we cannot inherit from square, it is not intended to be used as a base class. We automatically inherit both the rectangle::draw() and rectangle::~rectangle() interfaces and we do not need to override these. The only specialisation we need is the constructor which invokes the rectangle constructor to implement the invariant that a rectangle's width and height are always equal for squares. The square has no data members of its own, so there is zero overhead and while we do inherit the data members from rectangle, they are private so we cannot access them.

To complete the implementation, we also need to provide an implementation for the rectangle::draw() method. For this we'll assume that a line() function handles the low-level graphics facility. We do not need to know the implementation details of the line() function, we need only know that the function will draw a line between a pair of coordinates.

void rectangle::draw() {

line (t, l, t, l+w);

line (t, l+w, t+h, l+w);

line (t+h, l+w, t+h, l);

line (t+h, l, t, l);

}

Our definition is complete. We can now use these classes. Let's define a function that accepts a vector of shape pointers and invokes each of their draw methods. We'll use a type alias to reduce code verbosity:

using vec_shapes = std::vector<std::unique_ptr<shape>>;

void draw_shapes (vec_shapes& v) {

for (auto s : v) s->draw();

}

Note that this function only needs to "see" the shape definition. That is, the rectangle and square definitions could be defined in another translation unit entirely. We can even add triangles, circles, pentagons and all manner of other shapes into the mix at a later date and this code will still work without any further modification.

Now let's invoke this function:

void foo() {

vec_shapes v;

v.push_back (new square {10, 10 , 5});

v.push_back (new rectangle {20, 15 , 5, 7});

v.push_back (new square {30, 20 , 4});

v.push_back (new rectangle {40, 25 , 6, 8});

draw_shapes (&v);

}

Note that the vec_shapes alias is itself an object, one that encapsulates a vector of resource handles ("smart" pointers). Although we instantiated four new objects on the heap, we didn't actually delete them as we normally would have had to had they been "naked" pointers. That's because we don't have to delete them. When this function ends, the vector falls from scope and this automatically invokes its destructor which subsequently empties the vector. As each smart pointer within the vector is removed, it falls from scope thus invoking its destructor which explicitly invokes the destructor of the pointer it encapsulates (a pointer to shape). Since that destructor is declared virtual, the most-derived object is destroyed first before working back through the hierarchy, destroying each base class until the shape class itself is finally destroyed.

From this we begin to see the importance of object oriented programming. Resource management details can be fully encapsulated within the objects themselves, thus there is less chance of human error creating resource leaks which is a common problem with C-style coding using "naked" pointers. Objects can also encapsulate class invariants, such that only those methods that modify class member data need maintain those invariants, thus eliminating the need to constantly test those invariants at runtime and thus improving performance. Objects can also implement move semantics so that resources can be efficiently transferred from one object to another thus making it possible to perform (almost) perfect swaps without making any unnecessary temporary copies. This also makes it possible to efficiently return objects from functions by value, the default semantic in both C and C++. Our code becomes easier to write because there's much less of it and much easier to maintain because implementation details are easier to encapsulate.

Begin

Read num

for(i=2; i<num; i++)

if(num%2==0) then

print "the number is not a prime no.";

else if

print "the number is prime";

end if

Stop

Short answer - No. With our current level of technology and progress in the field of artificial intelligence there are no computers that can program themselves. However, depending on what you mean by "programme", there are lots of devices that can configure themselves using computer technology. However, even here this is ultimately due to "hard coded" behavior in the circuitry of these devices which is essentially a form of programming from a hardware perspective, which also originated from an external source (people). Of course you could also argue that people can't really "program" themselves either. If you stay strictly within the bounds of the physical realm (not accounting for metaphysical/spiritual aspects) people and by proxy their actions are also a result of causal laws. In this context, we are only a product of our biology and our environment, so in that regard we are no different then a organic computer. Of course, this is not accounting for any metaphysical or spiritual elements, which could significantly change the model of human behavior to be different from that of a computer's behavior. (Updated - Sorry, I didn't have a login yet, so I figured I should get one of those).

The question is a bit too vague for a meaningful answer, it depends on what you are searching and what you are looking for.

For search in an unsorted list, there is no better alternative than the naive algorithm of looking at every single element.

For search in a sorted list (like a phone book sorted on name) binary search is much more efficient.

For string search, like used in biology to find DNA matches, there are dedicated algorithms that deal exclusively with string matching.

For graph search, A* ("A star") is among the better.

For more general search problems there are a whole host of search methods that work better than others in particular domains. But so far, there is no ultimate winner that is best for everything. The best ones are generally custom made for one particular problem, like the best known algorithm for the Travelling Salesman Problem.

See also related link.

Yes it's not uncommon especially in children

A race condition or race hazard is a flaw in a system or process whereby the output and/or result of the process is unexpectedly and critically dependent on the sequence or timing of other events. The term originates with the idea of two signals racing each other to influence the output first. Race conditions can occur in electronics systems, especially logic circuits, and in computer software, especially multithreaded or distributed programs.

The Quadratic Formula song: (my grade saver)

To the tune of the jack in the box song

X equals negative B

plus or minus square root

of

B squared minus 4AC

all over 2A

:)

Our computers are digital computers as opposed to analog computers. Digital computers process data and instructions made up of words or bytes which are composed of a number of bits. Normally 8 bits make a byte, either 2 bytes (16 bits) or 4 bytes (32 bits) make a computer instruction or a data word. It all depends on the computer design.

The smallest piece of information (part of an instruction or data) is the bit. A bit represents something that can have two values. We call them "0" and "1". Because it can only have two values, we refer to the computer as a binary computer and its machine language as a binary language.

Everything that you can see done on a computer, from playing games, using webpages, or even clicking icons on your desktop.

Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely.You can do anything form writing single addition program to creating a websites.

You can find a copy of that file in here:

http://ftp.ibiblio.org/pub/micro/PC-stuff/freedos/files/devel/c/dos.h

in case the server is down check the extracted file:

#ifndef __DOS_H

#define __DOS_H

#include <_defs.h>

#include <stddef.h>

#ifdef __WATCOMC__

#pragma pack( __push, 1 )

#endif

struct _R16BIT {

unsigned short ax, bx, cx, dx, si, di, es, cs, ss, ds, flags;

unsigned char cflag;

};

struct _R8BIT {

unsigned char al, ah, bl, bh, cl, ch, dl, dh;

};

union _INTR {

struct _R16BIT x;

struct _R8BIT h;

};

#define INTR _INTR

struct country {

int co_date; /* date format */

char co_curr[ 5 ]; /* currency symbol */

char co_thsep[ 2 ]; /* thousands separator */

char co_desep[ 2 ]; /* decimal separator */

char co_dtsep[ 2 ]; /* date separator */

char co_tmsep[ 2 ]; /* time separator */

char co_currstyle; /* currency style */

char co_digits; /* significant digits in currency */

char co_time; /* time format */

long co_case; /* case map */

char co_dasep[ 2 ]; /* data separator */

char co_fill[ 10 ]; /* filler */

};

#define COUNTRY country

struct DOSERROR {

int de_exterror; /* extended error */

char de_class; /* error class */

char de_action; /* action */

char de_locus; /* error locus */

};

struct date {

unsigned int da_year; /* current year */

unsigned char da_day; /* day of the month */

unsigned char da_mon; /* month (1 = Jan) */

};

struct dosdate_t {

unsigned char day; /* 1--31 */

unsigned char month; /* 1--12 */

unsigned int year; /* 1980--2099 */

unsigned char dayofweek; /* 0--6; 0 = Sunday */

};

struct devhdr {

long dh_next;

short dh_attr;

unsigned short dh_strat;

unsigned short dh_inter;

char dh_name[ 8 ];

};

struct dfree {

unsigned df_avail; /* Available clusters */

unsigned df_total; /* Total clusters */

unsigned df_bsec; /* Bytes per sector */

unsigned df_sclus; /* Sectors per cluster */

};

struct diskfree_t {

unsigned total_clusters;

unsigned avail_clusters;

unsigned sectors_per_cluster;

unsigned bytes_per_sector;

};

typedef struct {

char drive;

char pattern [ 13 ];

char reserved [ 7 ];

char attrib;

short time;

short date;

long size;

char nameZ [ 13 ];

} dosSearchInfo;

struct fatinfo {

char fi_sclus; /* sectors per cluster */

char fi_fatid; /* the FAT id byte */

int fi_nclus; /* number of clusters */

int fi_bysec; /* bytes per sector */

};

struct ffblk {

#ifdef __CLIB_LFN__

unsigned short cr_time; /* time of file creation */

unsigned short cr_date; /* date of file creation */

unsigned short ac_time; /* time of last file access */

unsigned short ac_date; /* date of last file access */

char ff_reserved[ 13 ]; /* reserved for use by DOS */

#else

char ff_reserved[ 21 ]; /* reserved for use by DOS */

#endif

char ff_attrib; /* attribute byte for file */

unsigned short ff_ftime; /* time of last write to file */

unsigned short ff_fdate; /* date of last write to file */

unsigned long ff_fsize; /* length of file in bytes */

#ifdef __CLIB_LFN__

char ff_name[ 256 ]; /* null-terminated filename */

unsigned short lfnhandle;/* DOS LFN support handle */

#else

char ff_name[ 13 ]; /* null-terminated filename */

#endif

};

struct find_t {

#ifdef __CLIB_LFN__

unsigned short cr_time; /* time of file creation */

unsigned short cr_date; /* date of file creation */

unsigned short ac_time; /* time of last file access */

unsigned short ac_date; /* date of last file access */

char reserved[ 13 ]; /* reserved for use by DOS */

#else

char reserved[ 21 ]; /* reserved for use by DOS */

#endif

char attrib; /* attribute byte for file */

unsigned short wr_time; /* time of last write to file */

unsigned short wr_date; /* date of last write to file */

unsigned long size; /* length of file in bytes */

#ifdef __CLIB_LFN__

char name[ 256 ]; /* null-terminated filename */

unsigned short lfnhandle;/* DOS LFN support handle */

#else

char name[ 13 ]; /* null-terminated filename */

#endif

};

#define _find_t find_t

struct fcb {

char fcb_drive;

char fcb_name[ 8 ],

fcb_ext[ 3 ];

short fcb_curblk,

fcb_recsize;

long fcb_filsize;

short fcb_date;

char fcb_resv[ 10 ],

fcb_currec;

long fcb_random;

};

struct xfcb {

char xfcb_flag;

char xfcb_resv[ 5 ];

char xfcb_attr;

struct fcb xfcb_fcb;

};

struct dostime_t {

unsigned char hour; /* Hours */

unsigned char minute; /* Minutes */

unsigned char second; /* Seconds */

unsigned char hsecond; /* Hundredths of seconds */

};

struct time {

unsigned char ti_min; /* minutes */

unsigned char ti_hour; /* hours */

unsigned char ti_hund; /* hundredths of seconds */

unsigned char ti_sec; /* seconds */

};

#ifdef __WATCOMC__

#pragma pack( __pop )

#endif

extern int __getversion( void );

extern char ** environ;

#define _version (*__getversion)()

extern unsigned char _osmajor;

extern unsigned char _osminor;

extern int absread( int drive, int sects, long lsect, void *buffer );

extern int abswrite( int drive, int sects, long lsect, void *buffer );

extern int allocmem( unsigned size, unsigned *seg );

extern int bdos( int ah, unsigned dx, unsigned al );

extern int bdosptr( int ah, void *argument, unsigned al );

extern int _callint( union INTR *regs );

extern struct COUNTRY *

country( int xcode, struct COUNTRY *ct );

extern void ctrlbrk( int ( *handler )( void ) );

extern void delay( unsigned mill );

extern void _disable( void );

extern unsigned _dos_allocmem( unsigned size, unsigned *seg );

extern unsigned _dos_close( int handle );

extern unsigned _dos_creat( const char *path, int attr, unsigned *handle );

extern unsigned _dos_creatnew( const char *path, int attr, unsigned *handle );

extern int __cdecl dosexterror( struct DOSERROR *errblk );

extern unsigned _dos_findfirst( char *filename, int attrib, void *strptr );

extern unsigned _dos_findnext( void *strptr );

extern unsigned _dos_findclose( void *strptr );

extern unsigned _dos_freemem( unsigned seg );

extern void __cdecl _dos_getdate( struct dosdate_t *ptr );

extern unsigned __cdecl

_dos_getdiskfree( unsigned char dr, struct diskfree_t *d );

extern unsigned _dos_getdrive( unsigned *disk );

extern unsigned _dos_getfileattr( const char *filename, unsigned *attrs );

extern unsigned __cdecl

_dos_getftime( int handle,

unsigned *date,

unsigned *time );

extern void __cdecl _dos_gettime( struct dostime_t *timeptr );

extern void ( interrupt far *

_dos_getvect( unsigned intno ) )( );

extern void _dos_keep( unsigned char retcode, unsigned size );

extern unsigned _dos_open( const char *path, unsigned flags, unsigned *handle );

extern unsigned _dos_read( int handle,

void far *buf,

unsigned len,

unsigned *nread );

extern unsigned _dos_setblock( unsigned newsize,

unsigned seg,

unsigned *max );

extern void _dos_setdate( struct dosdate_t *ptr );

extern void _dos_setdrive( unsigned disk, unsigned *total );

extern unsigned _dos_setfileattr( const char *filename, unsigned attrs );

extern unsigned _dos_setftime( int handle, unsigned date, unsigned time );

extern unsigned _dos_settime( struct dostime_t *timeptr );

extern void _dos_setvect( unsigned intno,

void ( interrupt far *vect )() );

extern time_t dostounix( struct date *date, struct time *time );

extern unsigned _dos_write( int handle,

void far *buf,

unsigned len,

unsigned *bytes );

extern void _enable( void );

extern int freemem( unsigned seg );

extern int getcbrk( void );

extern void __cdecl getdate( struct date *datep );

extern void __cdecl getdfree( unsigned char drive, struct dfree *dtable );

extern char * getdta( void );

extern void getfat( unsigned char drive, struct fatinfo *dtable );

extern void getfatd( struct fatinfo *dtable );

extern unsigned getpsp( void );

extern void __cdecl gettime( struct time *timeptr );

extern void ( interrupt far *

getvect( int intno ) )( );

extern int getverify( void );

extern int inp( unsigned id );

extern unsigned inpw( unsigned id );

extern unsigned inport( unsigned id );

extern unsigned char inportb( unsigned id );

extern void keep( unsigned char retcode, unsigned size );

extern void nosound( void );

extern int outp( unsigned id, int value );

extern unsigned outpw( unsigned id, unsigned value );

extern void outport( unsigned id, unsigned value );

extern void outportb( unsigned id, unsigned char value );

extern char * parsfnm( const char *cmdline, struct fcb *ptr, int al );

extern int peek( unsigned seg, unsigned offs );

extern char peekb( unsigned seg, unsigned offs );

extern void poke( unsigned seg, unsigned offs, int value );

extern void pokeb( unsigned seg, unsigned offs, char value );

extern int randbrd( struct fcb *buf, int rnum );

extern int randbwr( struct fcb *buf, int rnum );

extern int setblock( unsigned newsize, unsigned seg );

extern int setcbrk( int value );

extern void setdate( struct date *datep );

extern void setdta( char far *dta );

extern void setpsp( unsigned psp );

extern void settime( struct time *timeptr );

extern void setvect( int intno, void ( interrupt far *vect )() );

extern void setverify( int flag );

extern void sleep( unsigned x );

extern void sound( unsigned frequency );

extern void unixtodos( time_t longtime,

struct date *date,

struct time *time );

extern int unlink( const char *filename );

#define disable _disable

#define enable _enable

#define _A_NORMAL 0x00

#define _A_RDONLY 0x01

#define _A_HIDDEN 0x02

#define _A_SYSTEM 0x04

#define _A_VOLID 0x08

#define _A_SUBDIR 0x10

#define _A_ARCH 0x20

#define FA_NORMAL _A_NORMAL

#define FA_RDONLY _A_RDONLY

#define FA_HIDDEN _A_HIDDEN

#define FA_SYSTEM _A_SYSTEM

#define FA_LABEL _A_VOLID

#define FA_DIREC _A_SUBDIR

#define FA_ARCH _A_ARCH

#define NFDS 20

#define SEEK_SET 0

#define SEEK_CUR 1

#define SEEK_END 2

#define MK_FP( seg, ofs ) ( ( void * )\

( ( ( unsigned long )( seg ) << 16 ) |\

( unsigned )( ofs ) ) )

#define FP_SEG(fp) ( ( unsigned )( ( unsigned long )( fp ) >> 16 ) )

#define FP_OFF(fp) ( ( unsigned )( fp ) )

#define __peek( a,b ) ( *( ( int far * ) MK_FP ( ( a ), ( b ) ) ) )

#define __peekb( a,b ) ( *( ( char far * ) MK_FP ( ( a ), ( b ) ) ) )

#define __poke( a,b,c ) ( *( ( int far * ) MK_FP ( (a),(b)) ) = ( int )(c))

#define __pokeb( a,b,c ) ( *( ( char far * ) MK_FP ( (a),(b)) ) = ( char )(c))

#define peek( a,b ) ( *( ( int far * ) MK_FP ( ( a ), ( b ) ) ) )

#define peekb( a,b ) ( *( ( char far * ) MK_FP ( ( a ), ( b ) ) ) )

#define poke( a,b,c ) ( *( ( int far * ) MK_FP ( (a),(b)) ) = ( int )(c))

#define pokeb( a,b,c ) ( *( ( char far * ) MK_FP ( (a),(b)) ) = ( char )(c))

#ifndef __NO_INLINE_FUNCTIONS

#pragma aux _enable = "sti";

#pragma aux _disable = "cli";

#pragma aux inp = "in al, dx" parm [dx] value [al] modify [ax dx];

#pragma aux inpw = "in ax, dx" parm [dx] value [ax] modify [ax dx];

#pragma aux inport = "in ax, dx" parm [dx] value [ax] modify [ax dx];

#pragma aux inportb = "in al, dx" parm [dx] value [al] modify [ax dx];

#pragma aux outp = "out dx, al" parm [dx] [al] value [al] modify [ax dx];

#pragma aux outpw = "out dx, ax" parm [dx] [ax] value [ax] modify [ax dx];

#pragma aux outport = "out dx, ax" parm [dx] [ax] modify [ax dx];

#pragma aux outportb = "out dx, al" parm [dx] [al] modify [ax dx];

#endif

#endif

Some say Java is the most popular. Others say it is C, C++ or C#. It may depend on the definition of the word popular. Is it the most compilers downloaded or sold? Is it about the largest number of programs (of any size) written, the largest number of commercial applications, the most lines of code, or the most number of users of applications written in a language? It is all very subjective.

However, "most popular" does not equate to "best". Java is only suitable for writing applications software. Drivers, operating system kernels and embedded systems are typically written in C, C++ or assembly language, or some combination of the three. Such system programs need access to system tables, hardware commands and registers by accessing actual hardware addresses in memory. Java will not allow this.

More importantly, Java compiles to byte code rather than native machine code, thus Java programs execute much slower than their machine coded counterparts because the byte code must be interpreted (by the Java virtual machine) upon every execution. However, Java code only needs to be compiled once since the byte code will execute on any Java virtual machine on any hardware. Machine code programs must be recompiled separately for each machine architecture.

The merits of an array are that it provides the most compact storage mechanism of any data container, and enables constant-time, random access to that data.

The demerits are that insertions and extractions can be costly in terms of performance due to the need to copy/move elements within the array. For large arrays, the cost can become prohibitive. Also, arrays can only be used to store elements of the same type.

The main deliverable from the analysis phase is the Requirements Specification document. It is a living document that needs to be revised as the requirements change during the prototyping and development activities.

a class member declared as private can only be accessed by member functions and friends of that class
a class member declared as protected can only be accessed by member functions and friends of that class,and by member functions and friends of derived classes