|
the D programming language |
Thomas Fjellstrom
Member #476
June 2000
|
I might use recordCount if I was coding C++/Qt. -- |
ImLeftFooted
Member #3,935
October 2003
|
recordCount or numRecords here. Though to be honest, if the variable was just a count of the records it'd likely be short-scoped. Short-scoped variables I just name generic crap like count or num. |
bamccaig
Member #7,536
July 2006
|
Dustin Dettmer said: Short-scoped variables I just name generic crap like count or num. Count of what!? What num!? Personally I was taught to use descriptive variable names at all times. I prefer to use descriptive names so that my code and variables explain adequately what should be happening... And comments fill in the rest. Otherwise, somebody needs to figure out where count or num are coming from and what they represent. It's also messy if another count or num is required in the same scope because then you need to rename the other variables or work around it with the new variables. Do I hear a count2/num2? -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: Count of what!? What num!? Context my man. If its a really small if or loop, you know what its a count of. its like using i for a loop var. -- |
Jakub Wasilewski
Member #3,653
June 2003
|
Quote: it's like using i for a loop var. You mean intI? --------------------------- |
bamccaig
Member #7,536
July 2006
|
Thomas Fjellstrom said: Context my man. If its a really small if or loop, you know what its a count of. its like using i for a loop var. I always declare variables at the top of the file, function, or method. So the smallest scope my variables have is function/method-level. I think the only exception is for loop control variables (see below ). Jakub Wasilewski said: You mean intI? This is where it gets a little bit awkward using Hungarian notation in C/C++ (or C-like languages)... I like using i in those languages, but then it changes naming conventions... In VB-like languages I usually use intIndex. In C-like languages, I usually use i, j, k, l, etc... Actually, the simple chat server/client programs that I wrote to demonstrate sockets programming used Hungarian notation and just used i as a for loop control variable. I'm happy with that for now... -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: You mean intI? Kill me now. -- |
ImLeftFooted
Member #3,935
October 2003
|
Quote: So the smallest scope my variables have is function/method-level. My functions tend to be small enough to be small-scoped themselves . God I love small and well documented functions. Why must I always be forced to interface functions without defined purpose? |
bamccaig
Member #7,536
July 2006
|
Dustin Dettmer said: My functions tend to be small enough to be small-scoped themselves . Prove it. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
ImLeftFooted
Member #3,935
October 2003
|
bam said: Prove it. Oh ok sure. Pick a method:
|
nonnus29
Member #2,606
August 2002
|
Wow, you guys argue about some stupid sh*t.
|
MiquelFire
Member #3,110
January 2003
|
It's bam's fault! He's normally the one to start it. --- |
Bob
Free Market Evangelist
September 2000
|
Matthew said: In one file: That doesn't seem to solve anything beyond C. C does it in exactly the same way.
-- |
Matthew Leverton
Supreme Loser
January 1999
|
Dustin's example was fairly trivial... all I was doing was translating it to D. |
Bob
Free Market Evangelist
September 2000
|
This is why I asked if D has stack-allocated non-POD types. If so, then you should be able to do away with your 'new' calls. If not, then the point is moot because C++ also supports the same feature. You just have to remember to use pointers explicitly (as opposed to implicitly, as in D). -- |
Lars Ivar Igesund
Member #8,746
June 2007
|
You can allocate on the stack by doing scope MyObj mystackinstance = new MyObj; |
axilmar
Member #1,204
April 2001
|
Quote: I think that when people use a language so verbose as C++, over time they tend to believe that all of that complexity is needed in order to be efficient (in terms of runtime speed) and non-ambiguous. So when a language like D comes along and challenges the very notion that such complexity offers nothing, it's a bit of a culture shock. I think you overstating things a bit. D is quite similar to C++: it's an imperative object-oriented programming language, very much like C++, C# and Java. If you program anything in Haskell/Lisp/Oz, then you could say it's a culture shock. For me, D is not real progress in the domain of programming languages, for the following reasons: 1) D does not help really cut down the amount of code it has to be written for a specific task. D might eliminate some of the tedious typing of C++ (namely: headers, pointers, the operator -> etc) but that is not where the bulk of work is in a program. Most algorithms in C++ are exactly the same in D anyway. 2) most bugs in a C++ program would be bugs as well in a D program, even if the consequences in the latter are less catastrophic: null pointers, out of bounds indexes, wrong order of operations etc. What I would like to see is a truly advanced programming language that really minimizes development time: -more declarative programming, less imperative programming. In the end, a D program can be as spaghetti as a C++ program. For me, there is no real reason to migrate to D, especially when the libraries are of high quality (Qt for example) and the job gets done with minimal fuss in C++. |
Lars Ivar Igesund
Member #8,746
June 2007
|
Quote: 1) D does not help really cut down the amount of code it has to be written for a specific task. D might eliminate some of the tedious typing of C++ (namely: headers, pointers, the operator -> etc) but that is not where the bulk of work is in a program. Most algorithms in C++ are exactly the same in D anyway. DMDScript, which is a fairly direct C++ -> D port of DMCScript, have 30% fewer lines of code, much because of the lack of tedious typing of explicit memory allocation (yes, I know the next revision of C++ will have optional garbage collection). Several bugs where also caught by the index checking and similar features. It may not be revolution, but a rather huge step in evolution. As for incremental development, this is much easier to do in D, if only because it is so much faster to compile. |
HoHo
Member #4,534
April 2004
|
Quote: As for incremental development, this is much easier to do in D, if only because it is so much faster to compile. I can turn off all sorts of fancy optimization flags when compiling my programs and have stuff compiled in a blink of an eye, for multiple files having high-end multicore system also helps quite a bit. Though there is one thing that often takes quite a bit of time: linking. Is D compiler any faster than C/C++ compilers (gcc) in that area? __________ |
Lars Ivar Igesund
Member #8,746
June 2007
|
The object files are the same, so the linking usually takes the same amount of time (not that I have been bothered by that). Compilation and linking takes a few seconds for larger projects. The linker that comes with the windows version of DMD is blindingly fast though. On linux I see a notable slow down when using GDC instead of DMD as the compiler (gcc is used for linking in both cases). This is mainly due to GDC not yet being able to process all files at once. Templates can slow down compilation a bit, but is still quite a bit faster than C++ afaik. |
axilmar
Member #1,204
April 2001
|
Quote: DMDScript, which is a fairly direct C++ -> D port of DMCScript, have 30% fewer lines of code, much because of the lack of tedious typing of explicit memory allocation (yes, I know the next revision of C++ will have optional garbage collection). Several bugs where also caught by the index checking and similar features. It may not be revolution, but a rather huge step in evolution. It all depends in the code you write. In Qt, for example, memory management is almost implicit: you never have to delete objects yourself...similar code as in Java Swing. Quote: As for incremental development, this is much easier to do in D, if only because it is so much faster to compile. It may be slightly easier, but not as interactive as I would like. I have played with Common Lisp a little, and interactive development is so much better than the cycle edit-compile-debug. |
Lars Ivar Igesund
Member #8,746
June 2007
|
Quote: It may be slightly easier, but not as interactive as I would like. I have played with Common Lisp a little, and interactive development is so much better than the cycle edit-compile-debug. But then you are talking about interpreted languages, which is quite a different beast (even if it in theory is possible to interpret D). |
torhu
Member #2,727
September 2002
|
About the speed of DMD. I posted this in another thread, which is compiling C code, but DMD uses the same code generator as DMC does. Building allegro with dmc is supported in the 4.2 svn branch. Quote: Command: 'gmake lib STATICLINK=1 ALLEGRO_USE_C=1' GCC: 107 seconds I did this a few times and got similiar timings. Of course, this is C, not C++. Comparing GDC to DMD is not entirely fair, since like Lars Ivar said, GDC compiles one file at a time, while DMD accepts all the files at once. Building a static link library version of DAllegro takes 0.5 secs with dmd and 11 secs when using gdc's gdmd frontend (gdmd is a perl script). That difference means you don't need a makefile with dmd in this case. It's also perfectly reasonable to use dmd for script-like tasks. On unix, just put '#! /bin/dmd -run' at the top of the file, and it's compiled to a temporary file and run. This might sound silly, but it makes sense when you need some special processing done during the build process of a D library, etc. Windows doesn't come with a usable scripting language, so it's a way to avoid the need for extra tools. But I admit it's more of a gimmick sometimes. What I mostly use -run for is to compile and run small test programs etc. No executable or object files are left when the program exits. |
axilmar
Member #1,204
April 2001
|
Quote: But then you are talking about interpreted languages, which is quite a different beast (even if it in theory is possible to interpret D). You can develop in an interpreted language environment, and when you are satisfied with the result, you can produce an executable. |
Lars Ivar Igesund
Member #8,746
June 2007
|
Yes, but since D compiles so fast and compiled code probably will execute so much faster than interpreted D, the environment you want would probably be better implemented by making a somewhat more innovative IDE that appears to look like an interpreter by wrapping the compiled executables. |
|
|